You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cloudstack.apache.org by Asai <as...@globalchangemusic.org> on 2017/08/24 17:45:05 UTC

Unable to locate datastore with id

Greetings,

I was browsing to the Snapshots section under “Storage” 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.  Can someone please assist me on how to troubleshoot this problem?
Asai



Re: Unable to locate datastore with id

Posted by Anshul Gangwar <an...@accelerite.com>.
Probably you are facing issue https://issues.apache.org/jira/browse/CLOUDSTACK-9691.

Regards,
Anshul 

On 26/08/17, 3:42 AM, "Rafael Weingärtner" <ra...@gmail.com> wrote:

    Hmm, well, can you provide a step by step of what you are doing, the error
    you are getting and some log data of the problem?
    
    On Fri, Aug 25, 2017 at 6:00 PM, Asai <as...@globalchangemusic.org> wrote:
    
    > 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ärtner <
    > rafaelweingartner@gmail.com> wrote:
    > >
    > > By migrated, you mean moved the VM's disk to another storage that was
    > > already connected in the cluster where the vm was running?
    > >
    > > On Fri, Aug 25, 2017 at 1:13 PM, Asai <as...@globalchangemusic.org>
    > wrote:
    > >
    > >> 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
    > >>
    > >>> On Aug 25, 2017, at 7:10 AM, Rafael Weingärtner <
    > >> rafaelweingartner@gmail.com> wrote:
    > >>>
    > >>> 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?
    > >>>
    > >>> On Thu, Aug 24, 2017 at 1:57 PM, Asai <as...@globalchangemusic.org>
    > >> wrote:
    > >>>
    > >>>> Thanks,
    > >>>>
    > >>>> 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’m working on,
    > >> it
    > >>>> fails, because it’s 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
    > >>>>
    > >>>>
    > >>>>> On Aug 24, 2017, at 1:53 PM, Rafael Weingärtner <
    > >>>> rafaelweingartner@gmail.com> wrote:
    > >>>>>
    > >>>>> Do not remove (delete), to remove you can mark the flags. First set
    > the
    > >>>>> removed date flag and then the state as Destroyed.
    > >>>>>
    > >>>>> On Thu, Aug 24, 2017 at 1:10 PM, Asai <as...@globalchangemusic.org>
    > >>>> wrote:
    > >>>>>
    > >>>>>> 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
    > >>>>>>
    > >>>>>>> On Aug 24, 2017, at 1:06 PM, Asai <as...@globalchangemusic.org>
    > >> wrote:
    > >>>>>>>
    > >>>>>>> I can see now that id 3 refers to a primary storage that I had to
    > >>>> remove
    > >>>>>> a while ago.  It’s 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
    > >>>>>>>
    > >>>>>>>
    > >>>>>>>> On Aug 24, 2017, at 11:20 AM, Gabriel Beims Bräscher <
    > >>>>>> gabrascher@gmail.com> wrote:
    > >>>>>>>>
    > >>>>>>>> Just adding to Rafael's comment. Constant database backup is also
    > a
    > >>>>>> great
    > >>>>>>>> idea.
    > >>>>>>>>
    > >>>>>>>> 2017-08-24 15:19 GMT-03:00 Rafael Weingärtner <
    > >>>>>> 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ärtner <
    > >>>>>>>>>> rafaelweingartner@gmail.com> wrote:
    > >>>>>>>>>>>
    > >>>>>>>>>>> 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 = 3, and then the
    > >>>> volumes
    > >>>>>>>>> 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ärtner <
    > >>>>>>>>>>>> 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 “Storage”
    > 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.
    > >>>>>> Can
    > >>>>>>>>>>>> someone
    > >>>>>>>>>>>>>> please assist me on how to troubleshoot this problem?
    > >>>>>>>>>>>>>> Asai
    > >>>>>>>>>>>>>>
    > >>>>>>>>>>>>>>
    > >>>>>>>>>>>>>>
    > >>>>>>>>>>>>>
    > >>>>>>>>>>>>>
    > >>>>>>>>>>>>> --
    > >>>>>>>>>>>>> Rafael Weingärtner
    > >>>>>>>>>>>>
    > >>>>>>>>>>>>
    > >>>>>>>>>>>
    > >>>>>>>>>>>
    > >>>>>>>>>>> --
    > >>>>>>>>>>> Rafael Weingärtner
    > >>>>>>>>>>
    > >>>>>>>>>>
    > >>>>>>>>>
    > >>>>>>>>>
    > >>>>>>>>> --
    > >>>>>>>>> Rafael Weingärtner
    > >>>>>>>>>
    > >>>>>>>
    > >>>>>>
    > >>>>>>
    > >>>>>
    > >>>>>
    > >>>>> --
    > >>>>> Rafael Weingärtner
    > >>>>
    > >>>>
    > >>>
    > >>>
    > >>> --
    > >>> Rafael Weingärtner
    > >>
    > >>
    > >
    > >
    > > --
    > > Rafael Weingärtner
    >
    >
    
    
    -- 
    Rafael Weingärtner
    

