Unless I'm reading this incorrectly, it looks like label.action.restore.instance (Restore Instance) maps to recoverVirtualMachine
and label.resetVM (Reset VM) maps to restoreVirtualMachine On Wed, Mar 19, 2014 at 11:30 PM, Mike Tutkowski < mike.tutkow...@solidfire.com> wrote: > Ah, right - my mistake. I should have thought of that. > > > On Wed, Mar 19, 2014 at 11:29 PM, Harikrishna Patnala < > harikrishna.patn...@citrix.com> wrote: > >> There are two different APIs RestoreVMCmd and RecoverVMCmd >> >> RestoreVMCmd is what we are talking about here to restore the VM to fresh >> new root disk >> RecoverVMCmd is used to recover the vm back after we try to destroy the >> VM (within the time after Destroy and before Expunge) >> >> Thanks >> Harikrishna >> >> >> On 20-Mar-2014, at 10:49 am, Mike Tutkowski <mike.tutkow...@solidfire.com> >> wrote: >> >> > I see the actual API command is RecoverVMCmd. >> > >> > I wonder why the GUI says Reset instead of Recover. >> > >> > >> > On Wed, Mar 19, 2014 at 10:59 PM, Mike Tutkowski < >> > mike.tutkow...@solidfire.com> wrote: >> > >> >> Please correct me if I'm wrong, but there does not appear to be a way >> to >> >> "save" the old root disk once it has gone into the Destroy state in >> this >> >> situation, is there? >> >> >> >> In other words, the new root disk is created, the old is put into the >> >> Destroy state, and the old will get deleted at the next clean-up >> cycle...no >> >> chance to restore that volume (even for use as a data disk). >> >> >> >> >> >> On Wed, Mar 19, 2014 at 10:33 PM, Mike Tutkowski < >> >> mike.tutkow...@solidfire.com> wrote: >> >> >> >>> OK, I went back an re-ran my test. >> >>> >> >>> I see how this works now. >> >>> >> >>> I was aware that volumes in the Destroy state get expunged by a >> >>> background thread at some point; however, what tricked me here is >> that my >> >>> "old" root disk no longer showed up in the Storage tab of the GUI. >> >>> >> >>> When I looked in the volumes table, though, I saw that that disk was >> in >> >>> the Destroy state. >> >>> >> >>> I speed up the frequency of the clean-up background thread to run once >> >>> every minute and I saw the old root disk got put into the Expunged >> state >> >>> (as you'd expect, it was no longer present in the SR). >> >>> >> >>> >> >>> On Wed, Mar 19, 2014 at 7:06 PM, Mike Tutkowski < >> >>> mike.tutkow...@solidfire.com> wrote: >> >>> >> >>>> Yeah, usually "reset" (for hypervisors) means "shut down the VM and >> >>>> re-start it." >> >>>> >> >>>> >> >>>> On Wed, Mar 19, 2014 at 6:22 PM, Marcus <shadow...@gmail.com> wrote: >> >>>> >> >>>>> +1 to reset being a bad verb for this. It's too late now, however. >> >>>>> >> >>>>> On Wed, Mar 19, 2014 at 6:22 PM, Marcus <shadow...@gmail.com> >> wrote: >> >>>>>> The storage gets marked as 'Destroy' state. Then it goes to >> >>>>>> 'Expunging' when the storage cleanup interval occurs. I've actually >> >>>>>> thought about leveraging that for data disks, the current delete >> data >> >>>>>> disk immediately cleans up the disk, when we could create an api >> call >> >>>>>> that just moves the data disk to destroy state. Then there'd >> actually >> >>>>>> be room for an 'undo' operation where the state could be moved >> back to >> >>>>>> Ready, so long as the cleanup hasn't occurred. >> >>>>>> >> >>>>>> On Wed, Mar 19, 2014 at 4:43 PM, Nitin Mehta < >> nitin.me...@citrix.com> >> >>>>> wrote: >> >>>>>>> Please feel free to open a documentation bug on JIRA if the info >> >>>>> doesn't >> >>>>>>> exist. >> >>>>>>> >> >>>>>>> On 19/03/14 3:16 PM, "Mike Tutkowski" < >> mike.tutkow...@solidfire.com> >> >>>>> wrote: >> >>>>>>> >> >>>>>>>> Thanks for that background-cleanup info. I was not aware of that. >> >>>>>>>> >> >>>>>>>> I'll probably take a look into it and see how that works. >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> On Wed, Mar 19, 2014 at 4:13 PM, Alena Prokharchyk < >> >>>>>>>> alena.prokharc...@citrix.com> wrote: >> >>>>>>>> >> >>>>>>>>> CS destroys the Root volume in CS DB, then its up to the storage >> >>>>> pool >> >>>>>>>>> cleanup task to clean it up on the backend. This is a background >> >>>>> task >> >>>>>>>>> running every storage.cleanup.interval seconds. >> >>>>>>>>> >> >>>>>>>>> For how long do you see the volume being present on the SR? >> >>>>>>>>> >> >>>>>>>>> On 3/19/14, 3:03 PM, "Mike Tutkowski" < >> >>>>> mike.tutkow...@solidfire.com> >> >>>>>>>>> wrote: >> >>>>>>>>> >> >>>>>>>>>> OK, sounds good; however, if this is desired behavior, does >> >>>>> anyone know >> >>>>>>>>>> why >> >>>>>>>>>> we abandon the old root disk in the XenServer SR? It seems that >> >>>>>>>>> CloudStack >> >>>>>>>>>> "forgets" about it and it just stays in the SR taking up space. >> >>>>>>>>>> >> >>>>>>>>>> Do people think it should be deleted? >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> On Wed, Mar 19, 2014 at 3:49 PM, Nitin Mehta < >> >>>>> nitin.me...@citrix.com> >> >>>>>>>>>> wrote: >> >>>>>>>>>> >> >>>>>>>>>>> I think that's what it is supposed to do. It discards the old >> >>>>> root >> >>>>>>>>> disk >> >>>>>>>>>>> and creates a fresh root disk for the vm and in case an >> optional >> >>>>>>>>> field >> >>>>>>>>>>> template id is passed in the root disk is created from this >> new >> >>>>>>>>> template >> >>>>>>>>>>> id. >> >>>>>>>>>>> The api name is restoreVirtualMachine. Please check that the >> UI >> >>>>> is >> >>>>>>>>>>> internally invoking this api >> >>>>>>>>>>> >> >>>>>>>>>>> Thanks, >> >>>>>>>>>>> -Nitin >> >>>>>>>>>>> >> >>>>>>>>>>> On 19/03/14 1:55 PM, "Mike Tutkowski" < >> >>>>> mike.tutkow...@solidfire.com> >> >>>>>>>>>>> wrote: >> >>>>>>>>>>> >> >>>>>>>>>>>> Hi, >> >>>>>>>>>>>> >> >>>>>>>>>>>> I noticed today while running through some test cases for 4.4 >> >>>>> that >> >>>>>>>>>>>> resetting a VM does not work as expected. >> >>>>>>>>>>>> >> >>>>>>>>>>>> Instead of the typical stop and re-start behavior where the >> VM >> >>>>> is >> >>>>>>>>>>> booted >> >>>>>>>>>>>> back up using the same root disk, the VM gets a new root disk >> >>>>> when >> >>>>>>>>> it >> >>>>>>>>>>> is >> >>>>>>>>>>>> booted back up. >> >>>>>>>>>>>> >> >>>>>>>>>>>> Can anyone confirm this finding for me with his or her setup? >> >>>>>>>>>>>> >> >>>>>>>>>>>> Thanks! >> >>>>>>>>>>>> >> >>>>>>>>>>>> -- >> >>>>>>>>>>>> *Mike Tutkowski* >> >>>>>>>>>>>> *Senior CloudStack Developer, SolidFire Inc.* >> >>>>>>>>>>>> e: mike.tutkow...@solidfire.com >> >>>>>>>>>>>> o: 303.746.7302 >> >>>>>>>>>>>> Advancing the way the world uses the >> >>>>>>>>>>>> cloud<http://solidfire.com/solution/overview/?video=play> >> >>>>>>>>>>>> *(tm)* >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> -- >> >>>>>>>>>> *Mike Tutkowski* >> >>>>>>>>>> *Senior CloudStack Developer, SolidFire Inc.* >> >>>>>>>>>> e: mike.tutkow...@solidfire.com >> >>>>>>>>>> o: 303.746.7302 >> >>>>>>>>>> Advancing the way the world uses the >> >>>>>>>>>> cloud<http://solidfire.com/solution/overview/?video=play> >> >>>>>>>>>> *(tm)* >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> -- >> >>>>>>>> *Mike Tutkowski* >> >>>>>>>> *Senior CloudStack Developer, SolidFire Inc.* >> >>>>>>>> e: mike.tutkow...@solidfire.com >> >>>>>>>> o: 303.746.7302 >> >>>>>>>> Advancing the way the world uses the >> >>>>>>>> cloud<http://solidfire.com/solution/overview/?video=play> >> >>>>>>>> *(tm)* >> >>>>>>> >> >>>>> >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> *Mike Tutkowski* >> >>>> *Senior CloudStack Developer, SolidFire Inc.* >> >>>> e: mike.tutkow...@solidfire.com >> >>>> o: 303.746.7302 >> >>>> Advancing the way the world uses the cloud< >> http://solidfire.com/solution/overview/?video=play> >> >>>> *(tm)* >> >>>> >> >>> >> >>> >> >>> >> >>> -- >> >>> *Mike Tutkowski* >> >>> *Senior CloudStack Developer, SolidFire Inc.* >> >>> e: mike.tutkow...@solidfire.com >> >>> o: 303.746.7302 >> >>> Advancing the way the world uses the cloud< >> http://solidfire.com/solution/overview/?video=play> >> >>> *(tm)* >> >>> >> >> >> >> >> >> >> >> -- >> >> *Mike Tutkowski* >> >> *Senior CloudStack Developer, SolidFire Inc.* >> >> e: mike.tutkow...@solidfire.com >> >> o: 303.746.7302 >> >> Advancing the way the world uses the cloud< >> http://solidfire.com/solution/overview/?video=play> >> >> *(tm)* >> >> >> > >> > >> > >> > -- >> > *Mike Tutkowski* >> > *Senior CloudStack Developer, SolidFire Inc.* >> > e: mike.tutkow...@solidfire.com >> > o: 303.746.7302 >> > Advancing the way the world uses the >> > cloud<http://solidfire.com/solution/overview/?video=play> >> > *(tm)* >> >> > > > -- > *Mike Tutkowski* > *Senior CloudStack Developer, SolidFire Inc.* > e: mike.tutkow...@solidfire.com > o: 303.746.7302 > Advancing the way the world uses the > cloud<http://solidfire.com/solution/overview/?video=play> > *(tm)* > -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play> *(tm)*
