Thank you very much for the assistance. I will try that.
Asai
> On Aug 24, 2017, at 11:12 AM, Rafael Weingärtner
> <rafaelweingart...@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 <a...@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 <
>> rafaelweingart...@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 <a...@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