DISCLAIMER
==========
This e-mail may contain privileged and confidential information which is the property of Accelerite, a Persistent Systems business. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Accelerite, a Persistent Systems business does not accept any liability for virus infected mails.

Re: Unable to locate datastore with id

Posted by Rafael Weingärtner <ra...@gmail.com>.
Hmm, well, can you provide a step by step of what you are doing, the error
you are getting and some log data of the problem?

On Fri, Aug 25, 2017 at 6:00 PM, Asai <as...@globalchangemusic.org> wrote:

> 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ärtner <
> rafaelweingartner@gmail.com> wrote:
> >
> > By migrated, you mean moved the VM's disk to another storage that was
> > already connected in the cluster where the vm was running?
> >
> > On Fri, Aug 25, 2017 at 1:13 PM, Asai <as...@globalchangemusic.org>
> wrote:
> >
> >> 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
> >>
> >>> On Aug 25, 2017, at 7:10 AM, Rafael Weingärtner <
> >> rafaelweingartner@gmail.com> wrote:
> >>>
> >>> 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?
> >>>
> >>> On Thu, Aug 24, 2017 at 1:57 PM, Asai <as...@globalchangemusic.org>
> >> wrote:
> >>>
> >>>> Thanks,
> >>>>
> >>>> 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’m working on,
> >> it
> >>>> fails, because it’s 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
> >>>>
> >>>>
> >>>>> On Aug 24, 2017, at 1:53 PM, Rafael Weingärtner <
> >>>> rafaelweingartner@gmail.com> wrote:
> >>>>>
> >>>>> Do not remove (delete), to remove you can mark the flags. First set
> the
> >>>>> removed date flag and then the state as Destroyed.
> >>>>>
> >>>>> On Thu, Aug 24, 2017 at 1:10 PM, Asai <as...@globalchangemusic.org>
> >>>> wrote:
> >>>>>
> >>>>>> 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
> >>>>>>
> >>>>>>> On Aug 24, 2017, at 1:06 PM, Asai <as...@globalchangemusic.org>
> >> wrote:
> >>>>>>>
> >>>>>>> I can see now that id 3 refers to a primary storage that I had to
> >>>> remove
> >>>>>> a while ago.  It’s 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
> >>>>>>>
> >>>>>>>
> >>>>>>>> On Aug 24, 2017, at 11:20 AM, Gabriel Beims Bräscher <
> >>>>>> gabrascher@gmail.com> wrote:
> >>>>>>>>
> >>>>>>>> Just adding to Rafael's comment. Constant database backup is also
> a
> >>>>>> great
> >>>>>>>> idea.
> >>>>>>>>
> >>>>>>>> 2017-08-24 15:19 GMT-03:00 Rafael Weingärtner <
> >>>>>> 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ärtner <
> >>>>>>>>>> rafaelweingartner@gmail.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> 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 = 3, and then the
> >>>> volumes
> >>>>>>>>> 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ärtner <
> >>>>>>>>>>>> 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 “Storage”
> 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.
> >>>>>> Can
> >>>>>>>>>>>> someone
> >>>>>>>>>>>>>> please assist me on how to troubleshoot this problem?
> >>>>>>>>>>>>>> Asai
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> --
> >>>>>>>>>>>>> Rafael Weingärtner
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> Rafael Weingärtner
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Rafael Weingärtner
> >>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Rafael Weingärtner
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Rafael Weingärtner
> >>
> >>
> >
> >
> > --
> > Rafael Weingärtner
>
>


-- 
Rafael Weingärtner

Re: Unable to locate datastore with id

