Mailing-List: contact users-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cloudstack.apache.org
MIME-Version: 1.0
In-Reply-To: <CAG97raft5PefPRaq0PsUkygOXzaNFpbi=RmxR9x5NR5FLiRr1g@mail.gmail.com>
References: <809B3F09-3782-40EF-88AF-8151B86F775D@globalchangemusic.org>
 <CAG97radnPxX8+vcdWZkjftaRaVGbr5qRkW9a7pmMxUyhj9wfhA@mail.gmail.com>
 <BAB115B4-B1A6-4734-80DA-9EDE272F8616@globalchangemusic.org>
 <CAG97raeUzvNbPV=nWR6SCBh=Jhfs7p+zMj8ui=vGmXUPFX3gVQ@mail.gmail.com>
 <C3C4CE97-6D85-4EE1-ACA2-2A85037E692A@globalchangemusic.org> <CAG97raft5PefPRaq0PsUkygOXzaNFpbi=RmxR9x5NR5FLiRr1g@mail.gmail.com>
From: =?UTF-8?Q?Gabriel_Beims_Br=C3=A4scher?= <gabrascher@gmail.com>
Date: Thu, 24 Aug 2017 15:20:56 -0300
Message-ID: <CAFo0Kr8RTBpYC4ZkWJLoF8-CXVE+q3n4gEmmZ-CS7g1dc8-Xtw@mail.gmail.com>
Subject: Re: Unable to locate datastore with id
To: users@cloudstack.apache.org
Content-Type: multipart/alternative; boundary="001a1141bce2c15ba2055783e340"
archived-at: Thu, 24 Aug 2017 18:21:10 -0000

--001a1141bce2c15ba2055783e340
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Just adding to Rafael's comment. Constant database backup is also a great
idea.

2017-08-24 15:19 GMT-03:00 Rafael Weing=C3=A4rtner <rafaelweingartner@gmail=
.com>:

> I would suggest you taking quite a lot of care before executing anything =
in
> the database.
> Please, do not hesitate to ask for further assistance here.
>
> On Thu, Aug 24, 2017 at 2:15 PM, Asai <asai@globalchangemusic.org> wrote:
>
> > Thank you very much for the assistance.  I will try that.
> > Asai
> > > On Aug 24, 2017, at 11:12 AM, Rafael Weing=C3=A4rtner <
> > rafaelweingartner@gmail.com> wrote:
> > >
> > > Yes, quite easily.
> > > I do not know if your problem is the same (you need a human not payin=
g
> > much
> > > attention to cause this type of problem), but basically, you can chec=
k
> in
> > > the database what is the data store with id =3D 3, and then the volum=
es
> of
> > > snapshots that are allocated in this data store, and then you can
> remove
> > > them manually setting the flags.
> > >
> > >
> > > On Thu, Aug 24, 2017 at 2:09 PM, Asai <asai@globalchangemusic.org>
> > wrote:
> > >
> > >> Do you recall if it was able to be fixed?
> > >> Asai
> > >>
> > >>
> > >>> On Aug 24, 2017, at 11:03 AM, Rafael Weing=C3=A4rtner <
> > >> rafaelweingartner@gmail.com> wrote:
> > >>>
> > >>> I have seen this issue before. In the environment I noticed it, it
> was
> > >>> caused by someone that manually deleted a volume in the database in
> > order
> > >>> to remove a data store, but the snapshot that was using that volume
> was
> > >> not
> > >>> removed. Then, the data store was removed. By delete here I mean
> > setting
> > >>> the flag "removed" in the database to some data and the "state" to
> > >>> destroyed.
> > >>>
> > >>> On Thu, Aug 24, 2017 at 1:45 PM, Asai <asai@globalchangemusic.org>
> > >> wrote:
> > >>>
> > >>>> Greetings,
> > >>>>
> > >>>> I was browsing to the Snapshots section under =E2=80=9CStorage=E2=
=80=9D today and
> came
> > >> up
> > >>>> with this error:
> > >>>>
> > >>>> Unable to locate datastore with id 3
> > >>>>
> > >>>> I am unable to figure this out.  I went to the Secondary Storage
> > server
> > >>>> and it looks like all the snapshots are there from 2 days ago.  Ca=
n
> > >> someone
> > >>>> please assist me on how to troubleshoot this problem?
> > >>>> Asai
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>> --
> > >>> Rafael Weing=C3=A4rtner
> > >>
> > >>
> > >
> > >
> > > --
> > > Rafael Weing=C3=A4rtner
> >
> >
>
>
> --
> Rafael Weing=C3=A4rtner
>

--001a1141bce2c15ba2055783e340--