Mailing-List: contact users-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cloudstack.apache.org
From: Asai <asai@globalchangemusic.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_77DDCA0C-68E4-4E5B-9CB1-01F98F7527A1"
Message-Id: <F627E188-2BDE-4A98-9DDB-17D070A861DE@globalchangemusic.org>
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: Unable to locate datastore with id 
Date: Fri, 25 Aug 2017 15:00:32 -0700
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> <CAFo0Kr8RTBpYC4ZkWJLoF8-CXVE+q3n4gEmmZ-CS7g1dc8-Xtw@mail.gmail.com> <E08FD26F-A4EF-447D-8E45-CC652C0766B2@globalchangemusic.org> <94D901BC-535C-48EE-8AEC-832E80AC148D@globalchangemusic.org> <CAG97raearavJX--FxMcbPoHAOjXOex5Mj_ak9ZQzAA_dMdnKgQ@mail.gmail.com> <D7C4CA9B-AF60-4B60-9AF1-C1BCA480D2CE@globalchangemusic.org> <CAG97rae3+u0ejtkmLB03bPUDHS_eFeCmhArgDnYuS86Dpp+cdg@mail.gmail.com> <1432676A-6CBE-4693-94B4-7F916E8333C7@globalchangemusic.org> <CAG97rad8prEKEDsnYZWDTjVSaGa85ALE+MKDGTtQAZz9yFzS8g@mail.gmail.com>
To: users@cloudstack.apache.org
In-Reply-To: <CAG97rad8prEKEDsnYZWDTjVSaGa85ALE+MKDGTtQAZz9yFzS8g@mail.gmail.com>
archived-at: Fri, 25 Aug 2017 22:01:12 -0000

--Apple-Mail=_77DDCA0C-68E4-4E5B-9CB1-01F98F7527A1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Yes, I had two servers running in the cluster and each had a primary =
storage.  I removed one of them, but before removing, I migrated all the =
VMs and Volumes on that server to the other one.
Asai