Posted by Asai <as...@globalchangemusic.org>.
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ärtner <ra...@gmail.com> wrote:
> 
> By migrated, you mean moved the VM's disk to another storage that was
> already connected in the cluster where the vm was running?
> 
> On Fri, Aug 25, 2017 at 1:13 PM, Asai <as...@globalchangemusic.org> wrote:
> 
>> 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
>> 
>>> On Aug 25, 2017, at 7:10 AM, Rafael Weingärtner <
>> rafaelweingartner@gmail.com> wrote:
>>> 
>>> 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?
>>> 
>>> On Thu, Aug 24, 2017 at 1:57 PM, Asai <as...@globalchangemusic.org>
>> wrote:
>>> 
>>>> Thanks,
>>>> 
>>>> 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’m working on,
>> it
>>>> fails, because it’s 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
>>>> 
>>>> 
>>>>> On Aug 24, 2017, at 1:53 PM, Rafael Weingärtner <
>>>> rafaelweingartner@gmail.com> wrote:
>>>>> 
>>>>> Do not remove (delete), to remove you can mark the flags. First set the
>>>>> removed date flag and then the state as Destroyed.
>>>>> 
>>>>> On Thu, Aug 24, 2017 at 1:10 PM, Asai <as...@globalchangemusic.org>
>>>> wrote:
>>>>> 
>>>>>> 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
>>>>>> 
>>>>>>> On Aug 24, 2017, at 1:06 PM, Asai <as...@globalchangemusic.org>
>> wrote:
>>>>>>> 
>>>>>>> I can see now that id 3 refers to a primary storage that I had to
>>>> remove
>>>>>> a while ago.  It’s 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
>>>>>>> 
>>>>>>> 
>>>>>>>> On Aug 24, 2017, at 11:20 AM, Gabriel Beims Bräscher <
>>>>>> gabrascher@gmail.com> wrote:
>>>>>>>> 
>>>>>>>> Just adding to Rafael's comment. Constant database backup is also a
>>>>>> great
>>>>>>>> idea.
>>>>>>>> 
>>>>>>>> 2017-08-24 15:19 GMT-03:00 Rafael Weingärtner <
>>>>>> 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 <as...@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ärtner <
>>>>>>>>>> rafaelweingartner@gmail.com> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> 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 = 3, and then the
>>>> volumes
>>>>>>>>> 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ärtner <
>>>>>>>>>>>> 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 “Storage” 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.
>>>>>> Can
>>>>>>>>>>>> someone
>>>>>>>>>>>>>> please assist me on how to troubleshoot this problem?
>>>>>>>>>>>>>> Asai
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Rafael Weingärtner
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> --
>>>>>>>>>>> Rafael Weingärtner
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> Rafael Weingärtner
>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Rafael Weingärtner
>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> Rafael Weingärtner
>> 
>> 
> 
> 
> -- 
> Rafael Weingärtner


Re: Unable to locate datastore with id

Posted by Rafael Weingärtner <ra...@gmail.com>.
By migrated, you mean moved the VM's disk to another storage that was
already connected in the cluster where the vm was running?

On Fri, Aug 25, 2017 at 1:13 PM, Asai <as...@globalchangemusic.org> wrote:

> 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
>
> > On Aug 25, 2017, at 7:10 AM, Rafael Weingärtner <
> rafaelweingartner@gmail.com> wrote:
> >
> > 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?
> >
> > On Thu, Aug 24, 2017 at 1:57 PM, Asai <as...@globalchangemusic.org>
> wrote:
> >
> >> Thanks,
> >>
> >> 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’m working on,
> it
> >> fails, because it’s 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
> >>
> >>
> >>> On Aug 24, 2017, at 1:53 PM, Rafael Weingärtner <
> >> rafaelweingartner@gmail.com> wrote:
> >>>
> >>> Do not remove (delete), to remove you can mark the flags. First set the
> >>> removed date flag and then the state as Destroyed.
> >>>
> >>> On Thu, Aug 24, 2017 at 1:10 PM, Asai <as...@globalchangemusic.org>
> >> wrote:
> >>>
> >>>> 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
> >>>>
> >>>>> On Aug 24, 2017, at 1:06 PM, Asai <as...@globalchangemusic.org>
> wrote:
> >>>>>
> >>>>> I can see now that id 3 refers to a primary storage that I had to
> >> remove
> >>>> a while ago.  It’s 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
> >>>>>
> >>>>>
> >>>>>> On Aug 24, 2017, at 11:20 AM, Gabriel Beims Bräscher <
> >>>> gabrascher@gmail.com> wrote:
> >>>>>>
> >>>>>> Just adding to Rafael's comment. Constant database backup is also a
> >>>> great
> >>>>>> idea.
> >>>>>>
> >>>>>> 2017-08-24 15:19 GMT-03:00 Rafael Weingärtner <
> >>>> 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 <as...@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ärtner <
> >>>>>>>> rafaelweingartner@gmail.com> wrote:
> >>>>>>>>>
> >>>>>>>>> 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 = 3, and then the
> >> volumes
> >>>>>>> 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ärtner <
> >>>>>>>>>> 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 “Storage” 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.
> >>>> Can
> >>>>>>>>>> someone
> >>>>>>>>>>>> please assist me on how to troubleshoot this problem?
> >>>>>>>>>>>> Asai
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> Rafael Weingärtner
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Rafael Weingärtner
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Rafael Weingärtner
> >>>>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Rafael Weingärtner
> >>
> >>
> >
> >
> > --
> > Rafael Weingärtner
>
>


