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 <a...@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 < > rafaelweingart...@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 <a...@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 < > >> rafaelweingart...@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 <a...@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 <a...@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 < > >>>> gabrasc...@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 < > >>>> rafaelweingart...@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 <a...@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 < > >>>>>>>> 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 > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> Rafael Weingärtner > >>>>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >>> -- > >>> Rafael Weingärtner > >> > >> > > > > > > -- > > Rafael Weingärtner > > -- Rafael Weingärtner
