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)*