-- 
Rafael Weingärtner

Re: Unable to locate datastore with id

Posted by Asai <as...@globalchangemusic.org>.
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

> On Aug 25, 2017, at 7:10 AM, Rafael Weingärtner <ra...@gmail.com> wrote:
> 
> 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?
> 
> On Thu, Aug 24, 2017 at 1:57 PM, Asai <as...@globalchangemusic.org> wrote:
> 
>> Thanks,
>> 
>> 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’m working on, it
>> fails, because it’s 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
>> 
>> 
>>> On Aug 24, 2017, at 1:53 PM, Rafael Weingärtner <
>> rafaelweingartner@gmail.com> wrote:
>>> 
>>> Do not remove (delete), to remove you can mark the flags. First set the
>>> removed date flag and then the state as Destroyed.
>>> 
>>> On Thu, Aug 24, 2017 at 1:10 PM, Asai <as...@globalchangemusic.org>
>> wrote:
>>> 
>>>> 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
>>>> 
>>>>> On Aug 24, 2017, at 1:06 PM, Asai <as...@globalchangemusic.org> wrote:
>>>>> 
>>>>> I can see now that id 3 refers to a primary storage that I had to
>> remove
>>>> a while ago.  It’s 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
>>>>> 
>>>>> 
>>>>>> On Aug 24, 2017, at 11:20 AM, Gabriel Beims Bräscher <
>>>> gabrascher@gmail.com> wrote:
>>>>>> 
>>>>>> Just adding to Rafael's comment. Constant database backup is also a
>>>> great
>>>>>> idea.
>>>>>> 
>>>>>> 2017-08-24 15:19 GMT-03:00 Rafael Weingärtner <
>>>> 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 <as...@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ärtner <
>>>>>>>> rafaelweingartner@gmail.com> wrote:
>>>>>>>>> 
>>>>>>>>> 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 = 3, and then the
>> volumes
>>>>>>> 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 <as...@globalchangemusic.org>
>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> Do you recall if it was able to be fixed?
>>>>>>>>>> Asai
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> On Aug 24, 2017, at 11:03 AM, Rafael Weingärtner <
>>>>>>>>>> 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 “Storage” 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.
>>>> Can
>>>>>>>>>> someone
>>>>>>>>>>>> please assist me on how to troubleshoot this problem?
>>>>>>>>>>>> Asai
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> --
>>>>>>>>>>> Rafael Weingärtner
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> Rafael Weingärtner
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Rafael Weingärtner
>>>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> Rafael Weingärtner
>> 
>> 
> 
> 
> -- 
> Rafael Weingärtner


Re: Unable to locate datastore with id

Posted by Rafael Weingärtner <ra...@gmail.com>.
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?

On Thu, Aug 24, 2017 at 1:57 PM, Asai <as...@globalchangemusic.org> wrote:

