Yes Mike, this needs to be fixed with proper popup and mouse over action messages.
-Harikrishna On 20-Mar-2014, at 11:11 am, Mike Tutkowski <mike.tutkow...@solidfire.com> wrote: > 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)*