> On Aug 25, 2017, at 10:57 AM, Rafael Weing=C3=A4rtner =
<rafaelweingartner@gmail.com> wrote:
>=20
> By migrated, you mean moved the VM's disk to another storage that was
> already connected in the cluster where the vm was running?
>=20
> On Fri, Aug 25, 2017 at 1:13 PM, Asai <asai@globalchangemusic.org> =
wrote:
>=20
>> I migrated the VM to another Primary Storage and Host, then removed =
the
>> primary storage that was no longer in use from the Infrastructure.
>> Asai
>> Network and Systems Administrator
>> GLOBAL CHANGE MEDIA
>> office: 520.398.2542
>> http://globalchange.media
>> Tucson, AZ
>>=20
>>> On Aug 25, 2017, at 7:10 AM, Rafael Weing=C3=A4rtner <
>> rafaelweingartner@gmail.com> wrote:
>>>=20
>>> I did not understand. You removed a primary storage, how do you =
still
>> have
>>> a VM running that is from this deleted primary storage?
>>> What did you do? what was the process to remove a storage?
>>>=20
>>> On Thu, Aug 24, 2017 at 1:57 PM, Asai <asai@globalchangemusic.org>
>> wrote:
>>>=20
>>>> Thanks,
>>>>=20
>>>> The next problem seems to be now, that there was an original =
snapshot
>> that
>>>> is no longer there.  When I try to snapshot the volume I=E2=80=99m =
working on,
>> it
>>>> fails, because it=E2=80=99s looking for an initial snapshot that =
the database
>> says
>>>> is still there, but which was actually removed when I removed the =
other
>>>> Primary Storage volume.  Does that make sense?  What do I need to
>> change in
>>>> the database for that volume to be able to snapshot?
>>>> Asai
>>>>=20
>>>>=20
>>>>> On Aug 24, 2017, at 1:53 PM, Rafael Weing=C3=A4rtner <
>>>> rafaelweingartner@gmail.com> wrote:
>>>>>=20
>>>>> Do not remove (delete), to remove you can mark the flags. First =
set the
>>>>> removed date flag and then the state as Destroyed.
>>>>>=20
>>>>> On Thu, Aug 24, 2017 at 1:10 PM, Asai <asai@globalchangemusic.org>
>>>> wrote:
>>>>>=20
>>>>>> I the DB table snapshot_store_ref I see two snapshots listed with
>>>> store_id
>>>>>> 3.  Can I safely remove those rows?
>>>>>> Asai
>>>>>> Network and Systems Administrator
>>>>>> GLOBAL CHANGE MEDIA
>>>>>> office: 520.398.2542
>>>>>> http://globalchange.media
>>>>>> Tucson, AZ
>>>>>>=20
>>>>>>> On Aug 24, 2017, at 1:06 PM, Asai <asai@globalchangemusic.org>
>> wrote:
>>>>>>>=20
>>>>>>> I can see now that id 3 refers to a primary storage that I had =
to
>>>> remove
>>>>>> a while ago.  It=E2=80=99s still in the DB, though, and seems to =
be causing
>> the
>>>>>> error.  What steps should I take to remove this reference =
completely
>>>> from
>>>>>> the DB?
>>>>>>> Asai
>>>>>>>=20
>>>>>>>=20
>>>>>>>> On Aug 24, 2017, at 11:20 AM, Gabriel Beims Br=C3=A4scher <
>>>>>> gabrascher@gmail.com> wrote:
>>>>>>>>=20
>>>>>>>> Just adding to Rafael's comment. Constant database backup is =
also a
>>>>>> great
>>>>>>>> idea.
>>>>>>>>=20
>>>>>>>> 2017-08-24 15:19 GMT-03:00 Rafael Weing=C3=A4rtner <
>>>>>> rafaelweingartner@gmail.com>:
>>>>>>>>=20
>>>>>>>>> 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.
>>>>>>>>>=20
>>>>>>>>> On Thu, Aug 24, 2017 at 2:15 PM, Asai =
<asai@globalchangemusic.org>
>>>>>> wrote:
>>>>>>>>>=20
>>>>>>>>>> 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:
>>>>>>>>>>>=20
>>>>>>>>>>> Yes, quite easily.
>>>>>>>>>>> I do not know if your problem is the same (you need a human =
not
>>>>>> paying
>>>>>>>>>> much
>>>>>>>>>>> attention to cause this type of problem), but basically, you =
can
>>>>>> check
>>>>>>>>> in
>>>>>>>>>>> the database what is the data store with id =3D 3, and then =
the
>>>> volumes
>>>>>>>>> of
>>>>>>>>>>> snapshots that are allocated in this data store, and then =
you can
>>>>>>>>> remove
>>>>>>>>>>> them manually setting the flags.
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> On Thu, Aug 24, 2017 at 2:09 PM, Asai <
>> asai@globalchangemusic.org>
>>>>>>>>>> wrote:
>>>>>>>>>>>=20
>>>>>>>>>>>> Do you recall if it was able to be fixed?
>>>>>>>>>>>> Asai
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>> On Aug 24, 2017, at 11:03 AM, Rafael Weing=C3=A4rtner <
>>>>>>>>>>>> rafaelweingartner@gmail.com> wrote:
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> On Thu, Aug 24, 2017 at 1:45 PM, Asai <
>>>> asai@globalchangemusic.org>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> Greetings,
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> I was browsing to the Snapshots section under =
=E2=80=9CStorage=E2=80=9D today
>>>> and
>>>>>>>>> came
>>>>>>>>>>>> up
>>>>>>>>>>>>>> with this error:
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> Unable to locate datastore with id 3
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> 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.
>>>>>> Can
>>>>>>>>>>>> someone
>>>>>>>>>>>>>> please assist me on how to troubleshoot this problem?
>>>>>>>>>>>>>> Asai
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Rafael Weing=C3=A4rtner
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>>=20
>>>>>>>>>>> --
>>>>>>>>>>> Rafael Weing=C3=A4rtner
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> --
>>>>>>>>> Rafael Weing=C3=A4rtner
>>>>>>>>>=20
>>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>=20
>>>>>=20
>>>>> --
>>>>> Rafael Weing=C3=A4rtner
>>>>=20
>>>>=20
>>>=20
>>>=20
>>> --
>>> Rafael Weing=C3=A4rtner
>>=20
>>=20
>=20
>=20
> --=20
> Rafael Weing=C3=A4rtner


--Apple-Mail=_77DDCA0C-68E4-4E5B-9CB1-01F98F7527A1--