> Thanks,
>
> 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’m working on, it
> fails, because it’s 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
>
>
> > On Aug 24, 2017, at 1:53 PM, Rafael Weingärtner <
> rafaelweingartner@gmail.com> wrote:
> >
> > Do not remove (delete), to remove you can mark the flags. First set the
> > removed date flag and then the state as Destroyed.
> >
> > On Thu, Aug 24, 2017 at 1:10 PM, Asai <as...@globalchangemusic.org>
> wrote:
> >
> >> 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
> >>
> >>> On Aug 24, 2017, at 1:06 PM, Asai <as...@globalchangemusic.org> wrote:
> >>>
> >>> I can see now that id 3 refers to a primary storage that I had to
> remove
> >> a while ago.  It’s 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
> >>>
> >>>
> >>>> On Aug 24, 2017, at 11:20 AM, Gabriel Beims Bräscher <
> >> gabrascher@gmail.com> wrote:
> >>>>
> >>>> Just adding to Rafael's comment. Constant database backup is also a
> >> great
> >>>> idea.
> >>>>
> >>>> 2017-08-24 15:19 GMT-03:00 Rafael Weingärtner <
> >> 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 <as...@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ärtner <
> >>>>>> rafaelweingartner@gmail.com> wrote:
> >>>>>>>
> >>>>>>> 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 = 3, and then the
> volumes
> >>>>> 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 <as...@globalchangemusic.org>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>>> Do you recall if it was able to be fixed?
> >>>>>>>> Asai
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> On Aug 24, 2017, at 11:03 AM, Rafael Weingärtner <
> >>>>>>>> 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 “Storage” 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.
> >> Can
> >>>>>>>> someone
> >>>>>>>>>> please assist me on how to troubleshoot this problem?
> >>>>>>>>>> Asai
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Rafael Weingärtner
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Rafael Weingärtner
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Rafael Weingärtner
> >>>>>
> >>>
> >>
> >>
> >
> >
> > --
> > Rafael Weingärtner
>
>


-- 
Rafael Weingärtner

Re: Unable to locate datastore with id

Posted by Asai <as...@globalchangemusic.org>.
Thanks,

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’m working on, it fails, because it’s 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


> On Aug 24, 2017, at 1:53 PM, Rafael Weingärtner <ra...@gmail.com> wrote:
> 
> Do not remove (delete), to remove you can mark the flags. First set the
> removed date flag and then the state as Destroyed.
> 
> On Thu, Aug 24, 2017 at 1:10 PM, Asai <as...@globalchangemusic.org> wrote:
> 
>> 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
>> 
>>> On Aug 24, 2017, at 1:06 PM, Asai <as...@globalchangemusic.org> wrote:
>>> 
>>> I can see now that id 3 refers to a primary storage that I had to remove
>> a while ago.  It’s 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
>>> 
>>> 
>>>> On Aug 24, 2017, at 11:20 AM, Gabriel Beims Bräscher <
>> gabrascher@gmail.com> wrote:
>>>> 
>>>> Just adding to Rafael's comment. Constant database backup is also a
>> great
>>>> idea.
>>>> 
>>>> 2017-08-24 15:19 GMT-03:00 Rafael Weingärtner <
>> 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 <as...@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ärtner <
>>>>>> rafaelweingartner@gmail.com> wrote:
>>>>>>> 
>>>>>>> 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 = 3, and then the volumes
>>>>> 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 <as...@globalchangemusic.org>
>>>>>> wrote:
>>>>>>> 
>>>>>>>> Do you recall if it was able to be fixed?
>>>>>>>> Asai
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On Aug 24, 2017, at 11:03 AM, Rafael Weingärtner <
>>>>>>>> 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 <as...@globalchangemusic.org>
>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> Greetings,
>>>>>>>>>> 
>>>>>>>>>> I was browsing to the Snapshots section under “Storage” 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.
>> Can
>>>>>>>> someone
>>>>>>>>>> please assist me on how to troubleshoot this problem?
>>>>>>>>>> Asai
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> Rafael Weingärtner
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Rafael Weingärtner
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Rafael Weingärtner
>>>>> 
>>> 
>> 
>> 
> 
> 
> -- 
> Rafael Weingärtner


Re: Unable to locate datastore with id

Posted by Rafael Weingärtner <ra...@gmail.com>.
Do not remove (delete), to remove you can mark the flags. First set the
removed date flag and then the state as Destroyed.

On Thu, Aug 24, 2017 at 1:10 PM, Asai <as...@globalchangemusic.org> wrote:

> 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
>
> > On Aug 24, 2017, at 1:06 PM, Asai <as...@globalchangemusic.org> wrote:
> >
> > I can see now that id 3 refers to a primary storage that I had to remove
> a while ago.  It’s 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
> >
> >
> >> On Aug 24, 2017, at 11:20 AM, Gabriel Beims Bräscher <
> gabrascher@gmail.com> wrote:
> >>
> >> Just adding to Rafael's comment. Constant database backup is also a
> great
> >> idea.
> >>
> >> 2017-08-24 15:19 GMT-03:00 Rafael Weingärtner <
> 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 <as...@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ärtner <
> >>>> rafaelweingartner@gmail.com> wrote:
> >>>>>
> >>>>> 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 = 3, and then the volumes
> >>> 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 <as...@globalchangemusic.org>
> >>>> wrote:
> >>>>>
> >>>>>> Do you recall if it was able to be fixed?
> >>>>>> Asai
> >>>>>>
> >>>>>>
> >>>>>>> On Aug 24, 2017, at 11:03 AM, Rafael Weingärtner <
> >>>>>> 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 <as...@globalchangemusic.org>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>>> Greetings,
> >>>>>>>>
> >>>>>>>> I was browsing to the Snapshots section under “Storage” 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.
> Can
> >>>>>> someone
> >>>>>>>> please assist me on how to troubleshoot this problem?
> >>>>>>>> Asai
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Rafael Weingärtner
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Rafael Weingärtner
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Rafael Weingärtner
> >>>
> >
>
>


-- 
Rafael Weingärtner

Re: Unable to locate datastore with id

Posted by Asai <as...@globalchangemusic.org>.
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

> On Aug 24, 2017, at 1:06 PM, Asai <as...@globalchangemusic.org> wrote:
> 
> I can see now that id 3 refers to a primary storage that I had to remove a while ago.  It’s 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
> 
> 
>> On Aug 24, 2017, at 11:20 AM, Gabriel Beims Bräscher <ga...@gmail.com> wrote:
>> 
>> Just adding to Rafael's comment. Constant database backup is also a great
>> idea.
>> 
>> 2017-08-24 15:19 GMT-03:00 Rafael Weingärtner <ra...@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 <as...@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ärtner <
>>>> rafaelweingartner@gmail.com> wrote:
>>>>> 
>>>>> 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 = 3, and then the volumes
>>> 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 <as...@globalchangemusic.org>
>>>> wrote:
>>>>> 
>>>>>> Do you recall if it was able to be fixed?
>>>>>> Asai
>>>>>> 
>>>>>> 
>>>>>>> On Aug 24, 2017, at 11:03 AM, Rafael Weingärtner <
>>>>>> 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 <as...@globalchangemusic.org>
>>>>>> wrote:
>>>>>>> 
>>>>>>>> Greetings,
>>>>>>>> 
>>>>>>>> I was browsing to the Snapshots section under “Storage” 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.  Can
>>>>>> someone
>>>>>>>> please assist me on how to troubleshoot this problem?
>>>>>>>> Asai
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Rafael Weingärtner
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Rafael Weingärtner
>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> Rafael Weingärtner
>>> 
> 


Re: Unable to locate datastore with id

Posted by Asai <as...@globalchangemusic.org>.
I can see now that id 3 refers to a primary storage that I had to remove a while ago.  It’s 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


> On Aug 24, 2017, at 11:20 AM, Gabriel Beims Bräscher <ga...@gmail.com> wrote:
> 
> Just adding to Rafael's comment. Constant database backup is also a great
> idea.
> 
> 2017-08-24 15:19 GMT-03:00 Rafael Weingärtner <ra...@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 <as...@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ärtner <
>>> rafaelweingartner@gmail.com> wrote:
>>>> 
>>>> 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 = 3, and then the volumes
>> 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 <as...@globalchangemusic.org>
>>> wrote:
>>>> 
>>>>> Do you recall if it was able to be fixed?
>>>>> Asai
>>>>> 
>>>>> 
>>>>>> On Aug 24, 2017, at 11:03 AM, Rafael Weingärtner <
>>>>> 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 <as...@globalchangemusic.org>
>>>>> wrote:
>>>>>> 
>>>>>>> Greetings,
>>>>>>> 
>>>>>>> I was browsing to the Snapshots section under “Storage” 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.  Can
>>>>> someone
>>>>>>> please assist me on how to troubleshoot this problem?
>>>>>>> Asai
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Rafael Weingärtner
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> Rafael Weingärtner
>>> 
>>> 
>> 
>> 
>> --
>> Rafael Weingärtner
>> 


Re: Unable to locate datastore with id

Posted by Gabriel Beims Bräscher <ga...@gmail.com>.
Just adding to Rafael's comment. Constant database backup is also a great
idea.

2017-08-24 15:19 GMT-03:00 Rafael Weingärtner <ra...@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 <as...@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ärtner <
> > rafaelweingartner@gmail.com> wrote:
> > >
> > > 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 = 3, and then the volumes
> 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 <as...@globalchangemusic.org>
> > wrote:
> > >
> > >> Do you recall if it was able to be fixed?
> > >> Asai
> > >>
> > >>
> > >>> On Aug 24, 2017, at 11:03 AM, Rafael Weingärtner <
> > >> 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 <as...@globalchangemusic.org>
> > >> wrote:
> > >>>
> > >>>> Greetings,
> > >>>>
> > >>>> I was browsing to the Snapshots section under “Storage” 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.  Can
> > >> someone
> > >>>> please assist me on how to troubleshoot this problem?
> > >>>> Asai
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>> --
> > >>> Rafael Weingärtner
> > >>
> > >>
> > >
> > >
> > > --
> > > Rafael Weingärtner
> >
> >
>
>
> --
> Rafael Weingärtner
>

Re: Unable to locate datastore with id

Posted by Rafael Weingärtner <ra...@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 <as...@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ärtner <
> rafaelweingartner@gmail.com> wrote:
> >
> > 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 = 3, and then the volumes 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 <as...@globalchangemusic.org>
> wrote:
> >
> >> Do you recall if it was able to be fixed?
> >> Asai
> >>
> >>
> >>> On Aug 24, 2017, at 11:03 AM, Rafael Weingärtner <
> >> 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 <as...@globalchangemusic.org>
> >> wrote:
> >>>
> >>>> Greetings,
> >>>>
> >>>> I was browsing to the Snapshots section under “Storage” 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.  Can
> >> someone
> >>>> please assist me on how to troubleshoot this problem?
> >>>> Asai
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Rafael Weingärtner
> >>
> >>
> >
> >
> > --
> > Rafael Weingärtner
>
>


-- 
Rafael Weingärtner

Re: Unable to locate datastore with id

Posted by Asai <as...@globalchangemusic.org>.
Thank you very much for the assistance.  I will try that.
Asai
> On Aug 24, 2017, at 11:12 AM, Rafael Weingärtner <ra...@gmail.com> wrote:
> 
> 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 = 3, and then the volumes 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 <as...@globalchangemusic.org> wrote:
> 
>> Do you recall if it was able to be fixed?
>> Asai
>> 
>> 
>>> On Aug 24, 2017, at 11:03 AM, Rafael Weingärtner <
>> 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 <as...@globalchangemusic.org>
>> wrote:
>>> 
>>>> Greetings,
>>>> 
>>>> I was browsing to the Snapshots section under “Storage” 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.  Can
>> someone
>>>> please assist me on how to troubleshoot this problem?
>>>> Asai
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> Rafael Weingärtner
>> 
>> 
> 
> 
> -- 
> Rafael Weingärtner


Re: Unable to locate datastore with id

Posted by Rafael Weingärtner <ra...@gmail.com>.
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 = 3, and then the volumes 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 <as...@globalchangemusic.org> wrote:

> Do you recall if it was able to be fixed?
> Asai
>
>
> > On Aug 24, 2017, at 11:03 AM, Rafael Weingärtner <
> 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 <as...@globalchangemusic.org>
> wrote:
> >
> >> Greetings,
> >>
> >> I was browsing to the Snapshots section under “Storage” 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.  Can
> someone
> >> please assist me on how to troubleshoot this problem?
> >> Asai
> >>
> >>
> >>
> >
> >
> > --
> > Rafael Weingärtner
>
>


-- 
Rafael Weingärtner

Re: Unable to locate datastore with id

Posted by Asai <as...@globalchangemusic.org>.
Do you recall if it was able to be fixed?
Asai


> On Aug 24, 2017, at 11:03 AM, Rafael Weingärtner <ra...@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 <as...@globalchangemusic.org> wrote:
> 
>> Greetings,
>> 
>> I was browsing to the Snapshots section under “Storage” 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.  Can someone
>> please assist me on how to troubleshoot this problem?
>> Asai
>> 
>> 
>> 
> 
> 
> -- 
> Rafael Weingärtner


Re: Unable to locate datastore with id

Posted by Rafael Weingärtner <ra...@gmail.com>.
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 <as...@globalchangemusic.org> wrote:

> Greetings,
>
> I was browsing to the Snapshots section under “Storage” 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.  Can someone
> please assist me on how to troubleshoot this problem?
> Asai
>
>
>


-- 
Rafael Weingärtner