You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@cloudstack.apache.org by Mike Tutkowski <mi...@solidfire.com> on 2014/03/19 21:55:36 UTC

Resetting a VM is broken?

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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*

Re: Resetting a VM is broken?

Posted by Nux! <nu...@li.nux.ro>.

On 19.03.2014 21:19, Mike Tutkowski wrote:
> I didn't look into what the GUI calls, but I invoked the Reset VM 
> option in
> the GUI.
> 
> Thanks

That option should be renamed to "reinstall" as it's misleading, it 
re-instantiates a VM from its template AFAIK.

HTH
Lucian

-- 
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

Re: Resetting a VM is broken?

Posted by Harikrishna Patnala <ha...@citrix.com>.

On 20-Mar-2014, at 3:32 am, Alena Prokharchyk <Al...@citrix.com> wrote:

> 1) Didn’t notice “the elephant” - that the Reset Vm option is presented as
> a button unlike the icons for other options. UI folks - Brian/Jessica- why
> we decided to represent this option differently in the UI?
> 
> 2) Mike, I’ve looked at the code and the history. We've always allocated a
> new volume during the vm restore call. Hari, can you please confirm that
> this feature you wrote, was designed to work this way

[Hari] Yes Alena, this is the purpose of this API to restore the VM to fresh root disk or to restore the VM to new root disk if template Id is specified in API
> 
> 
> -Alena.
> 
> 
> On 3/19/14, 2:41 PM, "Mike Tutkowski" <mi...@solidfire.com> wrote:
> 
>> To clarify: Reboot VM seemed to keep the VM running and just reboot the
>> OS.
>> 
>> Reset VM seemed to shut the VM down and then re-start it (with the same
>> root disk for the OS).
>> 
>> 
>> On Wed, Mar 19, 2014 at 3:40 PM, Mike Tutkowski <
>> mike.tutkowski@solidfire.com> wrote:
>> 
>>> I could be wrong, but I thought as recently as 4.3 that Reset VM
>>> essentially stopped and then re-started the VM with the same root disk.
>>> 
>>> It seemed to differ from Reboot VM only in the sense that the VM was
>>> never
>>> technically stopped (the OS inside the VM was just rebooted).
>>> 
>>> 
>>> On Wed, Mar 19, 2014 at 3:38 PM, Mike Tutkowski <
>>> mike.tutkowski@solidfire.com> wrote:
>>> 
>>>> I'm using XenServer 6.1 hosts (two of them) in this case.
>>>> 
>>>> 
>>>> On Wed, Mar 19, 2014 at 3:37 PM, Mike Tutkowski <
>>>> mike.tutkowski@solidfire.com> wrote:
>>>> 
>>>>> Yeah, stopping and restarting works fine...as does, I believe,
>>>>> rebooting
>>>>> the VM.
>>>>> 
>>>>> Right below Reboot VM, there is a Reset VM option.
>>>>> 
>>>>> If that means "re-install," then we probably should clean up the old
>>>>> root disk.
>>>>> 
>>>>> 
>>>>> On Wed, Mar 19, 2014 at 3:30 PM, Alena Prokharchyk <
>>>>> Alena.Prokharchyk@citrix.com> wrote:
>>>>> 
>>>>>> don¹t see ³Reset Vm² option in UI; do you mean ³Reboot instance²?
>>>>>> I¹ve
>>>>>> just tried that, as well as calling stop/startVM from the UI. The Vm
>>>>>> boots
>>>>>> up with its original disk.
>>>>>> 
>>>>>> I¹m having Xen/Nfs, not sure it matters
>>>>>> 
>>>>>> -Alena.
>>>>>> 
>>>>>> On 3/19/14, 2:19 PM, "Mike Tutkowski" <mi...@solidfire.com>
>>>>>> wrote:
>>>>>> 
>>>>>>> I didn't look into what the GUI calls, but I invoked the Reset VM
>>>>>> option
>>>>>>> in
>>>>>>> the GUI.
>>>>>>> 
>>>>>>> Thanks
>>>>>>> 
>>>>>>> 
>>>>>>> On Wed, Mar 19, 2014 at 3:17 PM, Alena Prokharchyk <
>>>>>>> Alena.Prokharchyk@citrix.com> wrote:
>>>>>>> 
>>>>>>>> Mike, just to confirm - did you call
>>>>>>>> stopVirtualMachine/startVirtualMachine apis?
>>>>>>>> 
>>>>>>>> -alena.
>>>>>>>> 
>>>>>>>> On 3/19/14, 1:55 PM, "Mike Tutkowski"
>>>>>> <mi...@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
>> o: 303.746.7302
>> Advancing the way the world uses the
>> cloud<http://solidfire.com/solution/overview/?video=play>
>> *(tm)*
>

RE: Resetting a VM is broken?

Posted by Jessica Wang <Je...@citrix.com>.

Yes, "Reinstall VM" sounds clearer.


-----Original Message-----
From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com] 
Sent: Thursday, March 20, 2014 1:54 PM
To: dev@cloudstack.apache.org
Subject: Re: Resetting a VM is broken?

I also like Reinstall VM for the text (even if it doesn't match the API's
name).


On Thu, Mar 20, 2014 at 2:53 PM, Mike Tutkowski <
mike.tutkowski@solidfire.com> wrote:

> That sounds great. Let's go with your text. Thanks!
>
>
> On Thu, Mar 20, 2014 at 2:51 PM, Nux! <nu...@li.nux.ro> wrote:
>
>> On 20.03.2014 19:35, Mike Tutkowski wrote:
>>
>>> This action will restore the VM to a fresh root disk. After this action,
>>> the
>>> current root disk will be destroyed and un-recoverable.
>>>
>>> Just curious, Lucian - what is your recommended text?
>>>
>>
>> Your text is great, but it sounds like from a dev to a dev.
>>
>> I'd name the button "Reinstall VM" and say something like "The VM will be
>> reinstalled from template, all current data will be lost, proceed with
>> caution!"
>>
>> Sounds more end-user friendly. :)
>>
>>
>> Lucian
>>
>> --
>> Sent from the Delta quadrant using Borg technology!
>>
>> Nux!
>> www.nux.ro
>>
>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*

Re: Resetting a VM is broken?

Posted by Mike Tutkowski <mi...@solidfire.com>.

Cancel this e-mail here! :)

I somehow read Recycle when it clearly says Recover.


On Tue, Mar 25, 2014 at 2:20 PM, Mike Tutkowski <
mike.tutkowski@solidfire.com> wrote:

> Hi,
>
> I noticed today while running a VMware environment (although that probably
> doesn't matter) that when I destroyed, but did not expunge, a VM, I was
> given the option to later expunge it (expected) or recycle it (un-expected).
>
> I wonder if we mean to let the user restore the VM (i.e. un-destroy it)
> instead of recycle it (i.e. create a new root disk for the VM)?
>
> Thanks,
> Mike
>
>
> On Thu, Mar 20, 2014 at 3:47 PM, Mike Tutkowski <
> mike.tutkowski@solidfire.com> wrote:
>
>> Right...that would be great, as well.
>>
>>
>> On Thu, Mar 20, 2014 at 3:45 PM, Jessica Wang <Je...@citrix.com>wrote:
>>
>>>  Also:
>>>
>>> (3) Change Reinstall icon to use a 'recycle' symbol, to avoid confusion
>>> w/ reboot VM
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From:* Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
>>> *Sent:* Thursday, March 20, 2014 2:43 PM
>>> *To:* Jessica Wang
>>> *Cc:* Brian Federle; nux@li.nux.ro; dev@cloudstack.apache.org;
>>> Harikrishna Patnala; Alena Prokharchyk; Stephen Turner
>>>
>>> *Subject:* Re: Resetting a VM is broken?
>>>
>>>
>>>
>>> Works for me. Thanks!
>>>
>>>
>>>
>>> On Thu, Mar 20, 2014 at 3:41 PM, Jessica Wang <Je...@citrix.com>
>>> wrote:
>>>
>>> So, we'll change UI to:
>>>
>>> (1) Label the action icon that fires recoverVirtualMachine API as
>>> "Recover".
>>>     Label the action icon that fires restoreVirtualMachine API as
>>> "Reinstall".
>>>
>>> (2) change text in confirmation dialog of Reinstall action as:
>>> "The VM will be reinstalled from template, all current data will be
>>> lost, proceed with caution! Extra data volumes, if any, will not be
>>> touched."
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Nux! [mailto:nux@li.nux.ro]
>>> Sent: Thursday, March 20, 2014 2:04 PM
>>> To: dev@cloudstack.apache.org
>>> Subject: Re: Resetting a VM is broken?
>>>
>>> On 20.03.2014 20:54, Mike Tutkowski wrote:
>>> > The only technicality is that data on data disks won't be lost (just
>>> > the
>>> > root disk).
>>>
>>> Yes, that is true, we can add something like: "Extra data volumes, if
>>> any, will not be touched."
>>>
>>> HTH
>>>
>>> --
>>> Sent from the Delta quadrant using Borg technology!
>>>
>>> Nux!
>>> www.nux.ro
>>>
>>>
>>>
>>>
>>>
>>> --
>>> *Mike Tutkowski*
>>>
>>> *Senior CloudStack Developer, SolidFire Inc.*
>>>
>>> e: mike.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*

Re: Resetting a VM is broken?

Posted by Mike Tutkowski <mi...@solidfire.com>.

Hi,

I noticed today while running a VMware environment (although that probably
doesn't matter) that when I destroyed, but did not expunge, a VM, I was
given the option to later expunge it (expected) or recycle it (un-expected).

I wonder if we mean to let the user restore the VM (i.e. un-destroy it)
instead of recycle it (i.e. create a new root disk for the VM)?

Thanks,
Mike


On Thu, Mar 20, 2014 at 3:47 PM, Mike Tutkowski <
mike.tutkowski@solidfire.com> wrote:

> Right...that would be great, as well.
>
>
> On Thu, Mar 20, 2014 at 3:45 PM, Jessica Wang <Je...@citrix.com>wrote:
>
>>  Also:
>>
>> (3) Change Reinstall icon to use a 'recycle' symbol, to avoid confusion
>> w/ reboot VM
>>
>>
>>
>>
>>
>>
>>
>> *From:* Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
>> *Sent:* Thursday, March 20, 2014 2:43 PM
>> *To:* Jessica Wang
>> *Cc:* Brian Federle; nux@li.nux.ro; dev@cloudstack.apache.org;
>> Harikrishna Patnala; Alena Prokharchyk; Stephen Turner
>>
>> *Subject:* Re: Resetting a VM is broken?
>>
>>
>>
>> Works for me. Thanks!
>>
>>
>>
>> On Thu, Mar 20, 2014 at 3:41 PM, Jessica Wang <Je...@citrix.com>
>> wrote:
>>
>> So, we'll change UI to:
>>
>> (1) Label the action icon that fires recoverVirtualMachine API as
>> "Recover".
>>     Label the action icon that fires restoreVirtualMachine API as
>> "Reinstall".
>>
>> (2) change text in confirmation dialog of Reinstall action as:
>> "The VM will be reinstalled from template, all current data will be lost,
>> proceed with caution! Extra data volumes, if any, will not be touched."
>>
>>
>>
>>
>> -----Original Message-----
>> From: Nux! [mailto:nux@li.nux.ro]
>> Sent: Thursday, March 20, 2014 2:04 PM
>> To: dev@cloudstack.apache.org
>> Subject: Re: Resetting a VM is broken?
>>
>> On 20.03.2014 20:54, Mike Tutkowski wrote:
>> > The only technicality is that data on data disks won't be lost (just
>> > the
>> > root disk).
>>
>> Yes, that is true, we can add something like: "Extra data volumes, if
>> any, will not be touched."
>>
>> HTH
>>
>> --
>> Sent from the Delta quadrant using Borg technology!
>>
>> Nux!
>> www.nux.ro
>>
>>
>>
>>
>>
>> --
>> *Mike Tutkowski*
>>
>> *Senior CloudStack Developer, SolidFire Inc.*
>>
>> e: mike.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*

Re: Resetting a VM is broken?

Posted by Mike Tutkowski <mi...@solidfire.com>.

Right...that would be great, as well.


On Thu, Mar 20, 2014 at 3:45 PM, Jessica Wang <Je...@citrix.com>wrote:

>  Also:
>
> (3) Change Reinstall icon to use a 'recycle' symbol, to avoid confusion w/
> reboot VM
>
>
>
>
>
>
>
> *From:* Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
> *Sent:* Thursday, March 20, 2014 2:43 PM
> *To:* Jessica Wang
> *Cc:* Brian Federle; nux@li.nux.ro; dev@cloudstack.apache.org;
> Harikrishna Patnala; Alena Prokharchyk; Stephen Turner
>
> *Subject:* Re: Resetting a VM is broken?
>
>
>
> Works for me. Thanks!
>
>
>
> On Thu, Mar 20, 2014 at 3:41 PM, Jessica Wang <Je...@citrix.com>
> wrote:
>
> So, we'll change UI to:
>
> (1) Label the action icon that fires recoverVirtualMachine API as
> "Recover".
>     Label the action icon that fires restoreVirtualMachine API as
> "Reinstall".
>
> (2) change text in confirmation dialog of Reinstall action as:
> "The VM will be reinstalled from template, all current data will be lost,
> proceed with caution! Extra data volumes, if any, will not be touched."
>
>
>
>
> -----Original Message-----
> From: Nux! [mailto:nux@li.nux.ro]
> Sent: Thursday, March 20, 2014 2:04 PM
> To: dev@cloudstack.apache.org
> Subject: Re: Resetting a VM is broken?
>
> On 20.03.2014 20:54, Mike Tutkowski wrote:
> > The only technicality is that data on data disks won't be lost (just
> > the
> > root disk).
>
> Yes, that is true, we can add something like: "Extra data volumes, if
> any, will not be touched."
>
> HTH
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
>
>
>
>
> --
> *Mike Tutkowski*
>
> *Senior CloudStack Developer, SolidFire Inc.*
>
> e: mike.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*

RE: Resetting a VM is broken?

Posted by Jessica Wang <Je...@citrix.com>.

Also:
(3) Change Reinstall icon to use a 'recycle' symbol, to avoid confusion w/ reboot VM

From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
Sent: Thursday, March 20, 2014 2:43 PM
To: Jessica Wang
Cc: Brian Federle; nux@li.nux.ro; dev@cloudstack.apache.org; Harikrishna Patnala; Alena Prokharchyk; Stephen Turner
Subject: Re: Resetting a VM is broken?

Works for me. Thanks!

On Thu, Mar 20, 2014 at 3:41 PM, Jessica Wang <Je...@citrix.com>> wrote:
So, we'll change UI to:

(1) Label the action icon that fires recoverVirtualMachine API as "Recover".
    Label the action icon that fires restoreVirtualMachine API as "Reinstall".

(2) change text in confirmation dialog of Reinstall action as:
"The VM will be reinstalled from template, all current data will be lost, proceed with caution! Extra data volumes, if any, will not be touched."

-----Original Message-----
From: Nux! [mailto:nux@li.nux.ro<ma...@li.nux.ro>]
Sent: Thursday, March 20, 2014 2:04 PM
To: dev@cloudstack.apache.org<ma...@cloudstack.apache.org>
Subject: Re: Resetting a VM is broken?
On 20.03.2014 20:54, Mike Tutkowski wrote:
> The only technicality is that data on data disks won't be lost (just
> the
> root disk).

Yes, that is true, we can add something like: "Extra data volumes, if
any, will not be touched."

HTH

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro<http://www.nux.ro>

--
Mike Tutkowski
Senior CloudStack Developer, SolidFire Inc.
e: mike.tutkowski@solidfire.com<ma...@solidfire.com>
o: 303.746.7302
Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play>(tm)

Re: Resetting a VM is broken?

Posted by Mike Tutkowski <mi...@solidfire.com>.

Works for me. Thanks!


On Thu, Mar 20, 2014 at 3:41 PM, Jessica Wang <Je...@citrix.com>wrote:

> So, we'll change UI to:
>
> (1) Label the action icon that fires recoverVirtualMachine API as
> "Recover".
>     Label the action icon that fires restoreVirtualMachine API as
> "Reinstall".
>
> (2) change text in confirmation dialog of Reinstall action as:
> "The VM will be reinstalled from template, all current data will be lost,
> proceed with caution! Extra data volumes, if any, will not be touched."
>
>
>
> -----Original Message-----
> From: Nux! [mailto:nux@li.nux.ro]
> Sent: Thursday, March 20, 2014 2:04 PM
> To: dev@cloudstack.apache.org
> Subject: Re: Resetting a VM is broken?
>
> On 20.03.2014 20:54, Mike Tutkowski wrote:
> > The only technicality is that data on data disks won't be lost (just
> > the
> > root disk).
>
> Yes, that is true, we can add something like: "Extra data volumes, if
> any, will not be touched."
>
> HTH
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>



-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*

RE: Resetting a VM is broken?

Posted by Jessica Wang <Je...@citrix.com>.

So, we'll change UI to:

(1) Label the action icon that fires recoverVirtualMachine API as "Recover". 
    Label the action icon that fires restoreVirtualMachine API as "Reinstall". 

(2) change text in confirmation dialog of Reinstall action as: 
"The VM will be reinstalled from template, all current data will be lost, proceed with caution! Extra data volumes, if any, will not be touched."



-----Original Message-----
From: Nux! [mailto:nux@li.nux.ro] 
Sent: Thursday, March 20, 2014 2:04 PM
To: dev@cloudstack.apache.org
Subject: Re: Resetting a VM is broken?

On 20.03.2014 20:54, Mike Tutkowski wrote:
> The only technicality is that data on data disks won't be lost (just 
> the
> root disk).

Yes, that is true, we can add something like: "Extra data volumes, if 
any, will not be touched."

HTH

-- 
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

Re: Resetting a VM is broken?

Posted by Nux! <nu...@li.nux.ro>.

On 20.03.2014 20:54, Mike Tutkowski wrote:
> The only technicality is that data on data disks won't be lost (just 
> the
> root disk).

Yes, that is true, we can add something like: "Extra data volumes, if 
any, will not be touched."

HTH

-- 
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

Re: Resetting a VM is broken?

Posted by Mike Tutkowski <mi...@solidfire.com>.

The only technicality is that data on data disks won't be lost (just the
root disk).


On Thu, Mar 20, 2014 at 2:54 PM, Mike Tutkowski <
mike.tutkowski@solidfire.com> wrote:

> I also like Reinstall VM for the text (even if it doesn't match the API's
> name).
>
>
> On Thu, Mar 20, 2014 at 2:53 PM, Mike Tutkowski <
> mike.tutkowski@solidfire.com> wrote:
>
>> That sounds great. Let's go with your text. Thanks!
>>
>>
>> On Thu, Mar 20, 2014 at 2:51 PM, Nux! <nu...@li.nux.ro> wrote:
>>
>>> On 20.03.2014 19:35, Mike Tutkowski wrote:
>>>
>>>> This action will restore the VM to a fresh root disk. After this
>>>> action, the
>>>> current root disk will be destroyed and un-recoverable.
>>>>
>>>> Just curious, Lucian - what is your recommended text?
>>>>
>>>
>>> Your text is great, but it sounds like from a dev to a dev.
>>>
>>> I'd name the button "Reinstall VM" and say something like "The VM will
>>> be reinstalled from template, all current data will be lost, proceed with
>>> caution!"
>>>
>>> Sounds more end-user friendly. :)
>>>
>>>
>>> Lucian
>>>
>>> --
>>> Sent from the Delta quadrant using Borg technology!
>>>
>>> Nux!
>>> www.nux.ro
>>>
>>
>>
>>
>> --
>> *Mike Tutkowski*
>> *Senior CloudStack Developer, SolidFire Inc.*
>> e: mike.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*

Re: Resetting a VM is broken?

Posted by Mike Tutkowski <mi...@solidfire.com>.

I also like Reinstall VM for the text (even if it doesn't match the API's
name).


On Thu, Mar 20, 2014 at 2:53 PM, Mike Tutkowski <
mike.tutkowski@solidfire.com> wrote:

> That sounds great. Let's go with your text. Thanks!
>
>
> On Thu, Mar 20, 2014 at 2:51 PM, Nux! <nu...@li.nux.ro> wrote:
>
>> On 20.03.2014 19:35, Mike Tutkowski wrote:
>>
>>> This action will restore the VM to a fresh root disk. After this action,
>>> the
>>> current root disk will be destroyed and un-recoverable.
>>>
>>> Just curious, Lucian - what is your recommended text?
>>>
>>
>> Your text is great, but it sounds like from a dev to a dev.
>>
>> I'd name the button "Reinstall VM" and say something like "The VM will be
>> reinstalled from template, all current data will be lost, proceed with
>> caution!"
>>
>> Sounds more end-user friendly. :)
>>
>>
>> Lucian
>>
>> --
>> Sent from the Delta quadrant using Borg technology!
>>
>> Nux!
>> www.nux.ro
>>
>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*

RE: Resetting a VM is broken?

Posted by Jessica Wang <Je...@citrix.com>.

+1

-----Original Message-----
From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com] 
Sent: Thursday, March 20, 2014 1:53 PM
To: dev@cloudstack.apache.org
Subject: Re: Resetting a VM is broken?

That sounds great. Let's go with your text. Thanks!


On Thu, Mar 20, 2014 at 2:51 PM, Nux! <nu...@li.nux.ro> wrote:

> On 20.03.2014 19:35, Mike Tutkowski wrote:
>
>> This action will restore the VM to a fresh root disk. After this action,
>> the
>> current root disk will be destroyed and un-recoverable.
>>
>> Just curious, Lucian - what is your recommended text?
>>
>
> Your text is great, but it sounds like from a dev to a dev.
>
> I'd name the button "Reinstall VM" and say something like "The VM will be
> reinstalled from template, all current data will be lost, proceed with
> caution!"
>
> Sounds more end-user friendly. :)
>
>
> Lucian
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>



-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*

Re: Resetting a VM is broken?

Posted by Mike Tutkowski <mi...@solidfire.com>.

That sounds great. Let's go with your text. Thanks!


On Thu, Mar 20, 2014 at 2:51 PM, Nux! <nu...@li.nux.ro> wrote:

> On 20.03.2014 19:35, Mike Tutkowski wrote:
>
>> This action will restore the VM to a fresh root disk. After this action,
>> the
>> current root disk will be destroyed and un-recoverable.
>>
>> Just curious, Lucian - what is your recommended text?
>>
>
> Your text is great, but it sounds like from a dev to a dev.
>
> I'd name the button "Reinstall VM" and say something like "The VM will be
> reinstalled from template, all current data will be lost, proceed with
> caution!"
>
> Sounds more end-user friendly. :)
>
>
> Lucian
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>



-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*

Re: Resetting a VM is broken?

Posted by Nux! <nu...@li.nux.ro>.

On 20.03.2014 19:35, Mike Tutkowski wrote:
> This action will restore the VM to a fresh root disk. After this 
> action, the
> current root disk will be destroyed and un-recoverable.
> 
> Just curious, Lucian - what is your recommended text?

Your text is great, but it sounds like from a dev to a dev.

I'd name the button "Reinstall VM" and say something like "The VM will 
be reinstalled from template, all current data will be lost, proceed 
with caution!"

Sounds more end-user friendly. :)

Lucian

-- 
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

Re: Resetting a VM is broken?

Posted by Mike Tutkowski <mi...@solidfire.com>.

This action will restore the VM to a fresh root disk. After this action, the
current root disk will be destroyed and un-recoverable.

Just curious, Lucian - what is your recommended text?

Thanks


On Thu, Mar 20, 2014 at 1:33 PM, Nux! <nu...@li.nux.ro> wrote:

> On 20.03.2014 19:21, Mike Tutkowski wrote:
>
>> Personally I prefer something more along these lines:
>>
>> This action will restore the VM to a fresh root disk. After this action,
>> the current root disk will be destroyed.
>>
>
> I'm fine with either, I already know what it does. It depends how much you
> want to dumb down the message, to some non-technical users it might not be
> very clear.
>
>
> Just my 2 slips of gold-pressed latinum,
>
> Lucian
>
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>



-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*

Re: Resetting a VM is broken?

Posted by Nux! <nu...@li.nux.ro>.

On 20.03.2014 19:21, Mike Tutkowski wrote:
> Personally I prefer something more along these lines:
> 
> This action will restore the VM to a fresh root disk. After this 
> action,
> the current root disk will be destroyed.

I'm fine with either, I already know what it does. It depends how much 
you want to dumb down the message, to some non-technical users it might 
not be very clear.

Just my 2 slips of gold-pressed latinum,

Lucian

-- 
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

Re: Resetting a VM is broken?

Posted by Mike Tutkowski <mi...@solidfire.com>.

Great - thanks!


On Thu, Mar 20, 2014 at 1:30 PM, Brian Federle <Br...@citrix.com>wrote:

> OK, sounds good :)
> On Mar 20, 2014, at 12:21 PM, Mike Tutkowski <mi...@solidfire.com>
> wrote:
>
> > Personally I prefer something more along these lines:
> >
> > This action will restore the VM to a fresh root disk. After this action,
> > the current root disk will be destroyed.
> >
> >
> > On Thu, Mar 20, 2014 at 1:19 PM, Brian Federle <Brian.Federle@citrix.com
> >wrote:
> >
> >> I was just using what was suggested earlier in the thread (I'm not
> really
> >> familiar with the feature); if that is incorrect then I can change it to
> >> say,
> >>
> >> "Warning: this action is irreversible. If you continue you may lose
> data.
> >> Please confirm that you would like to proceed."
> >>
> >> -Brian
> >>
> >> On Mar 20, 2014, at 12:08 PM, Nux! <nu...@li.nux.ro> wrote:
> >>
> >>> On 20.03.2014 18:55, Brian Federle wrote:
> >>>> Those suggestions sound good. Here are the changes I will make in the
> >> UI:
> >>>> - Change icon to use a 'recycle' symbol, to avoid confusion w/ reboot
> VM
> >>>> - Rename action(s) to reflect the name of the API calls.
> >>>> - Update the confirm dialog to say, "This action will restore the VM
> >>>> to a fresh root disk. After this action, the current root disk will be
> >>>> attached to the VM."
> >>>
> >>> "After this action, the current root disk will be attached to the VM."
> >> <- What does this mean? To me it sounds like the VM gets re-instantiated
> >> from template and the "current" root disk will be attached as a volume,
> in
> >> addition to a _new_ root disk. This is not what is happening.
> >>>
> >>> People need to be aware that this action is irreversible and THEY WILL
> >> LOSE DATA, the message should say this.
> >>>
> >>>
> >>> --
> >>> Sent from the Delta quadrant using Borg technology!
> >>>
> >>> Nux!
> >>> www.nux.ro
> >>
> >>
> >
> >
> > --
> > *Mike Tutkowski*
> > *Senior CloudStack Developer, SolidFire Inc.*
> > e: mike.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*

Re: Resetting a VM is broken?

Posted by Brian Federle <Br...@citrix.com>.

OK, sounds good :)
On Mar 20, 2014, at 12:21 PM, Mike Tutkowski <mi...@solidfire.com> wrote:

> Personally I prefer something more along these lines:
> 
> This action will restore the VM to a fresh root disk. After this action,
> the current root disk will be destroyed.
> 
> 
> On Thu, Mar 20, 2014 at 1:19 PM, Brian Federle <Br...@citrix.com>wrote:
> 
>> I was just using what was suggested earlier in the thread (I'm not really
>> familiar with the feature); if that is incorrect then I can change it to
>> say,
>> 
>> "Warning: this action is irreversible. If you continue you may lose data.
>> Please confirm that you would like to proceed."
>> 
>> -Brian
>> 
>> On Mar 20, 2014, at 12:08 PM, Nux! <nu...@li.nux.ro> wrote:
>> 
>>> On 20.03.2014 18:55, Brian Federle wrote:
>>>> Those suggestions sound good. Here are the changes I will make in the
>> UI:
>>>> - Change icon to use a 'recycle' symbol, to avoid confusion w/ reboot VM
>>>> - Rename action(s) to reflect the name of the API calls.
>>>> - Update the confirm dialog to say, "This action will restore the VM
>>>> to a fresh root disk. After this action, the current root disk will be
>>>> attached to the VM."
>>> 
>>> "After this action, the current root disk will be attached to the VM."
>> <- What does this mean? To me it sounds like the VM gets re-instantiated
>> from template and the "current" root disk will be attached as a volume, in
>> addition to a _new_ root disk. This is not what is happening.
>>> 
>>> People need to be aware that this action is irreversible and THEY WILL
>> LOSE DATA, the message should say this.
>>> 
>>> 
>>> --
>>> Sent from the Delta quadrant using Borg technology!
>>> 
>>> Nux!
>>> www.nux.ro
>> 
>> 
> 
> 
> -- 
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkowski@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud<http://solidfire.com/solution/overview/?video=play>
> *(tm)*

Re: Resetting a VM is broken?

Posted by Mike Tutkowski <mi...@solidfire.com>.

Personally I prefer something more along these lines:

This action will restore the VM to a fresh root disk. After this action,
the current root disk will be destroyed.


On Thu, Mar 20, 2014 at 1:19 PM, Brian Federle <Br...@citrix.com>wrote:

> I was just using what was suggested earlier in the thread (I'm not really
> familiar with the feature); if that is incorrect then I can change it to
> say,
>
> "Warning: this action is irreversible. If you continue you may lose data.
> Please confirm that you would like to proceed."
>
> -Brian
>
> On Mar 20, 2014, at 12:08 PM, Nux! <nu...@li.nux.ro> wrote:
>
> > On 20.03.2014 18:55, Brian Federle wrote:
> >> Those suggestions sound good. Here are the changes I will make in the
> UI:
> >> - Change icon to use a 'recycle' symbol, to avoid confusion w/ reboot VM
> >> - Rename action(s) to reflect the name of the API calls.
> >> - Update the confirm dialog to say, "This action will restore the VM
> >> to a fresh root disk. After this action, the current root disk will be
> >> attached to the VM."
> >
> > "After this action, the current root disk will be attached to the VM."
> <- What does this mean? To me it sounds like the VM gets re-instantiated
> from template and the "current" root disk will be attached as a volume, in
> addition to a _new_ root disk. This is not what is happening.
> >
> > People need to be aware that this action is irreversible and THEY WILL
> LOSE DATA, the message should say this.
> >
> >
> > --
> > Sent from the Delta quadrant using Borg technology!
> >
> > Nux!
> > www.nux.ro
>
>


-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*

Re: Resetting a VM is broken?

Posted by Brian Federle <Br...@citrix.com>.

I was just using what was suggested earlier in the thread (I’m not really familiar with the feature); if that is incorrect then I can change it to say,

“Warning: this action is irreversible. If you continue you may lose data. Please confirm that you would like to proceed.”

-Brian

On Mar 20, 2014, at 12:08 PM, Nux! <nu...@li.nux.ro> wrote:

> On 20.03.2014 18:55, Brian Federle wrote:
>> Those suggestions sound good. Here are the changes I will make in the UI:
>> - Change icon to use a ‘recycle’ symbol, to avoid confusion w/ reboot VM
>> - Rename action(s) to reflect the name of the API calls.
>> - Update the confirm dialog to say, “This action will restore the VM
>> to a fresh root disk. After this action, the current root disk will be
>> attached to the VM.”
> 
> "After this action, the current root disk will be attached to the VM." <- What does this mean? To me it sounds like the VM gets re-instantiated from template and the "current" root disk will be attached as a volume, in addition to a _new_ root disk. This is not what is happening.
> 
> People need to be aware that this action is irreversible and THEY WILL LOSE DATA, the message should say this.
> 
> 
> -- 
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro

Re: Resetting a VM is broken?

Posted by Nux! <nu...@li.nux.ro>.

On 20.03.2014 18:55, Brian Federle wrote:
> Those suggestions sound good. Here are the changes I will make in the 
> UI:
> 
> - Change icon to use a ‘recycle’ symbol, to avoid confusion w/ reboot 
> VM
> - Rename action(s) to reflect the name of the API calls.
> - Update the confirm dialog to say, “This action will restore the VM
> to a fresh root disk. After this action, the current root disk will be
> attached to the VM.”

"After this action, the current root disk will be attached to the VM." 
<- What does this mean? To me it sounds like the VM gets re-instantiated 
from template and the "current" root disk will be attached as a volume, 
in addition to a _new_ root disk. This is not what is happening.

People need to be aware that this action is irreversible and THEY WILL 
LOSE DATA, the message should say this.

-- 
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

Re: Resetting a VM is broken?

Posted by Mike Tutkowski <mi...@solidfire.com>.

Quick question: The current root disk will be attached to the VM.

I interpret that statement (along with the line before it) to mean the old
root disk is replaced by a new root disk and the old root disk will be
attached to the VM as a data disk, which is not the behavior.

The behavior I see could be summarized as follows:

This action will restore the VM to a fresh root disk. After this action,
the current root disk will be destroyed.


On Thu, Mar 20, 2014 at 12:56 PM, Mike Tutkowski <
mike.tutkowski@solidfire.com> wrote:

> Perfect
>
>
> On Thu, Mar 20, 2014 at 12:55 PM, Brian Federle <Br...@citrix.com>wrote:
>
>> Those suggestions sound good. Here are the changes I will make in the UI:
>>
>> - Change icon to use a 'recycle' symbol, to avoid confusion w/ reboot VM
>> - Rename action(s) to reflect the name of the API calls.
>> - Update the confirm dialog to say, "This action will restore the VM to a
>> fresh root disk. After this action, the current root disk will be attached
>> to the VM."
>>
>> -Brian
>>
>> On Mar 20, 2014, at 11:46 AM, Mike Tutkowski <
>> mike.tutkowski@solidfire.com> wrote:
>>
>> > I think with the addition of detailed confirmation info that that is a
>> good
>> > solution.
>> >
>> > Thanks!
>> >
>> >
>> > On Thu, Mar 20, 2014 at 12:44 PM, Jessica Wang <Jessica.Wang@citrix.com
>> >wrote:
>> >
>> >> And also provide detailed info in confirmation dialog when clicking the
>> >> icon that fires restoreVirtualMachine API.
>> >>
>> >> e.g. "This action will restore the VM to a fresh new root disk.
>> >> After this action, the current root disk wll be destroyed and a new
>> root
>> >> disk will be attached to the VM."
>> >>
>> >>
>> >> Harikrishna,
>> >> do you any suggestion for the text in confirmation dialog?
>> >>
>> >>
>> >> -----Original Message-----
>> >> From: Jessica Wang [mailto:Jessica.Wang@citrix.com]
>> >> Sent: Thursday, March 20, 2014 11:32 AM
>> >> To: Mike Tutkowski
>> >> Cc: Brian Federle; Harikrishna Patnala; Alena Prokharchyk;
>> >> dev@cloudstack.apache.org; Stephen Turner
>> >> Subject: RE: Resetting a VM is broken?
>> >>
>> >> How about we just match text with API name?
>> >>
>> >> i. Label the icon that fires recoverVirtualMachine API as "Recover".
>> >> ii. Label the icon that fires restoreVirtualMachine API as "Restore".
>> >>
>> >>
>> >> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
>> >> Sent: Thursday, March 20, 2014 11:29 AM
>> >> To: Jessica Wang
>> >> Cc: Brian Federle; Harikrishna Patnala; Alena Prokharchyk;
>> >> dev@cloudstack.apache.org; Stephen Turner
>> >> Subject: Re: Resetting a VM is broken?
>> >>
>> >> OK, thanks for the history there.
>> >>
>> >> What about the text we're using? Are we OK with Reset VM, for example?
>> >>
>> >> Thanks!
>> >>
>> >> On Thu, Mar 20, 2014 at 12:26 PM, Jessica Wang <
>> Jessica.Wang@citrix.com
>> >> <ma...@citrix.com>> wrote:
>> >> Mike,
>> >>
>> >> Right.
>> >>
>> >> The history is recoverVirtualMachine API was created several years ago,
>> >> restoreVirtualMachine didn't exist yet at that time.
>> >> So, the icon that fires recoverVirtualMachine API was labeled as
>> "Restore"
>> >> at that time.
>> >>
>> >> restoreVirtualMachine API came along several years later.
>> >> Then, since label "Restore" has already taken, the icon that fires
>> >> restoreVirtualMachine API was therefore labeled as "Reset".
>> >>
>> >> The result is indeed weird.
>> >> We'll fix the label to match API name.
>> >>
>> >> Jessica
>> >>
>> >> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com<mailto:
>> >> mike.tutkowski@solidfire.com>]
>> >> Sent: Thursday, March 20, 2014 11:03 AM
>> >> To: Jessica Wang
>> >> Cc: Brian Federle; Harikrishna Patnala; Alena Prokharchyk;
>> >> dev@cloudstack.apache.org<ma...@cloudstack.apache.org>; Stephen
>> >> Turner
>> >>
>> >> Subject: Re: Resetting a VM is broken?
>> >>
>> >> Thanks, Jessica
>> >>
>> >> The even weirder part, though, is that the text Restore maps to the
>> >> recoverVirtualMachine API and the text Reset VM maps to the
>> >> restoreVirtualMachine.
>> >>
>> >> On Thu, Mar 20, 2014 at 11:58 AM, Jessica Wang <
>> Jessica.Wang@citrix.com
>> >> <ma...@citrix.com>> wrote:
>> >>> [Mike Tutkowski] 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
>> >> Yes, this is confusing.
>> >> I'll file an UI bug to match icon label with API name.
>> >> i.e. The icon that fires recoverVirtualMachine API will be labeled as
>> >> "Recover"
>> >> and the icon that fires restoreVirtualMachine API will be labeled as
>> >> "Restore"
>> >>
>> >>
>> >> -----Original Message-----
>> >> From: Brian Federle
>> >> Sent: Thursday, March 20, 2014 10:29 AM
>> >> To: Alena Prokharchyk
>> >> Cc: dev@cloudstack.apache.org<ma...@cloudstack.apache.org>; Brian
>> >> Federle; Jessica Wang; Mike Tutkowski; Harikrishna Patnala
>> >> Subject: Re: Resetting a VM is broken?
>> >>>> the Reset Vm option is presented as a button unlike the icons
>> >> I think this was because all the other icons we tried to represent this
>> >> with were too confusing to users - they were clicking on 'reset VM'
>> >> thinking it was 'reboot VM' - then as a last minute fix the decision
>> was to
>> >> just to show a text label.
>> >>
>> >> Any ideas from anyone on what would be a good icon representation?
>> >>
>> >> -Brian
>> >>
>> >> On Mar 19, 2014, at 3:02 PM, Alena Prokharchyk <
>> >> Alena.Prokharchyk@citrix.com<ma...@citrix.com>>
>> wrote:
>> >>
>> >>> 1) Didn't notice "the elephant" - that the Reset Vm option is
>> presented
>> >> as
>> >>> a button unlike the icons for other options. UI folks - Brian/Jessica-
>> >> why
>> >>> we decided to represent this option differently in the UI?
>> >>>
>> >>> 2) Mike, I've looked at the code and the history. We've always
>> allocated
>> >> a
>> >>> new volume during the vm restore call. Hari, can you please confirm
>> that
>> >>> this feature you wrote, was designed to work this way
>> >>>
>> >>>
>> >>> -Alena.
>> >>>
>> >>>
>> >>> On 3/19/14, 2:41 PM, "Mike Tutkowski" <mike.tutkowski@solidfire.com
>> >> <ma...@solidfire.com>> wrote:
>> >>>
>> >>>> To clarify: Reboot VM seemed to keep the VM running and just reboot
>> the
>> >>>> OS.
>> >>>>
>> >>>> Reset VM seemed to shut the VM down and then re-start it (with the
>> same
>> >>>> root disk for the OS).
>> >>>>
>> >>>>
>> >>>> On Wed, Mar 19, 2014 at 3:40 PM, Mike Tutkowski <
>> >>>> mike.tutkowski@solidfire.com<ma...@solidfire.com>>
>> >> wrote:
>> >>>>
>> >>>>> I could be wrong, but I thought as recently as 4.3 that Reset VM
>> >>>>> essentially stopped and then re-started the VM with the same root
>> disk.
>> >>>>>
>> >>>>> It seemed to differ from Reboot VM only in the sense that the VM was
>> >>>>> never
>> >>>>> technically stopped (the OS inside the VM was just rebooted).
>> >>>>>
>> >>>>>
>> >>>>> On Wed, Mar 19, 2014 at 3:38 PM, Mike Tutkowski <
>> >>>>> mike.tutkowski@solidfire.com<ma...@solidfire.com>>
>> >> wrote:
>> >>>>>
>> >>>>>> I'm using XenServer 6.1 hosts (two of them) in this case.
>> >>>>>>
>> >>>>>>
>> >>>>>> On Wed, Mar 19, 2014 at 3:37 PM, Mike Tutkowski <
>> >>>>>> mike.tutkowski@solidfire.com<ma...@solidfire.com>>
>> >> wrote:
>> >>>>>>
>> >>>>>>> Yeah, stopping and restarting works fine...as does, I believe,
>> >>>>>>> rebooting
>> >>>>>>> the VM.
>> >>>>>>>
>> >>>>>>> Right below Reboot VM, there is a Reset VM option.
>> >>>>>>>
>> >>>>>>> If that means "re-install," then we probably should clean up the
>> old
>> >>>>>>> root disk.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> On Wed, Mar 19, 2014 at 3:30 PM, Alena Prokharchyk <
>> >>>>>>> Alena.Prokharchyk@citrix.com<mailto:Alena.Prokharchyk@citrix.com
>> >>
>> >> wrote:
>> >>>>>>>
>> >>>>>>>> don¹t see ³Reset Vm² option in UI; do you mean ³Reboot instance²?
>> >>>>>>>> I¹ve
>> >>>>>>>> just tried that, as well as calling stop/startVM from the UI.
>> The Vm
>> >>>>>>>> boots
>> >>>>>>>> up with its original disk.
>> >>>>>>>>
>> >>>>>>>> I¹m having Xen/Nfs, not sure it matters
>> >>>>>>>>
>> >>>>>>>> -Alena.
>> >>>>>>>>
>> >>>>>>>> On 3/19/14, 2:19 PM, "Mike Tutkowski" <
>> mike.tutkowski@solidfire.com
>> >> <ma...@solidfire.com>>
>> >>>>>>>> wrote:
>> >>>>>>>>
>> >>>>>>>>> I didn't look into what the GUI calls, but I invoked the Reset
>> VM
>> >>>>>>>> option
>> >>>>>>>>> in
>> >>>>>>>>> the GUI.
>> >>>>>>>>>
>> >>>>>>>>> Thanks
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> On Wed, Mar 19, 2014 at 3:17 PM, Alena Prokharchyk <
>> >>>>>>>>> Alena.Prokharchyk@citrix.com<mailto:
>> Alena.Prokharchyk@citrix.com>>
>> >> wrote:
>> >>>>>>>>>
>> >>>>>>>>>> Mike, just to confirm - did you call
>> >>>>>>>>>> stopVirtualMachine/startVirtualMachine apis?
>> >>>>>>>>>>
>> >>>>>>>>>> -alena.
>> >>>>>>>>>>
>> >>>>>>>>>> On 3/19/14, 1:55 PM, "Mike Tutkowski"
>> >>>>>>>> <mike.tutkowski@solidfire.com<mailto:
>> mike.tutkowski@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.tutkowski@solidfire.com<mailto:
>> >> mike.tutkowski@solidfire.com>
>> >>>>>>>>>>> o: 303.746.7302<tel: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.tutkowski@solidfire.com<mailto:
>> >> mike.tutkowski@solidfire.com>
>> >>>>>>>>> o: 303.746.7302<tel: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.tutkowski@solidfire.com<mailto:
>> mike.tutkowski@solidfire.com>
>> >>>>>>> o: 303.746.7302<tel: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.tutkowski@solidfire.com<mailto:
>> mike.tutkowski@solidfire.com>
>> >>>>>> o: 303.746.7302<tel: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.tutkowski@solidfire.com<mailto:mike.tutkowski@solidfire.com
>> >
>> >>>>> o: 303.746.7302<tel: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.tutkowski@solidfire.com<ma...@solidfire.com>
>> >>>> o: 303.746.7302<tel: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.tutkowski@solidfire.com<ma...@solidfire.com>
>> >> o: 303.746.7302<tel: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.tutkowski@solidfire.com<ma...@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*

Re: Resetting a VM is broken?

Posted by Mike Tutkowski <mi...@solidfire.com>.

Perfect


On Thu, Mar 20, 2014 at 12:55 PM, Brian Federle <Br...@citrix.com>wrote:

> Those suggestions sound good. Here are the changes I will make in the UI:
>
> - Change icon to use a 'recycle' symbol, to avoid confusion w/ reboot VM
> - Rename action(s) to reflect the name of the API calls.
> - Update the confirm dialog to say, "This action will restore the VM to a
> fresh root disk. After this action, the current root disk will be attached
> to the VM."
>
> -Brian
>
> On Mar 20, 2014, at 11:46 AM, Mike Tutkowski <mi...@solidfire.com>
> wrote:
>
> > I think with the addition of detailed confirmation info that that is a
> good
> > solution.
> >
> > Thanks!
> >
> >
> > On Thu, Mar 20, 2014 at 12:44 PM, Jessica Wang <Jessica.Wang@citrix.com
> >wrote:
> >
> >> And also provide detailed info in confirmation dialog when clicking the
> >> icon that fires restoreVirtualMachine API.
> >>
> >> e.g. "This action will restore the VM to a fresh new root disk.
> >> After this action, the current root disk wll be destroyed and a new root
> >> disk will be attached to the VM."
> >>
> >>
> >> Harikrishna,
> >> do you any suggestion for the text in confirmation dialog?
> >>
> >>
> >> -----Original Message-----
> >> From: Jessica Wang [mailto:Jessica.Wang@citrix.com]
> >> Sent: Thursday, March 20, 2014 11:32 AM
> >> To: Mike Tutkowski
> >> Cc: Brian Federle; Harikrishna Patnala; Alena Prokharchyk;
> >> dev@cloudstack.apache.org; Stephen Turner
> >> Subject: RE: Resetting a VM is broken?
> >>
> >> How about we just match text with API name?
> >>
> >> i. Label the icon that fires recoverVirtualMachine API as "Recover".
> >> ii. Label the icon that fires restoreVirtualMachine API as "Restore".
> >>
> >>
> >> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
> >> Sent: Thursday, March 20, 2014 11:29 AM
> >> To: Jessica Wang
> >> Cc: Brian Federle; Harikrishna Patnala; Alena Prokharchyk;
> >> dev@cloudstack.apache.org; Stephen Turner
> >> Subject: Re: Resetting a VM is broken?
> >>
> >> OK, thanks for the history there.
> >>
> >> What about the text we're using? Are we OK with Reset VM, for example?
> >>
> >> Thanks!
> >>
> >> On Thu, Mar 20, 2014 at 12:26 PM, Jessica Wang <Jessica.Wang@citrix.com
> >> <ma...@citrix.com>> wrote:
> >> Mike,
> >>
> >> Right.
> >>
> >> The history is recoverVirtualMachine API was created several years ago,
> >> restoreVirtualMachine didn't exist yet at that time.
> >> So, the icon that fires recoverVirtualMachine API was labeled as
> "Restore"
> >> at that time.
> >>
> >> restoreVirtualMachine API came along several years later.
> >> Then, since label "Restore" has already taken, the icon that fires
> >> restoreVirtualMachine API was therefore labeled as "Reset".
> >>
> >> The result is indeed weird.
> >> We'll fix the label to match API name.
> >>
> >> Jessica
> >>
> >> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com<mailto:
> >> mike.tutkowski@solidfire.com>]
> >> Sent: Thursday, March 20, 2014 11:03 AM
> >> To: Jessica Wang
> >> Cc: Brian Federle; Harikrishna Patnala; Alena Prokharchyk;
> >> dev@cloudstack.apache.org<ma...@cloudstack.apache.org>; Stephen
> >> Turner
> >>
> >> Subject: Re: Resetting a VM is broken?
> >>
> >> Thanks, Jessica
> >>
> >> The even weirder part, though, is that the text Restore maps to the
> >> recoverVirtualMachine API and the text Reset VM maps to the
> >> restoreVirtualMachine.
> >>
> >> On Thu, Mar 20, 2014 at 11:58 AM, Jessica Wang <Jessica.Wang@citrix.com
> >> <ma...@citrix.com>> wrote:
> >>> [Mike Tutkowski] 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
> >> Yes, this is confusing.
> >> I'll file an UI bug to match icon label with API name.
> >> i.e. The icon that fires recoverVirtualMachine API will be labeled as
> >> "Recover"
> >> and the icon that fires restoreVirtualMachine API will be labeled as
> >> "Restore"
> >>
> >>
> >> -----Original Message-----
> >> From: Brian Federle
> >> Sent: Thursday, March 20, 2014 10:29 AM
> >> To: Alena Prokharchyk
> >> Cc: dev@cloudstack.apache.org<ma...@cloudstack.apache.org>; Brian
> >> Federle; Jessica Wang; Mike Tutkowski; Harikrishna Patnala
> >> Subject: Re: Resetting a VM is broken?
> >>>> the Reset Vm option is presented as a button unlike the icons
> >> I think this was because all the other icons we tried to represent this
> >> with were too confusing to users - they were clicking on 'reset VM'
> >> thinking it was 'reboot VM' - then as a last minute fix the decision
> was to
> >> just to show a text label.
> >>
> >> Any ideas from anyone on what would be a good icon representation?
> >>
> >> -Brian
> >>
> >> On Mar 19, 2014, at 3:02 PM, Alena Prokharchyk <
> >> Alena.Prokharchyk@citrix.com<ma...@citrix.com>>
> wrote:
> >>
> >>> 1) Didn't notice "the elephant" - that the Reset Vm option is presented
> >> as
> >>> a button unlike the icons for other options. UI folks - Brian/Jessica-
> >> why
> >>> we decided to represent this option differently in the UI?
> >>>
> >>> 2) Mike, I've looked at the code and the history. We've always
> allocated
> >> a
> >>> new volume during the vm restore call. Hari, can you please confirm
> that
> >>> this feature you wrote, was designed to work this way
> >>>
> >>>
> >>> -Alena.
> >>>
> >>>
> >>> On 3/19/14, 2:41 PM, "Mike Tutkowski" <mike.tutkowski@solidfire.com
> >> <ma...@solidfire.com>> wrote:
> >>>
> >>>> To clarify: Reboot VM seemed to keep the VM running and just reboot
> the
> >>>> OS.
> >>>>
> >>>> Reset VM seemed to shut the VM down and then re-start it (with the
> same
> >>>> root disk for the OS).
> >>>>
> >>>>
> >>>> On Wed, Mar 19, 2014 at 3:40 PM, Mike Tutkowski <
> >>>> mike.tutkowski@solidfire.com<ma...@solidfire.com>>
> >> wrote:
> >>>>
> >>>>> I could be wrong, but I thought as recently as 4.3 that Reset VM
> >>>>> essentially stopped and then re-started the VM with the same root
> disk.
> >>>>>
> >>>>> It seemed to differ from Reboot VM only in the sense that the VM was
> >>>>> never
> >>>>> technically stopped (the OS inside the VM was just rebooted).
> >>>>>
> >>>>>
> >>>>> On Wed, Mar 19, 2014 at 3:38 PM, Mike Tutkowski <
> >>>>> mike.tutkowski@solidfire.com<ma...@solidfire.com>>
> >> wrote:
> >>>>>
> >>>>>> I'm using XenServer 6.1 hosts (two of them) in this case.
> >>>>>>
> >>>>>>
> >>>>>> On Wed, Mar 19, 2014 at 3:37 PM, Mike Tutkowski <
> >>>>>> mike.tutkowski@solidfire.com<ma...@solidfire.com>>
> >> wrote:
> >>>>>>
> >>>>>>> Yeah, stopping and restarting works fine...as does, I believe,
> >>>>>>> rebooting
> >>>>>>> the VM.
> >>>>>>>
> >>>>>>> Right below Reboot VM, there is a Reset VM option.
> >>>>>>>
> >>>>>>> If that means "re-install," then we probably should clean up the
> old
> >>>>>>> root disk.
> >>>>>>>
> >>>>>>>
> >>>>>>> On Wed, Mar 19, 2014 at 3:30 PM, Alena Prokharchyk <
> >>>>>>> Alena.Prokharchyk@citrix.com<ma...@citrix.com>>
> >> wrote:
> >>>>>>>
> >>>>>>>> don¹t see ³Reset Vm² option in UI; do you mean ³Reboot instance²?
> >>>>>>>> I¹ve
> >>>>>>>> just tried that, as well as calling stop/startVM from the UI. The
> Vm
> >>>>>>>> boots
> >>>>>>>> up with its original disk.
> >>>>>>>>
> >>>>>>>> I¹m having Xen/Nfs, not sure it matters
> >>>>>>>>
> >>>>>>>> -Alena.
> >>>>>>>>
> >>>>>>>> On 3/19/14, 2:19 PM, "Mike Tutkowski" <
> mike.tutkowski@solidfire.com
> >> <ma...@solidfire.com>>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> I didn't look into what the GUI calls, but I invoked the Reset VM
> >>>>>>>> option
> >>>>>>>>> in
> >>>>>>>>> the GUI.
> >>>>>>>>>
> >>>>>>>>> Thanks
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Wed, Mar 19, 2014 at 3:17 PM, Alena Prokharchyk <
> >>>>>>>>> Alena.Prokharchyk@citrix.com<mailto:Alena.Prokharchyk@citrix.com
> >>
> >> wrote:
> >>>>>>>>>
> >>>>>>>>>> Mike, just to confirm - did you call
> >>>>>>>>>> stopVirtualMachine/startVirtualMachine apis?
> >>>>>>>>>>
> >>>>>>>>>> -alena.
> >>>>>>>>>>
> >>>>>>>>>> On 3/19/14, 1:55 PM, "Mike Tutkowski"
> >>>>>>>> <mike.tutkowski@solidfire.com<mailto:mike.tutkowski@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.tutkowski@solidfire.com<mailto:
> >> mike.tutkowski@solidfire.com>
> >>>>>>>>>>> o: 303.746.7302<tel: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.tutkowski@solidfire.com<mailto:
> >> mike.tutkowski@solidfire.com>
> >>>>>>>>> o: 303.746.7302<tel: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.tutkowski@solidfire.com<mailto:
> mike.tutkowski@solidfire.com>
> >>>>>>> o: 303.746.7302<tel: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.tutkowski@solidfire.com<mailto:mike.tutkowski@solidfire.com
> >
> >>>>>> o: 303.746.7302<tel: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.tutkowski@solidfire.com<ma...@solidfire.com>
> >>>>> o: 303.746.7302<tel: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.tutkowski@solidfire.com<ma...@solidfire.com>
> >>>> o: 303.746.7302<tel: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.tutkowski@solidfire.com<ma...@solidfire.com>
> >> o: 303.746.7302<tel: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.tutkowski@solidfire.com<ma...@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*

Re: Resetting a VM is broken?

Posted by Brian Federle <Br...@citrix.com>.

Those suggestions sound good. Here are the changes I will make in the UI:

- Change icon to use a ‘recycle’ symbol, to avoid confusion w/ reboot VM
- Rename action(s) to reflect the name of the API calls.
- Update the confirm dialog to say, “This action will restore the VM to a fresh root disk. After this action, the current root disk will be attached to the VM.”

-Brian
 
On Mar 20, 2014, at 11:46 AM, Mike Tutkowski <mi...@solidfire.com> wrote:

> I think with the addition of detailed confirmation info that that is a good
> solution.
> 
> Thanks!
> 
> 
> On Thu, Mar 20, 2014 at 12:44 PM, Jessica Wang <Je...@citrix.com>wrote:
> 
>> And also provide detailed info in confirmation dialog when clicking the
>> icon that fires restoreVirtualMachine API.
>> 
>> e.g. "This action will restore the VM to a fresh new root disk.
>> After this action, the current root disk wll be destroyed and a new root
>> disk will be attached to the VM."
>> 
>> 
>> Harikrishna,
>> do you any suggestion for the text in confirmation dialog?
>> 
>> 
>> -----Original Message-----
>> From: Jessica Wang [mailto:Jessica.Wang@citrix.com]
>> Sent: Thursday, March 20, 2014 11:32 AM
>> To: Mike Tutkowski
>> Cc: Brian Federle; Harikrishna Patnala; Alena Prokharchyk;
>> dev@cloudstack.apache.org; Stephen Turner
>> Subject: RE: Resetting a VM is broken?
>> 
>> How about we just match text with API name?
>> 
>> i. Label the icon that fires recoverVirtualMachine API as "Recover".
>> ii. Label the icon that fires restoreVirtualMachine API as "Restore".
>> 
>> 
>> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
>> Sent: Thursday, March 20, 2014 11:29 AM
>> To: Jessica Wang
>> Cc: Brian Federle; Harikrishna Patnala; Alena Prokharchyk;
>> dev@cloudstack.apache.org; Stephen Turner
>> Subject: Re: Resetting a VM is broken?
>> 
>> OK, thanks for the history there.
>> 
>> What about the text we're using? Are we OK with Reset VM, for example?
>> 
>> Thanks!
>> 
>> On Thu, Mar 20, 2014 at 12:26 PM, Jessica Wang <Jessica.Wang@citrix.com
>> <ma...@citrix.com>> wrote:
>> Mike,
>> 
>> Right.
>> 
>> The history is recoverVirtualMachine API was created several years ago,
>> restoreVirtualMachine didn't exist yet at that time.
>> So, the icon that fires recoverVirtualMachine API was labeled as "Restore"
>> at that time.
>> 
>> restoreVirtualMachine API came along several years later.
>> Then, since label "Restore" has already taken, the icon that fires
>> restoreVirtualMachine API was therefore labeled as "Reset".
>> 
>> The result is indeed weird.
>> We'll fix the label to match API name.
>> 
>> Jessica
>> 
>> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com<mailto:
>> mike.tutkowski@solidfire.com>]
>> Sent: Thursday, March 20, 2014 11:03 AM
>> To: Jessica Wang
>> Cc: Brian Federle; Harikrishna Patnala; Alena Prokharchyk;
>> dev@cloudstack.apache.org<ma...@cloudstack.apache.org>; Stephen
>> Turner
>> 
>> Subject: Re: Resetting a VM is broken?
>> 
>> Thanks, Jessica
>> 
>> The even weirder part, though, is that the text Restore maps to the
>> recoverVirtualMachine API and the text Reset VM maps to the
>> restoreVirtualMachine.
>> 
>> On Thu, Mar 20, 2014 at 11:58 AM, Jessica Wang <Jessica.Wang@citrix.com
>> <ma...@citrix.com>> wrote:
>>> [Mike Tutkowski] 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
>> Yes, this is confusing.
>> I'll file an UI bug to match icon label with API name.
>> i.e. The icon that fires recoverVirtualMachine API will be labeled as
>> "Recover"
>> and the icon that fires restoreVirtualMachine API will be labeled as
>> "Restore"
>> 
>> 
>> -----Original Message-----
>> From: Brian Federle
>> Sent: Thursday, March 20, 2014 10:29 AM
>> To: Alena Prokharchyk
>> Cc: dev@cloudstack.apache.org<ma...@cloudstack.apache.org>; Brian
>> Federle; Jessica Wang; Mike Tutkowski; Harikrishna Patnala
>> Subject: Re: Resetting a VM is broken?
>>>> the Reset Vm option is presented as a button unlike the icons
>> I think this was because all the other icons we tried to represent this
>> with were too confusing to users - they were clicking on 'reset VM'
>> thinking it was 'reboot VM' - then as a last minute fix the decision was to
>> just to show a text label.
>> 
>> Any ideas from anyone on what would be a good icon representation?
>> 
>> -Brian
>> 
>> On Mar 19, 2014, at 3:02 PM, Alena Prokharchyk <
>> Alena.Prokharchyk@citrix.com<ma...@citrix.com>> wrote:
>> 
>>> 1) Didn't notice "the elephant" - that the Reset Vm option is presented
>> as
>>> a button unlike the icons for other options. UI folks - Brian/Jessica-
>> why
>>> we decided to represent this option differently in the UI?
>>> 
>>> 2) Mike, I've looked at the code and the history. We've always allocated
>> a
>>> new volume during the vm restore call. Hari, can you please confirm that
>>> this feature you wrote, was designed to work this way
>>> 
>>> 
>>> -Alena.
>>> 
>>> 
>>> On 3/19/14, 2:41 PM, "Mike Tutkowski" <mike.tutkowski@solidfire.com
>> <ma...@solidfire.com>> wrote:
>>> 
>>>> To clarify: Reboot VM seemed to keep the VM running and just reboot the
>>>> OS.
>>>> 
>>>> Reset VM seemed to shut the VM down and then re-start it (with the same
>>>> root disk for the OS).
>>>> 
>>>> 
>>>> On Wed, Mar 19, 2014 at 3:40 PM, Mike Tutkowski <
>>>> mike.tutkowski@solidfire.com<ma...@solidfire.com>>
>> wrote:
>>>> 
>>>>> I could be wrong, but I thought as recently as 4.3 that Reset VM
>>>>> essentially stopped and then re-started the VM with the same root disk.
>>>>> 
>>>>> It seemed to differ from Reboot VM only in the sense that the VM was
>>>>> never
>>>>> technically stopped (the OS inside the VM was just rebooted).
>>>>> 
>>>>> 
>>>>> On Wed, Mar 19, 2014 at 3:38 PM, Mike Tutkowski <
>>>>> mike.tutkowski@solidfire.com<ma...@solidfire.com>>
>> wrote:
>>>>> 
>>>>>> I'm using XenServer 6.1 hosts (two of them) in this case.
>>>>>> 
>>>>>> 
>>>>>> On Wed, Mar 19, 2014 at 3:37 PM, Mike Tutkowski <
>>>>>> mike.tutkowski@solidfire.com<ma...@solidfire.com>>
>> wrote:
>>>>>> 
>>>>>>> Yeah, stopping and restarting works fine...as does, I believe,
>>>>>>> rebooting
>>>>>>> the VM.
>>>>>>> 
>>>>>>> Right below Reboot VM, there is a Reset VM option.
>>>>>>> 
>>>>>>> If that means "re-install," then we probably should clean up the old
>>>>>>> root disk.
>>>>>>> 
>>>>>>> 
>>>>>>> On Wed, Mar 19, 2014 at 3:30 PM, Alena Prokharchyk <
>>>>>>> Alena.Prokharchyk@citrix.com<ma...@citrix.com>>
>> wrote:
>>>>>>> 
>>>>>>>> don¹t see ³Reset Vm² option in UI; do you mean ³Reboot instance²?
>>>>>>>> I¹ve
>>>>>>>> just tried that, as well as calling stop/startVM from the UI. The Vm
>>>>>>>> boots
>>>>>>>> up with its original disk.
>>>>>>>> 
>>>>>>>> I¹m having Xen/Nfs, not sure it matters
>>>>>>>> 
>>>>>>>> -Alena.
>>>>>>>> 
>>>>>>>> On 3/19/14, 2:19 PM, "Mike Tutkowski" <mike.tutkowski@solidfire.com
>> <ma...@solidfire.com>>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> I didn't look into what the GUI calls, but I invoked the Reset VM
>>>>>>>> option
>>>>>>>>> in
>>>>>>>>> the GUI.
>>>>>>>>> 
>>>>>>>>> Thanks
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Wed, Mar 19, 2014 at 3:17 PM, Alena Prokharchyk <
>>>>>>>>> Alena.Prokharchyk@citrix.com<ma...@citrix.com>>
>> wrote:
>>>>>>>>> 
>>>>>>>>>> Mike, just to confirm - did you call
>>>>>>>>>> stopVirtualMachine/startVirtualMachine apis?
>>>>>>>>>> 
>>>>>>>>>> -alena.
>>>>>>>>>> 
>>>>>>>>>> On 3/19/14, 1:55 PM, "Mike Tutkowski"
>>>>>>>> <mi...@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.tutkowski@solidfire.com<mailto:
>> mike.tutkowski@solidfire.com>
>>>>>>>>>>> o: 303.746.7302<tel: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.tutkowski@solidfire.com<mailto:
>> mike.tutkowski@solidfire.com>
>>>>>>>>> o: 303.746.7302<tel: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.tutkowski@solidfire.com<ma...@solidfire.com>
>>>>>>> o: 303.746.7302<tel: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.tutkowski@solidfire.com<ma...@solidfire.com>
>>>>>> o: 303.746.7302<tel: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.tutkowski@solidfire.com<ma...@solidfire.com>
>>>>> o: 303.746.7302<tel: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.tutkowski@solidfire.com<ma...@solidfire.com>
>>>> o: 303.746.7302<tel: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.tutkowski@solidfire.com<ma...@solidfire.com>
>> o: 303.746.7302<tel: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.tutkowski@solidfire.com<ma...@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.tutkowski@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud<http://solidfire.com/solution/overview/?video=play>
> *(tm)*

Re: Resetting a VM is broken?

Posted by Mike Tutkowski <mi...@solidfire.com>.

I think with the addition of detailed confirmation info that that is a good
solution.

Thanks!


On Thu, Mar 20, 2014 at 12:44 PM, Jessica Wang <Je...@citrix.com>wrote:

> And also provide detailed info in confirmation dialog when clicking the
> icon that fires restoreVirtualMachine API.
>
> e.g. "This action will restore the VM to a fresh new root disk.
> After this action, the current root disk wll be destroyed and a new root
> disk will be attached to the VM."
>
>
> Harikrishna,
> do you any suggestion for the text in confirmation dialog?
>
>
> -----Original Message-----
> From: Jessica Wang [mailto:Jessica.Wang@citrix.com]
> Sent: Thursday, March 20, 2014 11:32 AM
> To: Mike Tutkowski
> Cc: Brian Federle; Harikrishna Patnala; Alena Prokharchyk;
> dev@cloudstack.apache.org; Stephen Turner
> Subject: RE: Resetting a VM is broken?
>
> How about we just match text with API name?
>
> i. Label the icon that fires recoverVirtualMachine API as "Recover".
> ii. Label the icon that fires restoreVirtualMachine API as "Restore".
>
>
> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
> Sent: Thursday, March 20, 2014 11:29 AM
> To: Jessica Wang
> Cc: Brian Federle; Harikrishna Patnala; Alena Prokharchyk;
> dev@cloudstack.apache.org; Stephen Turner
> Subject: Re: Resetting a VM is broken?
>
> OK, thanks for the history there.
>
> What about the text we're using? Are we OK with Reset VM, for example?
>
> Thanks!
>
> On Thu, Mar 20, 2014 at 12:26 PM, Jessica Wang <Jessica.Wang@citrix.com
> <ma...@citrix.com>> wrote:
> Mike,
>
> Right.
>
> The history is recoverVirtualMachine API was created several years ago,
> restoreVirtualMachine didn't exist yet at that time.
> So, the icon that fires recoverVirtualMachine API was labeled as "Restore"
> at that time.
>
> restoreVirtualMachine API came along several years later.
> Then, since label "Restore" has already taken, the icon that fires
> restoreVirtualMachine API was therefore labeled as "Reset".
>
> The result is indeed weird.
> We'll fix the label to match API name.
>
> Jessica
>
> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com<mailto:
> mike.tutkowski@solidfire.com>]
> Sent: Thursday, March 20, 2014 11:03 AM
> To: Jessica Wang
> Cc: Brian Federle; Harikrishna Patnala; Alena Prokharchyk;
> dev@cloudstack.apache.org<ma...@cloudstack.apache.org>; Stephen
> Turner
>
> Subject: Re: Resetting a VM is broken?
>
> Thanks, Jessica
>
> The even weirder part, though, is that the text Restore maps to the
> recoverVirtualMachine API and the text Reset VM maps to the
> restoreVirtualMachine.
>
> On Thu, Mar 20, 2014 at 11:58 AM, Jessica Wang <Jessica.Wang@citrix.com
> <ma...@citrix.com>> wrote:
> > [Mike Tutkowski] 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
> Yes, this is confusing.
> I'll file an UI bug to match icon label with API name.
> i.e. The icon that fires recoverVirtualMachine API will be labeled as
> "Recover"
> and the icon that fires restoreVirtualMachine API will be labeled as
> "Restore"
>
>
> -----Original Message-----
> From: Brian Federle
> Sent: Thursday, March 20, 2014 10:29 AM
> To: Alena Prokharchyk
> Cc: dev@cloudstack.apache.org<ma...@cloudstack.apache.org>; Brian
> Federle; Jessica Wang; Mike Tutkowski; Harikrishna Patnala
> Subject: Re: Resetting a VM is broken?
> >> the Reset Vm option is presented as a button unlike the icons
> I think this was because all the other icons we tried to represent this
> with were too confusing to users - they were clicking on 'reset VM'
> thinking it was 'reboot VM' - then as a last minute fix the decision was to
> just to show a text label.
>
> Any ideas from anyone on what would be a good icon representation?
>
> -Brian
>
> On Mar 19, 2014, at 3:02 PM, Alena Prokharchyk <
> Alena.Prokharchyk@citrix.com<ma...@citrix.com>> wrote:
>
> > 1) Didn't notice "the elephant" - that the Reset Vm option is presented
> as
> > a button unlike the icons for other options. UI folks - Brian/Jessica-
> why
> > we decided to represent this option differently in the UI?
> >
> > 2) Mike, I've looked at the code and the history. We've always allocated
> a
> > new volume during the vm restore call. Hari, can you please confirm that
> > this feature you wrote, was designed to work this way
> >
> >
> > -Alena.
> >
> >
> > On 3/19/14, 2:41 PM, "Mike Tutkowski" <mike.tutkowski@solidfire.com
> <ma...@solidfire.com>> wrote:
> >
> >> To clarify: Reboot VM seemed to keep the VM running and just reboot the
> >> OS.
> >>
> >> Reset VM seemed to shut the VM down and then re-start it (with the same
> >> root disk for the OS).
> >>
> >>
> >> On Wed, Mar 19, 2014 at 3:40 PM, Mike Tutkowski <
> >> mike.tutkowski@solidfire.com<ma...@solidfire.com>>
> wrote:
> >>
> >>> I could be wrong, but I thought as recently as 4.3 that Reset VM
> >>> essentially stopped and then re-started the VM with the same root disk.
> >>>
> >>> It seemed to differ from Reboot VM only in the sense that the VM was
> >>> never
> >>> technically stopped (the OS inside the VM was just rebooted).
> >>>
> >>>
> >>> On Wed, Mar 19, 2014 at 3:38 PM, Mike Tutkowski <
> >>> mike.tutkowski@solidfire.com<ma...@solidfire.com>>
> wrote:
> >>>
> >>>> I'm using XenServer 6.1 hosts (two of them) in this case.
> >>>>
> >>>>
> >>>> On Wed, Mar 19, 2014 at 3:37 PM, Mike Tutkowski <
> >>>> mike.tutkowski@solidfire.com<ma...@solidfire.com>>
> wrote:
> >>>>
> >>>>> Yeah, stopping and restarting works fine...as does, I believe,
> >>>>> rebooting
> >>>>> the VM.
> >>>>>
> >>>>> Right below Reboot VM, there is a Reset VM option.
> >>>>>
> >>>>> If that means "re-install," then we probably should clean up the old
> >>>>> root disk.
> >>>>>
> >>>>>
> >>>>> On Wed, Mar 19, 2014 at 3:30 PM, Alena Prokharchyk <
> >>>>> Alena.Prokharchyk@citrix.com<ma...@citrix.com>>
> wrote:
> >>>>>
> >>>>>> don¹t see ³Reset Vm² option in UI; do you mean ³Reboot instance²?
> >>>>>> I¹ve
> >>>>>> just tried that, as well as calling stop/startVM from the UI. The Vm
> >>>>>> boots
> >>>>>> up with its original disk.
> >>>>>>
> >>>>>> I¹m having Xen/Nfs, not sure it matters
> >>>>>>
> >>>>>> -Alena.
> >>>>>>
> >>>>>> On 3/19/14, 2:19 PM, "Mike Tutkowski" <mike.tutkowski@solidfire.com
> <ma...@solidfire.com>>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> I didn't look into what the GUI calls, but I invoked the Reset VM
> >>>>>> option
> >>>>>>> in
> >>>>>>> the GUI.
> >>>>>>>
> >>>>>>> Thanks
> >>>>>>>
> >>>>>>>
> >>>>>>> On Wed, Mar 19, 2014 at 3:17 PM, Alena Prokharchyk <
> >>>>>>> Alena.Prokharchyk@citrix.com<ma...@citrix.com>>
> wrote:
> >>>>>>>
> >>>>>>>> Mike, just to confirm - did you call
> >>>>>>>> stopVirtualMachine/startVirtualMachine apis?
> >>>>>>>>
> >>>>>>>> -alena.
> >>>>>>>>
> >>>>>>>> On 3/19/14, 1:55 PM, "Mike Tutkowski"
> >>>>>> <mi...@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.tutkowski@solidfire.com<mailto:
> mike.tutkowski@solidfire.com>
> >>>>>>>>> o: 303.746.7302<tel: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.tutkowski@solidfire.com<mailto:
> mike.tutkowski@solidfire.com>
> >>>>>>> o: 303.746.7302<tel: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.tutkowski@solidfire.com<ma...@solidfire.com>
> >>>>> o: 303.746.7302<tel: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.tutkowski@solidfire.com<ma...@solidfire.com>
> >>>> o: 303.746.7302<tel: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.tutkowski@solidfire.com<ma...@solidfire.com>
> >>> o: 303.746.7302<tel: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.tutkowski@solidfire.com<ma...@solidfire.com>
> >> o: 303.746.7302<tel: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.tutkowski@solidfire.com<ma...@solidfire.com>
> o: 303.746.7302<tel: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.tutkowski@solidfire.com<ma...@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*

RE: Resetting a VM is broken?

Posted by Jessica Wang <Je...@citrix.com>.

And also provide detailed info in confirmation dialog when clicking the icon that fires restoreVirtualMachine API.

e.g. "This action will restore the VM to a fresh new root disk. 
After this action, the current root disk wll be destroyed and a new root disk will be attached to the VM."


Harikrishna, 
do you any suggestion for the text in confirmation dialog?


-----Original Message-----
From: Jessica Wang [mailto:Jessica.Wang@citrix.com] 
Sent: Thursday, March 20, 2014 11:32 AM
To: Mike Tutkowski
Cc: Brian Federle; Harikrishna Patnala; Alena Prokharchyk; dev@cloudstack.apache.org; Stephen Turner
Subject: RE: Resetting a VM is broken?

How about we just match text with API name?

i. Label the icon that fires recoverVirtualMachine API as "Recover".
ii. Label the icon that fires restoreVirtualMachine API as "Restore".


From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
Sent: Thursday, March 20, 2014 11:29 AM
To: Jessica Wang
Cc: Brian Federle; Harikrishna Patnala; Alena Prokharchyk; dev@cloudstack.apache.org; Stephen Turner
Subject: Re: Resetting a VM is broken?

OK, thanks for the history there.

What about the text we're using? Are we OK with Reset VM, for example?

Thanks!

On Thu, Mar 20, 2014 at 12:26 PM, Jessica Wang <Je...@citrix.com>> wrote:
Mike,

Right.

The history is recoverVirtualMachine API was created several years ago, restoreVirtualMachine didn't exist yet at that time.
So, the icon that fires recoverVirtualMachine API was labeled as "Restore" at that time.

restoreVirtualMachine API came along several years later.
Then, since label "Restore" has already taken, the icon that fires restoreVirtualMachine API was therefore labeled as "Reset".

The result is indeed weird.
We'll fix the label to match API name.

Jessica

From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com<ma...@solidfire.com>]
Sent: Thursday, March 20, 2014 11:03 AM
To: Jessica Wang
Cc: Brian Federle; Harikrishna Patnala; Alena Prokharchyk; dev@cloudstack.apache.org<ma...@cloudstack.apache.org>; Stephen Turner

Subject: Re: Resetting a VM is broken?

Thanks, Jessica

The even weirder part, though, is that the text Restore maps to the recoverVirtualMachine API and the text Reset VM maps to the restoreVirtualMachine.

On Thu, Mar 20, 2014 at 11:58 AM, Jessica Wang <Je...@citrix.com>> wrote:
> [Mike Tutkowski] 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
Yes, this is confusing.
I'll file an UI bug to match icon label with API name.
i.e. The icon that fires recoverVirtualMachine API will be labeled as "Recover"
and the icon that fires restoreVirtualMachine API will be labeled as "Restore"


-----Original Message-----
From: Brian Federle
Sent: Thursday, March 20, 2014 10:29 AM
To: Alena Prokharchyk
Cc: dev@cloudstack.apache.org<ma...@cloudstack.apache.org>; Brian Federle; Jessica Wang; Mike Tutkowski; Harikrishna Patnala
Subject: Re: Resetting a VM is broken?
>> the Reset Vm option is presented as a button unlike the icons
I think this was because all the other icons we tried to represent this with were too confusing to users - they were clicking on 'reset VM' thinking it was 'reboot VM' - then as a last minute fix the decision was to just to show a text label.

Any ideas from anyone on what would be a good icon representation?

-Brian

On Mar 19, 2014, at 3:02 PM, Alena Prokharchyk <Al...@citrix.com>> wrote:

> 1) Didn't notice "the elephant" - that the Reset Vm option is presented as
> a button unlike the icons for other options. UI folks - Brian/Jessica- why
> we decided to represent this option differently in the UI?
>
> 2) Mike, I've looked at the code and the history. We've always allocated a
> new volume during the vm restore call. Hari, can you please confirm that
> this feature you wrote, was designed to work this way
>
>
> -Alena.
>
>
> On 3/19/14, 2:41 PM, "Mike Tutkowski" <mi...@solidfire.com>> wrote:
>
>> To clarify: Reboot VM seemed to keep the VM running and just reboot the
>> OS.
>>
>> Reset VM seemed to shut the VM down and then re-start it (with the same
>> root disk for the OS).
>>
>>
>> On Wed, Mar 19, 2014 at 3:40 PM, Mike Tutkowski <
>> mike.tutkowski@solidfire.com<ma...@solidfire.com>> wrote:
>>
>>> I could be wrong, but I thought as recently as 4.3 that Reset VM
>>> essentially stopped and then re-started the VM with the same root disk.
>>>
>>> It seemed to differ from Reboot VM only in the sense that the VM was
>>> never
>>> technically stopped (the OS inside the VM was just rebooted).
>>>
>>>
>>> On Wed, Mar 19, 2014 at 3:38 PM, Mike Tutkowski <
>>> mike.tutkowski@solidfire.com<ma...@solidfire.com>> wrote:
>>>
>>>> I'm using XenServer 6.1 hosts (two of them) in this case.
>>>>
>>>>
>>>> On Wed, Mar 19, 2014 at 3:37 PM, Mike Tutkowski <
>>>> mike.tutkowski@solidfire.com<ma...@solidfire.com>> wrote:
>>>>
>>>>> Yeah, stopping and restarting works fine...as does, I believe,
>>>>> rebooting
>>>>> the VM.
>>>>>
>>>>> Right below Reboot VM, there is a Reset VM option.
>>>>>
>>>>> If that means "re-install," then we probably should clean up the old
>>>>> root disk.
>>>>>
>>>>>
>>>>> On Wed, Mar 19, 2014 at 3:30 PM, Alena Prokharchyk <
>>>>> Alena.Prokharchyk@citrix.com<ma...@citrix.com>> wrote:
>>>>>
>>>>>> don¹t see ³Reset Vm² option in UI; do you mean ³Reboot instance²?
>>>>>> I¹ve
>>>>>> just tried that, as well as calling stop/startVM from the UI. The Vm
>>>>>> boots
>>>>>> up with its original disk.
>>>>>>
>>>>>> I¹m having Xen/Nfs, not sure it matters
>>>>>>
>>>>>> -Alena.
>>>>>>
>>>>>> On 3/19/14, 2:19 PM, "Mike Tutkowski" <mi...@solidfire.com>>
>>>>>> wrote:
>>>>>>
>>>>>>> I didn't look into what the GUI calls, but I invoked the Reset VM
>>>>>> option
>>>>>>> in
>>>>>>> the GUI.
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Mar 19, 2014 at 3:17 PM, Alena Prokharchyk <
>>>>>>> Alena.Prokharchyk@citrix.com<ma...@citrix.com>> wrote:
>>>>>>>
>>>>>>>> Mike, just to confirm - did you call
>>>>>>>> stopVirtualMachine/startVirtualMachine apis?
>>>>>>>>
>>>>>>>> -alena.
>>>>>>>>
>>>>>>>> On 3/19/14, 1:55 PM, "Mike Tutkowski"
>>>>>> <mi...@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.tutkowski@solidfire.com<ma...@solidfire.com>
>>>>>>>>> o: 303.746.7302<tel: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.tutkowski@solidfire.com<ma...@solidfire.com>
>>>>>>> o: 303.746.7302<tel: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.tutkowski@solidfire.com<ma...@solidfire.com>
>>>>> o: 303.746.7302<tel: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.tutkowski@solidfire.com<ma...@solidfire.com>
>>>> o: 303.746.7302<tel: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.tutkowski@solidfire.com<ma...@solidfire.com>
>>> o: 303.746.7302<tel: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.tutkowski@solidfire.com<ma...@solidfire.com>
>> o: 303.746.7302<tel: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.tutkowski@solidfire.com<ma...@solidfire.com>
o: 303.746.7302<tel: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.tutkowski@solidfire.com<ma...@solidfire.com>
o: 303.746.7302
Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play>(tm)

RE: Resetting a VM is broken?

Posted by Jessica Wang <Je...@citrix.com>.

How about we just match text with API name?

i. Label the icon that fires recoverVirtualMachine API as "Recover".
ii. Label the icon that fires restoreVirtualMachine API as "Restore".


From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
Sent: Thursday, March 20, 2014 11:29 AM
To: Jessica Wang
Cc: Brian Federle; Harikrishna Patnala; Alena Prokharchyk; dev@cloudstack.apache.org; Stephen Turner
Subject: Re: Resetting a VM is broken?

OK, thanks for the history there.

What about the text we're using? Are we OK with Reset VM, for example?

Thanks!

On Thu, Mar 20, 2014 at 12:26 PM, Jessica Wang <Je...@citrix.com>> wrote:
Mike,

Right.

The history is recoverVirtualMachine API was created several years ago, restoreVirtualMachine didn't exist yet at that time.
So, the icon that fires recoverVirtualMachine API was labeled as "Restore" at that time.

restoreVirtualMachine API came along several years later.
Then, since label "Restore" has already taken, the icon that fires restoreVirtualMachine API was therefore labeled as "Reset".

The result is indeed weird.
We'll fix the label to match API name.

Jessica

From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com<ma...@solidfire.com>]
Sent: Thursday, March 20, 2014 11:03 AM
To: Jessica Wang
Cc: Brian Federle; Harikrishna Patnala; Alena Prokharchyk; dev@cloudstack.apache.org<ma...@cloudstack.apache.org>; Stephen Turner

Subject: Re: Resetting a VM is broken?

Thanks, Jessica

The even weirder part, though, is that the text Restore maps to the recoverVirtualMachine API and the text Reset VM maps to the restoreVirtualMachine.

On Thu, Mar 20, 2014 at 11:58 AM, Jessica Wang <Je...@citrix.com>> wrote:
> [Mike Tutkowski] 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
Yes, this is confusing.
I'll file an UI bug to match icon label with API name.
i.e. The icon that fires recoverVirtualMachine API will be labeled as "Recover"
and the icon that fires restoreVirtualMachine API will be labeled as "Restore"


-----Original Message-----
From: Brian Federle
Sent: Thursday, March 20, 2014 10:29 AM
To: Alena Prokharchyk
Cc: dev@cloudstack.apache.org<ma...@cloudstack.apache.org>; Brian Federle; Jessica Wang; Mike Tutkowski; Harikrishna Patnala
Subject: Re: Resetting a VM is broken?
>> the Reset Vm option is presented as a button unlike the icons
I think this was because all the other icons we tried to represent this with were too confusing to users - they were clicking on 'reset VM' thinking it was 'reboot VM' - then as a last minute fix the decision was to just to show a text label.

Any ideas from anyone on what would be a good icon representation?

-Brian

On Mar 19, 2014, at 3:02 PM, Alena Prokharchyk <Al...@citrix.com>> wrote:

> 1) Didn't notice "the elephant" - that the Reset Vm option is presented as
> a button unlike the icons for other options. UI folks - Brian/Jessica- why
> we decided to represent this option differently in the UI?
>
> 2) Mike, I've looked at the code and the history. We've always allocated a
> new volume during the vm restore call. Hari, can you please confirm that
> this feature you wrote, was designed to work this way
>
>
> -Alena.
>
>
> On 3/19/14, 2:41 PM, "Mike Tutkowski" <mi...@solidfire.com>> wrote:
>
>> To clarify: Reboot VM seemed to keep the VM running and just reboot the
>> OS.
>>
>> Reset VM seemed to shut the VM down and then re-start it (with the same
>> root disk for the OS).
>>
>>
>> On Wed, Mar 19, 2014 at 3:40 PM, Mike Tutkowski <
>> mike.tutkowski@solidfire.com<ma...@solidfire.com>> wrote:
>>
>>> I could be wrong, but I thought as recently as 4.3 that Reset VM
>>> essentially stopped and then re-started the VM with the same root disk.
>>>
>>> It seemed to differ from Reboot VM only in the sense that the VM was
>>> never
>>> technically stopped (the OS inside the VM was just rebooted).
>>>
>>>
>>> On Wed, Mar 19, 2014 at 3:38 PM, Mike Tutkowski <
>>> mike.tutkowski@solidfire.com<ma...@solidfire.com>> wrote:
>>>
>>>> I'm using XenServer 6.1 hosts (two of them) in this case.
>>>>
>>>>
>>>> On Wed, Mar 19, 2014 at 3:37 PM, Mike Tutkowski <
>>>> mike.tutkowski@solidfire.com<ma...@solidfire.com>> wrote:
>>>>
>>>>> Yeah, stopping and restarting works fine...as does, I believe,
>>>>> rebooting
>>>>> the VM.
>>>>>
>>>>> Right below Reboot VM, there is a Reset VM option.
>>>>>
>>>>> If that means "re-install," then we probably should clean up the old
>>>>> root disk.
>>>>>
>>>>>
>>>>> On Wed, Mar 19, 2014 at 3:30 PM, Alena Prokharchyk <
>>>>> Alena.Prokharchyk@citrix.com<ma...@citrix.com>> wrote:
>>>>>
>>>>>> don¹t see ³Reset Vm² option in UI; do you mean ³Reboot instance²?
>>>>>> I¹ve
>>>>>> just tried that, as well as calling stop/startVM from the UI. The Vm
>>>>>> boots
>>>>>> up with its original disk.
>>>>>>
>>>>>> I¹m having Xen/Nfs, not sure it matters
>>>>>>
>>>>>> -Alena.
>>>>>>
>>>>>> On 3/19/14, 2:19 PM, "Mike Tutkowski" <mi...@solidfire.com>>
>>>>>> wrote:
>>>>>>
>>>>>>> I didn't look into what the GUI calls, but I invoked the Reset VM
>>>>>> option
>>>>>>> in
>>>>>>> the GUI.
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Mar 19, 2014 at 3:17 PM, Alena Prokharchyk <
>>>>>>> Alena.Prokharchyk@citrix.com<ma...@citrix.com>> wrote:
>>>>>>>
>>>>>>>> Mike, just to confirm - did you call
>>>>>>>> stopVirtualMachine/startVirtualMachine apis?
>>>>>>>>
>>>>>>>> -alena.
>>>>>>>>
>>>>>>>> On 3/19/14, 1:55 PM, "Mike Tutkowski"
>>>>>> <mi...@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.tutkowski@solidfire.com<ma...@solidfire.com>
>>>>>>>>> o: 303.746.7302<tel: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.tutkowski@solidfire.com<ma...@solidfire.com>
>>>>>>> o: 303.746.7302<tel: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.tutkowski@solidfire.com<ma...@solidfire.com>
>>>>> o: 303.746.7302<tel: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.tutkowski@solidfire.com<ma...@solidfire.com>
>>>> o: 303.746.7302<tel: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.tutkowski@solidfire.com<ma...@solidfire.com>
>>> o: 303.746.7302<tel: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.tutkowski@solidfire.com<ma...@solidfire.com>
>> o: 303.746.7302<tel: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.tutkowski@solidfire.com<ma...@solidfire.com>
o: 303.746.7302<tel: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.tutkowski@solidfire.com<ma...@solidfire.com>
o: 303.746.7302
Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play>(tm)

Re: Resetting a VM is broken?

Posted by Mike Tutkowski <mi...@solidfire.com>.

OK, thanks for the history there.

What about the text we're using? Are we OK with Reset VM, for example?

Thanks!


On Thu, Mar 20, 2014 at 12:26 PM, Jessica Wang <Je...@citrix.com>wrote:

>  Mike,
>
>
>
> Right.
>
>
>
> The history is recoverVirtualMachine API was created several years ago,
> restoreVirtualMachine didn't exist yet at that time.
>
> So, the icon that fires recoverVirtualMachine API was labeled as "Restore"
> at that time.
>
>
>
> restoreVirtualMachine API came along several years later.
>
> Then, since label "Restore" has already taken, the icon that fires
> restoreVirtualMachine API was therefore labeled as "Reset".
>
>
>
> The result is indeed weird.
>
> We'll fix the label to match API name.
>
>
>
> Jessica
>
>
>
> *From:* Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
> *Sent:* Thursday, March 20, 2014 11:03 AM
> *To:* Jessica Wang
> *Cc:* Brian Federle; Harikrishna Patnala; Alena Prokharchyk;
> dev@cloudstack.apache.org; Stephen Turner
>
> *Subject:* Re: Resetting a VM is broken?
>
>
>
> Thanks, Jessica
>
>
>
> The even weirder part, though, is that the text Restore maps to the
> recoverVirtualMachine API and the text Reset VM maps to the
> restoreVirtualMachine.
>
>
>
> On Thu, Mar 20, 2014 at 11:58 AM, Jessica Wang <Je...@citrix.com>
> wrote:
>
> > [Mike Tutkowski] 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
>
>  Yes, this is confusing.
> I'll file an UI bug to match icon label with API name.
> i.e. The icon that fires recoverVirtualMachine API will be labeled as
> "Recover"
> and the icon that fires restoreVirtualMachine API will be labeled as
> "Restore"
>
>
>
> -----Original Message-----
> From: Brian Federle
> Sent: Thursday, March 20, 2014 10:29 AM
> To: Alena Prokharchyk
> Cc: dev@cloudstack.apache.org; Brian Federle; Jessica Wang; Mike
> Tutkowski; Harikrishna Patnala
> Subject: Re: Resetting a VM is broken?
>
> >> the Reset Vm option is presented as a button unlike the icons
>
> I think this was because all the other icons we tried to represent this
> with were too confusing to users - they were clicking on 'reset VM'
> thinking it was 'reboot VM' - then as a last minute fix the decision was to
> just to show a text label.
>
>
> Any ideas from anyone on what would be a good icon representation?
>
> -Brian
>
> On Mar 19, 2014, at 3:02 PM, Alena Prokharchyk <
> Alena.Prokharchyk@citrix.com> wrote:
>
> > 1) Didn't notice "the elephant" - that the Reset Vm option is presented
> as
> > a button unlike the icons for other options. UI folks - Brian/Jessica-
> why
> > we decided to represent this option differently in the UI?
> >
> > 2) Mike, I've looked at the code and the history. We've always allocated
> a
> > new volume during the vm restore call. Hari, can you please confirm that
> > this feature you wrote, was designed to work this way
> >
> >
> > -Alena.
> >
> >
> > On 3/19/14, 2:41 PM, "Mike Tutkowski" <mi...@solidfire.com>
> wrote:
> >
> >> To clarify: Reboot VM seemed to keep the VM running and just reboot the
> >> OS.
> >>
> >> Reset VM seemed to shut the VM down and then re-start it (with the same
> >> root disk for the OS).
> >>
> >>
> >> On Wed, Mar 19, 2014 at 3:40 PM, Mike Tutkowski <
> >> mike.tutkowski@solidfire.com> wrote:
> >>
> >>> I could be wrong, but I thought as recently as 4.3 that Reset VM
> >>> essentially stopped and then re-started the VM with the same root disk.
> >>>
> >>> It seemed to differ from Reboot VM only in the sense that the VM was
> >>> never
> >>> technically stopped (the OS inside the VM was just rebooted).
> >>>
> >>>
> >>> On Wed, Mar 19, 2014 at 3:38 PM, Mike Tutkowski <
> >>> mike.tutkowski@solidfire.com> wrote:
> >>>
> >>>> I'm using XenServer 6.1 hosts (two of them) in this case.
> >>>>
> >>>>
> >>>> On Wed, Mar 19, 2014 at 3:37 PM, Mike Tutkowski <
> >>>> mike.tutkowski@solidfire.com> wrote:
> >>>>
> >>>>> Yeah, stopping and restarting works fine...as does, I believe,
> >>>>> rebooting
> >>>>> the VM.
> >>>>>
> >>>>> Right below Reboot VM, there is a Reset VM option.
> >>>>>
> >>>>> If that means "re-install," then we probably should clean up the old
> >>>>> root disk.
> >>>>>
> >>>>>
> >>>>> On Wed, Mar 19, 2014 at 3:30 PM, Alena Prokharchyk <
> >>>>> Alena.Prokharchyk@citrix.com> wrote:
> >>>>>
> >>>>>> don¹t see ³Reset Vm² option in UI; do you mean ³Reboot instance²?
> >>>>>> I¹ve
> >>>>>> just tried that, as well as calling stop/startVM from the UI. The Vm
> >>>>>> boots
> >>>>>> up with its original disk.
> >>>>>>
> >>>>>> I¹m having Xen/Nfs, not sure it matters
> >>>>>>
> >>>>>> -Alena.
> >>>>>>
> >>>>>> On 3/19/14, 2:19 PM, "Mike Tutkowski" <mike.tutkowski@solidfire.com
> >
> >>>>>> wrote:
> >>>>>>
> >>>>>>> I didn't look into what the GUI calls, but I invoked the Reset VM
> >>>>>> option
> >>>>>>> in
> >>>>>>> the GUI.
> >>>>>>>
> >>>>>>> Thanks
> >>>>>>>
> >>>>>>>
> >>>>>>> On Wed, Mar 19, 2014 at 3:17 PM, Alena Prokharchyk <
> >>>>>>> Alena.Prokharchyk@citrix.com> wrote:
> >>>>>>>
> >>>>>>>> Mike, just to confirm - did you call
> >>>>>>>> stopVirtualMachine/startVirtualMachine apis?
> >>>>>>>>
> >>>>>>>> -alena.
> >>>>>>>>
> >>>>>>>> On 3/19/14, 1:55 PM, "Mike Tutkowski"
> >>>>>> <mi...@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*

RE: Resetting a VM is broken?

Posted by Jessica Wang <Je...@citrix.com>.

Mike,

Right.

The history is recoverVirtualMachine API was created several years ago, restoreVirtualMachine didn't exist yet at that time.
So, the icon that fires recoverVirtualMachine API was labeled as "Restore" at that time.

restoreVirtualMachine API came along several years later.
Then, since label "Restore" has already taken, the icon that fires restoreVirtualMachine API was therefore labeled as "Reset".

The result is indeed weird.
We'll fix the label to match API name.

Jessica

From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
Sent: Thursday, March 20, 2014 11:03 AM
To: Jessica Wang
Cc: Brian Federle; Harikrishna Patnala; Alena Prokharchyk; dev@cloudstack.apache.org; Stephen Turner
Subject: Re: Resetting a VM is broken?

Thanks, Jessica

The even weirder part, though, is that the text Restore maps to the recoverVirtualMachine API and the text Reset VM maps to the restoreVirtualMachine.

On Thu, Mar 20, 2014 at 11:58 AM, Jessica Wang <Je...@citrix.com>> wrote:
> [Mike Tutkowski] 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

Yes, this is confusing.
I'll file an UI bug to match icon label with API name.
i.e. The icon that fires recoverVirtualMachine API will be labeled as "Recover"
and the icon that fires restoreVirtualMachine API will be labeled as "Restore"


-----Original Message-----
From: Brian Federle
Sent: Thursday, March 20, 2014 10:29 AM
To: Alena Prokharchyk
Cc: dev@cloudstack.apache.org<ma...@cloudstack.apache.org>; Brian Federle; Jessica Wang; Mike Tutkowski; Harikrishna Patnala
Subject: Re: Resetting a VM is broken?
>> the Reset Vm option is presented as a button unlike the icons
I think this was because all the other icons we tried to represent this with were too confusing to users - they were clicking on 'reset VM' thinking it was 'reboot VM' - then as a last minute fix the decision was to just to show a text label.

Any ideas from anyone on what would be a good icon representation?

-Brian

On Mar 19, 2014, at 3:02 PM, Alena Prokharchyk <Al...@citrix.com>> wrote:

> 1) Didn't notice "the elephant" - that the Reset Vm option is presented as
> a button unlike the icons for other options. UI folks - Brian/Jessica- why
> we decided to represent this option differently in the UI?
>
> 2) Mike, I've looked at the code and the history. We've always allocated a
> new volume during the vm restore call. Hari, can you please confirm that
> this feature you wrote, was designed to work this way
>
>
> -Alena.
>
>
> On 3/19/14, 2:41 PM, "Mike Tutkowski" <mi...@solidfire.com>> wrote:
>
>> To clarify: Reboot VM seemed to keep the VM running and just reboot the
>> OS.
>>
>> Reset VM seemed to shut the VM down and then re-start it (with the same
>> root disk for the OS).
>>
>>
>> On Wed, Mar 19, 2014 at 3:40 PM, Mike Tutkowski <
>> mike.tutkowski@solidfire.com<ma...@solidfire.com>> wrote:
>>
>>> I could be wrong, but I thought as recently as 4.3 that Reset VM
>>> essentially stopped and then re-started the VM with the same root disk.
>>>
>>> It seemed to differ from Reboot VM only in the sense that the VM was
>>> never
>>> technically stopped (the OS inside the VM was just rebooted).
>>>
>>>
>>> On Wed, Mar 19, 2014 at 3:38 PM, Mike Tutkowski <
>>> mike.tutkowski@solidfire.com<ma...@solidfire.com>> wrote:
>>>
>>>> I'm using XenServer 6.1 hosts (two of them) in this case.
>>>>
>>>>
>>>> On Wed, Mar 19, 2014 at 3:37 PM, Mike Tutkowski <
>>>> mike.tutkowski@solidfire.com<ma...@solidfire.com>> wrote:
>>>>
>>>>> Yeah, stopping and restarting works fine...as does, I believe,
>>>>> rebooting
>>>>> the VM.
>>>>>
>>>>> Right below Reboot VM, there is a Reset VM option.
>>>>>
>>>>> If that means "re-install," then we probably should clean up the old
>>>>> root disk.
>>>>>
>>>>>
>>>>> On Wed, Mar 19, 2014 at 3:30 PM, Alena Prokharchyk <
>>>>> Alena.Prokharchyk@citrix.com<ma...@citrix.com>> wrote:
>>>>>
>>>>>> don¹t see ³Reset Vm² option in UI; do you mean ³Reboot instance²?
>>>>>> I¹ve
>>>>>> just tried that, as well as calling stop/startVM from the UI. The Vm
>>>>>> boots
>>>>>> up with its original disk.
>>>>>>
>>>>>> I¹m having Xen/Nfs, not sure it matters
>>>>>>
>>>>>> -Alena.
>>>>>>
>>>>>> On 3/19/14, 2:19 PM, "Mike Tutkowski" <mi...@solidfire.com>>
>>>>>> wrote:
>>>>>>
>>>>>>> I didn't look into what the GUI calls, but I invoked the Reset VM
>>>>>> option
>>>>>>> in
>>>>>>> the GUI.
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Mar 19, 2014 at 3:17 PM, Alena Prokharchyk <
>>>>>>> Alena.Prokharchyk@citrix.com<ma...@citrix.com>> wrote:
>>>>>>>
>>>>>>>> Mike, just to confirm - did you call
>>>>>>>> stopVirtualMachine/startVirtualMachine apis?
>>>>>>>>
>>>>>>>> -alena.
>>>>>>>>
>>>>>>>> On 3/19/14, 1:55 PM, "Mike Tutkowski"
>>>>>> <mi...@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.tutkowski@solidfire.com<ma...@solidfire.com>
>>>>>>>>> o: 303.746.7302<tel: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.tutkowski@solidfire.com<ma...@solidfire.com>
>>>>>>> o: 303.746.7302<tel: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.tutkowski@solidfire.com<ma...@solidfire.com>
>>>>> o: 303.746.7302<tel: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.tutkowski@solidfire.com<ma...@solidfire.com>
>>>> o: 303.746.7302<tel: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.tutkowski@solidfire.com<ma...@solidfire.com>
>>> o: 303.746.7302<tel: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.tutkowski@solidfire.com<ma...@solidfire.com>
>> o: 303.746.7302<tel: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.tutkowski@solidfire.com<ma...@solidfire.com>
o: 303.746.7302
Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play>(tm)

Re: Resetting a VM is broken?

Posted by Mike Tutkowski <mi...@solidfire.com>.

Thanks, Jessica

The even weirder part, though, is that the text Restore maps to the
recoverVirtualMachine API and the text Reset VM maps to the
restoreVirtualMachine.


On Thu, Mar 20, 2014 at 11:58 AM, Jessica Wang <Je...@citrix.com>wrote:

> > [Mike Tutkowski] 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
>
>
> Yes, this is confusing.
> I'll file an UI bug to match icon label with API name.
> i.e. The icon that fires recoverVirtualMachine API will be labeled as
> "Recover"
> and the icon that fires restoreVirtualMachine API will be labeled as
> "Restore"
>
>
> -----Original Message-----
> From: Brian Federle
> Sent: Thursday, March 20, 2014 10:29 AM
> To: Alena Prokharchyk
> Cc: dev@cloudstack.apache.org; Brian Federle; Jessica Wang; Mike
> Tutkowski; Harikrishna Patnala
> Subject: Re: Resetting a VM is broken?
>
> >> the Reset Vm option is presented as a button unlike the icons
>
> I think this was because all the other icons we tried to represent this
> with were too confusing to users - they were clicking on 'reset VM'
> thinking it was 'reboot VM' - then as a last minute fix the decision was to
> just to show a text label.
>
> Any ideas from anyone on what would be a good icon representation?
>
> -Brian
>
> On Mar 19, 2014, at 3:02 PM, Alena Prokharchyk <
> Alena.Prokharchyk@citrix.com> wrote:
>
> > 1) Didn't notice "the elephant" - that the Reset Vm option is presented
> as
> > a button unlike the icons for other options. UI folks - Brian/Jessica-
> why
> > we decided to represent this option differently in the UI?
> >
> > 2) Mike, I've looked at the code and the history. We've always allocated
> a
> > new volume during the vm restore call. Hari, can you please confirm that
> > this feature you wrote, was designed to work this way
> >
> >
> > -Alena.
> >
> >
> > On 3/19/14, 2:41 PM, "Mike Tutkowski" <mi...@solidfire.com>
> wrote:
> >
> >> To clarify: Reboot VM seemed to keep the VM running and just reboot the
> >> OS.
> >>
> >> Reset VM seemed to shut the VM down and then re-start it (with the same
> >> root disk for the OS).
> >>
> >>
> >> On Wed, Mar 19, 2014 at 3:40 PM, Mike Tutkowski <
> >> mike.tutkowski@solidfire.com> wrote:
> >>
> >>> I could be wrong, but I thought as recently as 4.3 that Reset VM
> >>> essentially stopped and then re-started the VM with the same root disk.
> >>>
> >>> It seemed to differ from Reboot VM only in the sense that the VM was
> >>> never
> >>> technically stopped (the OS inside the VM was just rebooted).
> >>>
> >>>
> >>> On Wed, Mar 19, 2014 at 3:38 PM, Mike Tutkowski <
> >>> mike.tutkowski@solidfire.com> wrote:
> >>>
> >>>> I'm using XenServer 6.1 hosts (two of them) in this case.
> >>>>
> >>>>
> >>>> On Wed, Mar 19, 2014 at 3:37 PM, Mike Tutkowski <
> >>>> mike.tutkowski@solidfire.com> wrote:
> >>>>
> >>>>> Yeah, stopping and restarting works fine...as does, I believe,
> >>>>> rebooting
> >>>>> the VM.
> >>>>>
> >>>>> Right below Reboot VM, there is a Reset VM option.
> >>>>>
> >>>>> If that means "re-install," then we probably should clean up the old
> >>>>> root disk.
> >>>>>
> >>>>>
> >>>>> On Wed, Mar 19, 2014 at 3:30 PM, Alena Prokharchyk <
> >>>>> Alena.Prokharchyk@citrix.com> wrote:
> >>>>>
> >>>>>> don¹t see ³Reset Vm² option in UI; do you mean ³Reboot instance²?
> >>>>>> I¹ve
> >>>>>> just tried that, as well as calling stop/startVM from the UI. The Vm
> >>>>>> boots
> >>>>>> up with its original disk.
> >>>>>>
> >>>>>> I¹m having Xen/Nfs, not sure it matters
> >>>>>>
> >>>>>> -Alena.
> >>>>>>
> >>>>>> On 3/19/14, 2:19 PM, "Mike Tutkowski" <mike.tutkowski@solidfire.com
> >
> >>>>>> wrote:
> >>>>>>
> >>>>>>> I didn't look into what the GUI calls, but I invoked the Reset VM
> >>>>>> option
> >>>>>>> in
> >>>>>>> the GUI.
> >>>>>>>
> >>>>>>> Thanks
> >>>>>>>
> >>>>>>>
> >>>>>>> On Wed, Mar 19, 2014 at 3:17 PM, Alena Prokharchyk <
> >>>>>>> Alena.Prokharchyk@citrix.com> wrote:
> >>>>>>>
> >>>>>>>> Mike, just to confirm - did you call
> >>>>>>>> stopVirtualMachine/startVirtualMachine apis?
> >>>>>>>>
> >>>>>>>> -alena.
> >>>>>>>>
> >>>>>>>> On 3/19/14, 1:55 PM, "Mike Tutkowski"
> >>>>>> <mi...@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*

RE: Resetting a VM is broken?

Posted by Jessica Wang <Je...@citrix.com>.

> [Mike Tutkowski] 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  


Yes, this is confusing.
I'll file an UI bug to match icon label with API name.
i.e. The icon that fires recoverVirtualMachine API will be labeled as "Recover" 
and the icon that fires restoreVirtualMachine API will be labeled as "Restore" 


-----Original Message-----
From: Brian Federle 
Sent: Thursday, March 20, 2014 10:29 AM
To: Alena Prokharchyk
Cc: dev@cloudstack.apache.org; Brian Federle; Jessica Wang; Mike Tutkowski; Harikrishna Patnala
Subject: Re: Resetting a VM is broken?

>> the Reset Vm option is presented as a button unlike the icons 

I think this was because all the other icons we tried to represent this with were too confusing to users - they were clicking on 'reset VM' thinking it was 'reboot VM' - then as a last minute fix the decision was to just to show a text label.

Any ideas from anyone on what would be a good icon representation?

-Brian

On Mar 19, 2014, at 3:02 PM, Alena Prokharchyk <Al...@citrix.com> wrote:

> 1) Didn't notice "the elephant" - that the Reset Vm option is presented as
> a button unlike the icons for other options. UI folks - Brian/Jessica- why
> we decided to represent this option differently in the UI?
> 
> 2) Mike, I've looked at the code and the history. We've always allocated a
> new volume during the vm restore call. Hari, can you please confirm that
> this feature you wrote, was designed to work this way
> 
> 
> -Alena.
> 
> 
> On 3/19/14, 2:41 PM, "Mike Tutkowski" <mi...@solidfire.com> wrote:
> 
>> To clarify: Reboot VM seemed to keep the VM running and just reboot the
>> OS.
>> 
>> Reset VM seemed to shut the VM down and then re-start it (with the same
>> root disk for the OS).
>> 
>> 
>> On Wed, Mar 19, 2014 at 3:40 PM, Mike Tutkowski <
>> mike.tutkowski@solidfire.com> wrote:
>> 
>>> I could be wrong, but I thought as recently as 4.3 that Reset VM
>>> essentially stopped and then re-started the VM with the same root disk.
>>> 
>>> It seemed to differ from Reboot VM only in the sense that the VM was
>>> never
>>> technically stopped (the OS inside the VM was just rebooted).
>>> 
>>> 
>>> On Wed, Mar 19, 2014 at 3:38 PM, Mike Tutkowski <
>>> mike.tutkowski@solidfire.com> wrote:
>>> 
>>>> I'm using XenServer 6.1 hosts (two of them) in this case.
>>>> 
>>>> 
>>>> On Wed, Mar 19, 2014 at 3:37 PM, Mike Tutkowski <
>>>> mike.tutkowski@solidfire.com> wrote:
>>>> 
>>>>> Yeah, stopping and restarting works fine...as does, I believe,
>>>>> rebooting
>>>>> the VM.
>>>>> 
>>>>> Right below Reboot VM, there is a Reset VM option.
>>>>> 
>>>>> If that means "re-install," then we probably should clean up the old
>>>>> root disk.
>>>>> 
>>>>> 
>>>>> On Wed, Mar 19, 2014 at 3:30 PM, Alena Prokharchyk <
>>>>> Alena.Prokharchyk@citrix.com> wrote:
>>>>> 
>>>>>> don¹t see ³Reset Vm² option in UI; do you mean ³Reboot instance²?
>>>>>> I¹ve
>>>>>> just tried that, as well as calling stop/startVM from the UI. The Vm
>>>>>> boots
>>>>>> up with its original disk.
>>>>>> 
>>>>>> I¹m having Xen/Nfs, not sure it matters
>>>>>> 
>>>>>> -Alena.
>>>>>> 
>>>>>> On 3/19/14, 2:19 PM, "Mike Tutkowski" <mi...@solidfire.com>
>>>>>> wrote:
>>>>>> 
>>>>>>> I didn't look into what the GUI calls, but I invoked the Reset VM
>>>>>> option
>>>>>>> in
>>>>>>> the GUI.
>>>>>>> 
>>>>>>> Thanks
>>>>>>> 
>>>>>>> 
>>>>>>> On Wed, Mar 19, 2014 at 3:17 PM, Alena Prokharchyk <
>>>>>>> Alena.Prokharchyk@citrix.com> wrote:
>>>>>>> 
>>>>>>>> Mike, just to confirm - did you call
>>>>>>>> stopVirtualMachine/startVirtualMachine apis?
>>>>>>>> 
>>>>>>>> -alena.
>>>>>>>> 
>>>>>>>> On 3/19/14, 1:55 PM, "Mike Tutkowski"
>>>>>> <mi...@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
>> o: 303.746.7302
>> Advancing the way the world uses the
>> cloud<http://solidfire.com/solution/overview/?video=play>
>> *(tm)*
>

RE: Resetting a VM is broken?

Posted by Alex Hitchins <al...@shapeblue.com>.

Perhaps a recycle icon would be better? To me it makes more sense.

I do like the idea of making sure via dialogs that the user knows what they are doing. Perhaps configurable so for private clouds where sysadmins know their stuff they don't get prompted.


Regards

Alex Hitchins

D: +44 1892 523 587 | S: +44 2036 030 540 | M: +44 7788 423 969

alex.hitchins@shapeblue.com

-----Original Message-----
From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
Sent: 20 March 2014 17:38
To: Brian Federle
Cc: Alena Prokharchyk; dev@cloudstack.apache.org; Jessica Wang; Harikrishna Patnala
Subject: Re: Resetting a VM is broken?

I don't really have an opinion regarding icons, but maybe another idea here would be to provide a detailed explanation in the confirmation dialog of what's about to happen since it could lead to data loss (unless you follow John's solution of the management server having to be stopped, which seems like a lot of work in a multi-management server environment).


On Thu, Mar 20, 2014 at 11:29 AM, Brian Federle <Br...@citrix.com>wrote:

> >> the Reset Vm option is presented as a button unlike the icons
>
> I think this was because all the other icons we tried to represent
> this with were too confusing to users -- they were clicking on 'reset VM'
> thinking it was 'reboot VM' -- then as a last minute fix the decision
> was to just to show a text label.
>
> Any ideas from anyone on what would be a good icon representation?
>
> -Brian
>
> On Mar 19, 2014, at 3:02 PM, Alena Prokharchyk <
> Alena.Prokharchyk@citrix.com> wrote:
>
> > 1) Didn't notice "the elephant" - that the Reset Vm option is
> > presented
> as
> > a button unlike the icons for other options. UI folks -
> > Brian/Jessica-
> why
> > we decided to represent this option differently in the UI?
> >
> > 2) Mike, I've looked at the code and the history. We've always
> > allocated
> a
> > new volume during the vm restore call. Hari, can you please confirm
> > that this feature you wrote, was designed to work this way
> >
> >
> > -Alena.
> >
> >
> > On 3/19/14, 2:41 PM, "Mike Tutkowski" <mi...@solidfire.com>
> wrote:
> >
> >> To clarify: Reboot VM seemed to keep the VM running and just reboot
> >> the OS.
> >>
> >> Reset VM seemed to shut the VM down and then re-start it (with the
> >> same root disk for the OS).
> >>
> >>
> >> On Wed, Mar 19, 2014 at 3:40 PM, Mike Tutkowski <
> >> mike.tutkowski@solidfire.com> wrote:
> >>
> >>> I could be wrong, but I thought as recently as 4.3 that Reset VM
> >>> essentially stopped and then re-started the VM with the same root disk.
> >>>
> >>> It seemed to differ from Reboot VM only in the sense that the VM
> >>> was never technically stopped (the OS inside the VM was just
> >>> rebooted).
> >>>
> >>>
> >>> On Wed, Mar 19, 2014 at 3:38 PM, Mike Tutkowski <
> >>> mike.tutkowski@solidfire.com> wrote:
> >>>
> >>>> I'm using XenServer 6.1 hosts (two of them) in this case.
> >>>>
> >>>>
> >>>> On Wed, Mar 19, 2014 at 3:37 PM, Mike Tutkowski <
> >>>> mike.tutkowski@solidfire.com> wrote:
> >>>>
> >>>>> Yeah, stopping and restarting works fine...as does, I believe,
> >>>>> rebooting the VM.
> >>>>>
> >>>>> Right below Reboot VM, there is a Reset VM option.
> >>>>>
> >>>>> If that means "re-install," then we probably should clean up the
> >>>>> old root disk.
> >>>>>
> >>>>>
> >>>>> On Wed, Mar 19, 2014 at 3:30 PM, Alena Prokharchyk <
> >>>>> Alena.Prokharchyk@citrix.com> wrote:
> >>>>>
> >>>>>> don¹t see ³Reset Vm² option in UI; do you mean ³Reboot instance²?
> >>>>>> I¹ve
> >>>>>> just tried that, as well as calling stop/startVM from the UI.
> >>>>>> The Vm boots up with its original disk.
> >>>>>>
> >>>>>> I¹m having Xen/Nfs, not sure it matters
> >>>>>>
> >>>>>> -Alena.
> >>>>>>
> >>>>>> On 3/19/14, 2:19 PM, "Mike Tutkowski"
> >>>>>> <mike.tutkowski@solidfire.com
> >
> >>>>>> wrote:
> >>>>>>
> >>>>>>> I didn't look into what the GUI calls, but I invoked the Reset
> >>>>>>> VM
> >>>>>> option
> >>>>>>> in
> >>>>>>> the GUI.
> >>>>>>>
> >>>>>>> Thanks
> >>>>>>>
> >>>>>>>
> >>>>>>> On Wed, Mar 19, 2014 at 3:17 PM, Alena Prokharchyk <
> >>>>>>> Alena.Prokharchyk@citrix.com> wrote:
> >>>>>>>
> >>>>>>>> Mike, just to confirm - did you call
> >>>>>>>> stopVirtualMachine/startVirtualMachine apis?
> >>>>>>>>
> >>>>>>>> -alena.
> >>>>>>>>
> >>>>>>>> On 3/19/14, 1:55 PM, "Mike Tutkowski"
> >>>>>> <mi...@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*
Need Enterprise Grade Support for Apache CloudStack?
Our CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/> offers the best 24/7 SLA for CloudStack Environments.

Apache CloudStack Bootcamp training courses

**NEW!** CloudStack 4.2.1 training<http://shapeblue.com/cloudstack-training/>
18th-19th February 2014, Brazil. Classroom<http://shapeblue.com/cloudstack-training/>
17th-23rd March 2014, Region A. Instructor led, On-line<http://shapeblue.com/cloudstack-training/>
24th-28th March 2014, Region B. Instructor led, On-line<http://shapeblue.com/cloudstack-training/>
16th-20th June 2014, Region A. Instructor led, On-line<http://shapeblue.com/cloudstack-training/>
23rd-27th June 2014, Region B. Instructor led, On-line<http://shapeblue.com/cloudstack-training/>

This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue is a registered trademark.

Re: Resetting a VM is broken?

Posted by Mike Tutkowski <mi...@solidfire.com>.

I don't really have an opinion regarding icons, but maybe another idea here
would be to provide a detailed explanation in the confirmation dialog of
what's about to happen since it could lead to data loss (unless you follow
John's solution of the management server having to be stopped, which seems
like a lot of work in a multi-management server environment).


On Thu, Mar 20, 2014 at 11:29 AM, Brian Federle <Br...@citrix.com>wrote:

> >> the Reset Vm option is presented as a button unlike the icons
>
> I think this was because all the other icons we tried to represent this
> with were too confusing to users -- they were clicking on 'reset VM'
> thinking it was 'reboot VM' -- then as a last minute fix the decision was to
> just to show a text label.
>
> Any ideas from anyone on what would be a good icon representation?
>
> -Brian
>
> On Mar 19, 2014, at 3:02 PM, Alena Prokharchyk <
> Alena.Prokharchyk@citrix.com> wrote:
>
> > 1) Didn't notice "the elephant" - that the Reset Vm option is presented
> as
> > a button unlike the icons for other options. UI folks - Brian/Jessica-
> why
> > we decided to represent this option differently in the UI?
> >
> > 2) Mike, I've looked at the code and the history. We've always allocated
> a
> > new volume during the vm restore call. Hari, can you please confirm that
> > this feature you wrote, was designed to work this way
> >
> >
> > -Alena.
> >
> >
> > On 3/19/14, 2:41 PM, "Mike Tutkowski" <mi...@solidfire.com>
> wrote:
> >
> >> To clarify: Reboot VM seemed to keep the VM running and just reboot the
> >> OS.
> >>
> >> Reset VM seemed to shut the VM down and then re-start it (with the same
> >> root disk for the OS).
> >>
> >>
> >> On Wed, Mar 19, 2014 at 3:40 PM, Mike Tutkowski <
> >> mike.tutkowski@solidfire.com> wrote:
> >>
> >>> I could be wrong, but I thought as recently as 4.3 that Reset VM
> >>> essentially stopped and then re-started the VM with the same root disk.
> >>>
> >>> It seemed to differ from Reboot VM only in the sense that the VM was
> >>> never
> >>> technically stopped (the OS inside the VM was just rebooted).
> >>>
> >>>
> >>> On Wed, Mar 19, 2014 at 3:38 PM, Mike Tutkowski <
> >>> mike.tutkowski@solidfire.com> wrote:
> >>>
> >>>> I'm using XenServer 6.1 hosts (two of them) in this case.
> >>>>
> >>>>
> >>>> On Wed, Mar 19, 2014 at 3:37 PM, Mike Tutkowski <
> >>>> mike.tutkowski@solidfire.com> wrote:
> >>>>
> >>>>> Yeah, stopping and restarting works fine...as does, I believe,
> >>>>> rebooting
> >>>>> the VM.
> >>>>>
> >>>>> Right below Reboot VM, there is a Reset VM option.
> >>>>>
> >>>>> If that means "re-install," then we probably should clean up the old
> >>>>> root disk.
> >>>>>
> >>>>>
> >>>>> On Wed, Mar 19, 2014 at 3:30 PM, Alena Prokharchyk <
> >>>>> Alena.Prokharchyk@citrix.com> wrote:
> >>>>>
> >>>>>> don¹t see ³Reset Vm² option in UI; do you mean ³Reboot instance²?
> >>>>>> I¹ve
> >>>>>> just tried that, as well as calling stop/startVM from the UI. The Vm
> >>>>>> boots
> >>>>>> up with its original disk.
> >>>>>>
> >>>>>> I¹m having Xen/Nfs, not sure it matters
> >>>>>>
> >>>>>> -Alena.
> >>>>>>
> >>>>>> On 3/19/14, 2:19 PM, "Mike Tutkowski" <mike.tutkowski@solidfire.com
> >
> >>>>>> wrote:
> >>>>>>
> >>>>>>> I didn't look into what the GUI calls, but I invoked the Reset VM
> >>>>>> option
> >>>>>>> in
> >>>>>>> the GUI.
> >>>>>>>
> >>>>>>> Thanks
> >>>>>>>
> >>>>>>>
> >>>>>>> On Wed, Mar 19, 2014 at 3:17 PM, Alena Prokharchyk <
> >>>>>>> Alena.Prokharchyk@citrix.com> wrote:
> >>>>>>>
> >>>>>>>> Mike, just to confirm - did you call
> >>>>>>>> stopVirtualMachine/startVirtualMachine apis?
> >>>>>>>>
> >>>>>>>> -alena.
> >>>>>>>>
> >>>>>>>> On 3/19/14, 1:55 PM, "Mike Tutkowski"
> >>>>>> <mi...@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*

Re: Resetting a VM is broken?

Posted by Brian Federle <Br...@citrix.com>.

>> the Reset Vm option is presented as a button unlike the icons 

I think this was because all the other icons we tried to represent this with were too confusing to users — they were clicking on 'reset VM' thinking it was ‘reboot VM’ — then as a last minute fix the decision was to just to show a text label.

Any ideas from anyone on what would be a good icon representation?

-Brian

On Mar 19, 2014, at 3:02 PM, Alena Prokharchyk <Al...@citrix.com> wrote:

> 1) Didn’t notice “the elephant” - that the Reset Vm option is presented as
> a button unlike the icons for other options. UI folks - Brian/Jessica- why
> we decided to represent this option differently in the UI?
> 
> 2) Mike, I’ve looked at the code and the history. We've always allocated a
> new volume during the vm restore call. Hari, can you please confirm that
> this feature you wrote, was designed to work this way
> 
> 
> -Alena.
> 
> 
> On 3/19/14, 2:41 PM, "Mike Tutkowski" <mi...@solidfire.com> wrote:
> 
>> To clarify: Reboot VM seemed to keep the VM running and just reboot the
>> OS.
>> 
>> Reset VM seemed to shut the VM down and then re-start it (with the same
>> root disk for the OS).
>> 
>> 
>> On Wed, Mar 19, 2014 at 3:40 PM, Mike Tutkowski <
>> mike.tutkowski@solidfire.com> wrote:
>> 
>>> I could be wrong, but I thought as recently as 4.3 that Reset VM
>>> essentially stopped and then re-started the VM with the same root disk.
>>> 
>>> It seemed to differ from Reboot VM only in the sense that the VM was
>>> never
>>> technically stopped (the OS inside the VM was just rebooted).
>>> 
>>> 
>>> On Wed, Mar 19, 2014 at 3:38 PM, Mike Tutkowski <
>>> mike.tutkowski@solidfire.com> wrote:
>>> 
>>>> I'm using XenServer 6.1 hosts (two of them) in this case.
>>>> 
>>>> 
>>>> On Wed, Mar 19, 2014 at 3:37 PM, Mike Tutkowski <
>>>> mike.tutkowski@solidfire.com> wrote:
>>>> 
>>>>> Yeah, stopping and restarting works fine...as does, I believe,
>>>>> rebooting
>>>>> the VM.
>>>>> 
>>>>> Right below Reboot VM, there is a Reset VM option.
>>>>> 
>>>>> If that means "re-install," then we probably should clean up the old
>>>>> root disk.
>>>>> 
>>>>> 
>>>>> On Wed, Mar 19, 2014 at 3:30 PM, Alena Prokharchyk <
>>>>> Alena.Prokharchyk@citrix.com> wrote:
>>>>> 
>>>>>> don¹t see ³Reset Vm² option in UI; do you mean ³Reboot instance²?
>>>>>> I¹ve
>>>>>> just tried that, as well as calling stop/startVM from the UI. The Vm
>>>>>> boots
>>>>>> up with its original disk.
>>>>>> 
>>>>>> I¹m having Xen/Nfs, not sure it matters
>>>>>> 
>>>>>> -Alena.
>>>>>> 
>>>>>> On 3/19/14, 2:19 PM, "Mike Tutkowski" <mi...@solidfire.com>
>>>>>> wrote:
>>>>>> 
>>>>>>> I didn't look into what the GUI calls, but I invoked the Reset VM
>>>>>> option
>>>>>>> in
>>>>>>> the GUI.
>>>>>>> 
>>>>>>> Thanks
>>>>>>> 
>>>>>>> 
>>>>>>> On Wed, Mar 19, 2014 at 3:17 PM, Alena Prokharchyk <
>>>>>>> Alena.Prokharchyk@citrix.com> wrote:
>>>>>>> 
>>>>>>>> Mike, just to confirm - did you call
>>>>>>>> stopVirtualMachine/startVirtualMachine apis?
>>>>>>>> 
>>>>>>>> -alena.
>>>>>>>> 
>>>>>>>> On 3/19/14, 1:55 PM, "Mike Tutkowski"
>>>>>> <mi...@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
>> o: 303.746.7302
>> Advancing the way the world uses the
>> cloud<http://solidfire.com/solution/overview/?video=play>
>> *(tm)*
>

Re: Resetting a VM is broken?

Posted by Alena Prokharchyk <Al...@citrix.com>.

1) Didn’t notice “the elephant” - that the Reset Vm option is presented as
a button unlike the icons for other options. UI folks - Brian/Jessica- why
we decided to represent this option differently in the UI?

2) Mike, I’ve looked at the code and the history. We've always allocated a
new volume during the vm restore call. Hari, can you please confirm that
this feature you wrote, was designed to work this way


-Alena.


On 3/19/14, 2:41 PM, "Mike Tutkowski" <mi...@solidfire.com> wrote:

>To clarify: Reboot VM seemed to keep the VM running and just reboot the
>OS.
>
>Reset VM seemed to shut the VM down and then re-start it (with the same
>root disk for the OS).
>
>
>On Wed, Mar 19, 2014 at 3:40 PM, Mike Tutkowski <
>mike.tutkowski@solidfire.com> wrote:
>
>> I could be wrong, but I thought as recently as 4.3 that Reset VM
>> essentially stopped and then re-started the VM with the same root disk.
>>
>> It seemed to differ from Reboot VM only in the sense that the VM was
>>never
>> technically stopped (the OS inside the VM was just rebooted).
>>
>>
>> On Wed, Mar 19, 2014 at 3:38 PM, Mike Tutkowski <
>> mike.tutkowski@solidfire.com> wrote:
>>
>>> I'm using XenServer 6.1 hosts (two of them) in this case.
>>>
>>>
>>> On Wed, Mar 19, 2014 at 3:37 PM, Mike Tutkowski <
>>> mike.tutkowski@solidfire.com> wrote:
>>>
>>>> Yeah, stopping and restarting works fine...as does, I believe,
>>>>rebooting
>>>> the VM.
>>>>
>>>> Right below Reboot VM, there is a Reset VM option.
>>>>
>>>> If that means "re-install," then we probably should clean up the old
>>>> root disk.
>>>>
>>>>
>>>> On Wed, Mar 19, 2014 at 3:30 PM, Alena Prokharchyk <
>>>> Alena.Prokharchyk@citrix.com> wrote:
>>>>
>>>>> don¹t see ³Reset Vm² option in UI; do you mean ³Reboot instance²?
>>>>>I¹ve
>>>>> just tried that, as well as calling stop/startVM from the UI. The Vm
>>>>> boots
>>>>> up with its original disk.
>>>>>
>>>>> I¹m having Xen/Nfs, not sure it matters
>>>>>
>>>>> -Alena.
>>>>>
>>>>> On 3/19/14, 2:19 PM, "Mike Tutkowski" <mi...@solidfire.com>
>>>>> wrote:
>>>>>
>>>>> >I didn't look into what the GUI calls, but I invoked the Reset VM
>>>>> option
>>>>> >in
>>>>> >the GUI.
>>>>> >
>>>>> >Thanks
>>>>> >
>>>>> >
>>>>> >On Wed, Mar 19, 2014 at 3:17 PM, Alena Prokharchyk <
>>>>> >Alena.Prokharchyk@citrix.com> wrote:
>>>>> >
>>>>> >> Mike, just to confirm - did you call
>>>>> >> stopVirtualMachine/startVirtualMachine apis?
>>>>> >>
>>>>> >> -alena.
>>>>> >>
>>>>> >> On 3/19/14, 1:55 PM, "Mike Tutkowski"
>>>>><mi...@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
>o: 303.746.7302
>Advancing the way the world uses the
>cloud<http://solidfire.com/solution/overview/?video=play>
>*(tm)*

Re: Resetting a VM is broken?

Posted by Mike Tutkowski <mi...@solidfire.com>.

To clarify: Reboot VM seemed to keep the VM running and just reboot the OS.

Reset VM seemed to shut the VM down and then re-start it (with the same
root disk for the OS).


On Wed, Mar 19, 2014 at 3:40 PM, Mike Tutkowski <
mike.tutkowski@solidfire.com> wrote:

> I could be wrong, but I thought as recently as 4.3 that Reset VM
> essentially stopped and then re-started the VM with the same root disk.
>
> It seemed to differ from Reboot VM only in the sense that the VM was never
> technically stopped (the OS inside the VM was just rebooted).
>
>
> On Wed, Mar 19, 2014 at 3:38 PM, Mike Tutkowski <
> mike.tutkowski@solidfire.com> wrote:
>
>> I'm using XenServer 6.1 hosts (two of them) in this case.
>>
>>
>> On Wed, Mar 19, 2014 at 3:37 PM, Mike Tutkowski <
>> mike.tutkowski@solidfire.com> wrote:
>>
>>> Yeah, stopping and restarting works fine...as does, I believe, rebooting
>>> the VM.
>>>
>>> Right below Reboot VM, there is a Reset VM option.
>>>
>>> If that means "re-install," then we probably should clean up the old
>>> root disk.
>>>
>>>
>>> On Wed, Mar 19, 2014 at 3:30 PM, Alena Prokharchyk <
>>> Alena.Prokharchyk@citrix.com> wrote:
>>>
>>>> don¹t see ³Reset Vm² option in UI; do you mean ³Reboot instance²? I¹ve
>>>> just tried that, as well as calling stop/startVM from the UI. The Vm
>>>> boots
>>>> up with its original disk.
>>>>
>>>> I¹m having Xen/Nfs, not sure it matters
>>>>
>>>> -Alena.
>>>>
>>>> On 3/19/14, 2:19 PM, "Mike Tutkowski" <mi...@solidfire.com>
>>>> wrote:
>>>>
>>>> >I didn't look into what the GUI calls, but I invoked the Reset VM
>>>> option
>>>> >in
>>>> >the GUI.
>>>> >
>>>> >Thanks
>>>> >
>>>> >
>>>> >On Wed, Mar 19, 2014 at 3:17 PM, Alena Prokharchyk <
>>>> >Alena.Prokharchyk@citrix.com> wrote:
>>>> >
>>>> >> Mike, just to confirm - did you call
>>>> >> stopVirtualMachine/startVirtualMachine apis?
>>>> >>
>>>> >> -alena.
>>>> >>
>>>> >> On 3/19/14, 1:55 PM, "Mike Tutkowski" <mi...@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*

Re: Resetting a VM is broken?

Posted by Mike Tutkowski <mi...@solidfire.com>.

I could be wrong, but I thought as recently as 4.3 that Reset VM
essentially stopped and then re-started the VM with the same root disk.

It seemed to differ from Reboot VM only in the sense that the VM was never
technically stopped (the OS inside the VM was just rebooted).


On Wed, Mar 19, 2014 at 3:38 PM, Mike Tutkowski <
mike.tutkowski@solidfire.com> wrote:

> I'm using XenServer 6.1 hosts (two of them) in this case.
>
>
> On Wed, Mar 19, 2014 at 3:37 PM, Mike Tutkowski <
> mike.tutkowski@solidfire.com> wrote:
>
>> Yeah, stopping and restarting works fine...as does, I believe, rebooting
>> the VM.
>>
>> Right below Reboot VM, there is a Reset VM option.
>>
>> If that means "re-install," then we probably should clean up the old root
>> disk.
>>
>>
>> On Wed, Mar 19, 2014 at 3:30 PM, Alena Prokharchyk <
>> Alena.Prokharchyk@citrix.com> wrote:
>>
>>> don¹t see ³Reset Vm² option in UI; do you mean ³Reboot instance²? I¹ve
>>> just tried that, as well as calling stop/startVM from the UI. The Vm
>>> boots
>>> up with its original disk.
>>>
>>> I¹m having Xen/Nfs, not sure it matters
>>>
>>> -Alena.
>>>
>>> On 3/19/14, 2:19 PM, "Mike Tutkowski" <mi...@solidfire.com>
>>> wrote:
>>>
>>> >I didn't look into what the GUI calls, but I invoked the Reset VM option
>>> >in
>>> >the GUI.
>>> >
>>> >Thanks
>>> >
>>> >
>>> >On Wed, Mar 19, 2014 at 3:17 PM, Alena Prokharchyk <
>>> >Alena.Prokharchyk@citrix.com> wrote:
>>> >
>>> >> Mike, just to confirm - did you call
>>> >> stopVirtualMachine/startVirtualMachine apis?
>>> >>
>>> >> -alena.
>>> >>
>>> >> On 3/19/14, 1:55 PM, "Mike Tutkowski" <mi...@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*

Re: Resetting a VM is broken?

Posted by Mike Tutkowski <mi...@solidfire.com>.

I'm using XenServer 6.1 hosts (two of them) in this case.


On Wed, Mar 19, 2014 at 3:37 PM, Mike Tutkowski <
mike.tutkowski@solidfire.com> wrote:

> Yeah, stopping and restarting works fine...as does, I believe, rebooting
> the VM.
>
> Right below Reboot VM, there is a Reset VM option.
>
> If that means "re-install," then we probably should clean up the old root
> disk.
>
>
> On Wed, Mar 19, 2014 at 3:30 PM, Alena Prokharchyk <
> Alena.Prokharchyk@citrix.com> wrote:
>
>> don¹t see ³Reset Vm² option in UI; do you mean ³Reboot instance²? I¹ve
>> just tried that, as well as calling stop/startVM from the UI. The Vm boots
>> up with its original disk.
>>
>> I¹m having Xen/Nfs, not sure it matters
>>
>> -Alena.
>>
>> On 3/19/14, 2:19 PM, "Mike Tutkowski" <mi...@solidfire.com>
>> wrote:
>>
>> >I didn't look into what the GUI calls, but I invoked the Reset VM option
>> >in
>> >the GUI.
>> >
>> >Thanks
>> >
>> >
>> >On Wed, Mar 19, 2014 at 3:17 PM, Alena Prokharchyk <
>> >Alena.Prokharchyk@citrix.com> wrote:
>> >
>> >> Mike, just to confirm - did you call
>> >> stopVirtualMachine/startVirtualMachine apis?
>> >>
>> >> -alena.
>> >>
>> >> On 3/19/14, 1:55 PM, "Mike Tutkowski" <mi...@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*

Re: Resetting a VM is broken?

Posted by Mike Tutkowski <mi...@solidfire.com>.

Yeah, stopping and restarting works fine...as does, I believe, rebooting
the VM.

Right below Reboot VM, there is a Reset VM option.

If that means "re-install," then we probably should clean up the old root
disk.


On Wed, Mar 19, 2014 at 3:30 PM, Alena Prokharchyk <
Alena.Prokharchyk@citrix.com> wrote:

> don¹t see ³Reset Vm² option in UI; do you mean ³Reboot instance²? I¹ve
> just tried that, as well as calling stop/startVM from the UI. The Vm boots
> up with its original disk.
>
> I¹m having Xen/Nfs, not sure it matters
>
> -Alena.
>
> On 3/19/14, 2:19 PM, "Mike Tutkowski" <mi...@solidfire.com>
> wrote:
>
> >I didn't look into what the GUI calls, but I invoked the Reset VM option
> >in
> >the GUI.
> >
> >Thanks
> >
> >
> >On Wed, Mar 19, 2014 at 3:17 PM, Alena Prokharchyk <
> >Alena.Prokharchyk@citrix.com> wrote:
> >
> >> Mike, just to confirm - did you call
> >> stopVirtualMachine/startVirtualMachine apis?
> >>
> >> -alena.
> >>
> >> On 3/19/14, 1:55 PM, "Mike Tutkowski" <mi...@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*

Re: Resetting a VM is broken?

Posted by Alena Prokharchyk <Al...@citrix.com>.

don¹t see ³Reset Vm² option in UI; do you mean ³Reboot instance²? I¹ve
just tried that, as well as calling stop/startVM from the UI. The Vm boots
up with its original disk.

I¹m having Xen/Nfs, not sure it matters

-Alena.

On 3/19/14, 2:19 PM, "Mike Tutkowski" <mi...@solidfire.com> wrote:

>I didn't look into what the GUI calls, but I invoked the Reset VM option
>in
>the GUI.
>
>Thanks
>
>
>On Wed, Mar 19, 2014 at 3:17 PM, Alena Prokharchyk <
>Alena.Prokharchyk@citrix.com> wrote:
>
>> Mike, just to confirm - did you call
>> stopVirtualMachine/startVirtualMachine apis?
>>
>> -alena.
>>
>> On 3/19/14, 1:55 PM, "Mike Tutkowski" <mi...@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.tutkowski@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.tutkowski@solidfire.com
>o: 303.746.7302
>Advancing the way the world uses the
>cloud<http://solidfire.com/solution/overview/?video=play>
>*(tm)*

Re: Resetting a VM is broken?

Posted by Mike Tutkowski <mi...@solidfire.com>.

I didn't look into what the GUI calls, but I invoked the Reset VM option in
the GUI.

Thanks


On Wed, Mar 19, 2014 at 3:17 PM, Alena Prokharchyk <
Alena.Prokharchyk@citrix.com> wrote:

> Mike, just to confirm - did you call
> stopVirtualMachine/startVirtualMachine apis?
>
> -alena.
>
> On 3/19/14, 1:55 PM, "Mike Tutkowski" <mi...@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*

Re: Resetting a VM is broken?

Posted by Alena Prokharchyk <Al...@citrix.com>.

Mike, just to confirm - did you call
stopVirtualMachine/startVirtualMachine apis?

-alena.

On 3/19/14, 1:55 PM, "Mike Tutkowski" <mi...@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.tutkowski@solidfire.com
>o: 303.746.7302
>Advancing the way the world uses the
>cloud<http://solidfire.com/solution/overview/?video=play>
>*(tm)*

Re: Resetting a VM is broken?

Posted by Mike Tutkowski <mi...@solidfire.com>.

OK, thanks :)


On Wed, Mar 19, 2014 at 11:20 PM, Harikrishna Patnala <
harikrishna.patnala@citrix.com> wrote:

> Hi
> Yes Mike, currently there is no way to get the old root disk back, since a
> new root disk is already attached to VM and old disk is marked as destroyed.
> With this API we can also specify templateId to restore the VM from the
> new template.
>
> -Harikrishna
>
> On 20-Mar-2014, at 10:29 am, Mike Tutkowski <mi...@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.tutkowski@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.tutkowski@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 <sh...@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 <sh...@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.Mehta@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.tutkowski@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.Prokharchyk@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.tutkowski@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.Mehta@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*

Re: Resetting a VM is broken?

Posted by Harikrishna Patnala <ha...@citrix.com>.

Hi
Yes Mike, currently there is no way to get the old root disk back, since a new root disk is already attached to VM and old disk is marked as destroyed.
With this API we can also specify templateId to restore the VM from the new template.

-Harikrishna

On 20-Mar-2014, at 10:29 am, Mike Tutkowski <mi...@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.tutkowski@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.tutkowski@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 <sh...@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 <sh...@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 <Ni...@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" <mi...@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.Prokharchyk@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.tutkowski@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.Mehta@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud<http://solidfire.com/solution/overview/?video=play>
> *(tm)*

Re: Resetting a VM is broken?

Posted by Harikrishna Patnala <ha...@citrix.com>.

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 <mi...@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.tutkowski@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.patnala@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 <mi...@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.tutkowski@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.tutkowski@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.tutkowski@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 <sh...@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 <sh...@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.Mehta@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.tutkowski@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.Prokharchyk@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.tutkowski@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.Mehta@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud<http://solidfire.com/solution/overview/?video=play>
> *(tm)*

Re: Resetting a VM is broken?

Posted by Mike Tutkowski <mi...@solidfire.com>.

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.tutkowski@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.patnala@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 <mi...@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.tutkowski@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.tutkowski@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.tutkowski@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 <sh...@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 <sh...@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.Mehta@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.tutkowski@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.Prokharchyk@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.tutkowski@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.Mehta@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*

Re: Resetting a VM is broken?

Posted by Mike Tutkowski <mi...@solidfire.com>.

Ah, right - my mistake. I should have thought of that.


On Wed, Mar 19, 2014 at 11:29 PM, Harikrishna Patnala <
harikrishna.patnala@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 <mi...@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.tutkowski@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.tutkowski@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.tutkowski@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 <sh...@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 <sh...@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.Mehta@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.tutkowski@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.Prokharchyk@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.tutkowski@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.Mehta@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*

Re: Resetting a VM is broken?

Posted by Harikrishna Patnala <ha...@citrix.com>.

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 <mi...@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.tutkowski@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.tutkowski@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.tutkowski@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 <sh...@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 <sh...@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 <Ni...@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" <mi...@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.Prokharchyk@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.tutkowski@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.Mehta@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud<http://solidfire.com/solution/overview/?video=play>
> *(tm)*

Re: Resetting a VM is broken?

Posted by Mike Tutkowski <mi...@solidfire.com>.

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.tutkowski@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.tutkowski@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.tutkowski@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 <sh...@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 <sh...@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 <Ni...@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" <mi...@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.Prokharchyk@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.tutkowski@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.Mehta@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*

Re: Resetting a VM is broken?

Posted by Mike Tutkowski <mi...@solidfire.com>.

Thanks, John

I am mainly curious about this use case because of work I did on 4.4 to
support root disks for managed storage (just on XenServer for 4.4.).

It appears I need to make a small tweak to 4.4 code in the managed-storage
area for this cleanup to completely work (the SR that was auto created for
the volume that's deleted needs to be removed from the applicable XenServer
cluster).


On Thu, Mar 20, 2014 at 9:36 AM, John Kinsella <jl...@stratosec.co> wrote:

> Mike - There is a way to restore disks in destroyed state before they are
> expunged. It requires shutting down management server, modifying database
> directly, and keeping a good stock of potential offerings near your data
> recovery shrine.
>
> I'm going to be covering this in my CCC Denver talk.
>
> John
>
> On Mar 19, 2014, at 9:59 PM, Mike Tutkowski <mike.tutkowski@solidfire.com
> <ma...@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.tutkowski@solidfire.com<ma...@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.tutkowski@solidfire.com<ma...@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 <shadowsor@gmail.com<mailto:
> shadowsor@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 <shadowsor@gmail.com<mailto:
> shadowsor@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.Mehta@citrix.com
> <ma...@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.tutkowski@solidfire.com
> <ma...@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.Prokharchyk@citrix.com<ma...@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.tutkowski@solidfire.com
> <ma...@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.Mehta@citrix.com<ma...@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.tutkowski@solidfire.com<ma...@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.tutkowski@solidfire.com<ma...@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.tutkowski@solidfire.com<ma...@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.tutkowski@solidfire.com<ma...@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.tutkowski@solidfire.com<ma...@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.tutkowski@solidfire.com<ma...@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.tutkowski@solidfire.com<ma...@solidfire.com>
> o: 303.746.7302
> Advancing the way the world uses the
> cloud<http://solidfire.com/solution/overview/?video=play>
> *(tm)*
>
> Stratosec<http://stratosec.co/> - Compliance as a Service
> o: 415.315.9385
> @johnlkinsella<http://twitter.com/johnlkinsella>
>
>


-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*

Re: Resetting a VM is broken?

Posted by John Kinsella <jl...@stratosec.co>.

Mike - There is a way to restore disks in destroyed state before they are expunged. It requires shutting down management server, modifying database directly, and keeping a good stock of potential offerings near your data recovery shrine.

I’m going to be covering this in my CCC Denver talk.

John

On Mar 19, 2014, at 9:59 PM, Mike Tutkowski <mi...@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.tutkowski@solidfire.com<ma...@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.tutkowski@solidfire.com<ma...@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 <sh...@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 <sh...@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 <Ni...@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" <mi...@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.Prokharchyk@citrix.com<ma...@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" <mi...@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.Mehta@citrix.com<ma...@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.tutkowski@solidfire.com<ma...@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.tutkowski@solidfire.com<ma...@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.tutkowski@solidfire.com<ma...@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.tutkowski@solidfire.com<ma...@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.tutkowski@solidfire.com<ma...@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.tutkowski@solidfire.com<ma...@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.tutkowski@solidfire.com<ma...@solidfire.com>
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*

Stratosec<http://stratosec.co/> - Compliance as a Service
o: 415.315.9385
@johnlkinsella<http://twitter.com/johnlkinsella>

Re: Resetting a VM is broken?

Posted by Mike Tutkowski <mi...@solidfire.com>.

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.tutkowski@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.tutkowski@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 <sh...@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 <sh...@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 <Ni...@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" <mi...@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.Prokharchyk@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.tutkowski@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.Mehta@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*

Re: Resetting a VM is broken?

Posted by Mike Tutkowski <mi...@solidfire.com>.

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.tutkowski@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 <sh...@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 <sh...@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 <Ni...@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" <mi...@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.Prokharchyk@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" <mi...@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.Mehta@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*

Re: Resetting a VM is broken?

Posted by Mike Tutkowski <mi...@solidfire.com>.

Yeah, usually "reset" (for hypervisors) means "shut down the VM and
re-start it."


On Wed, Mar 19, 2014 at 6:22 PM, Marcus <sh...@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 <sh...@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 <Ni...@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" <mi...@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.Prokharchyk@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" <mi...@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.Mehta@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*

Re: Resetting a VM is broken?

Posted by Marcus <sh...@gmail.com>.

+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 <sh...@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 <Ni...@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" <mi...@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.Prokharchyk@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" <mi...@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 <Ni...@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" <mi...@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
>>>o: 303.746.7302
>>>Advancing the way the world uses the
>>>cloud<http://solidfire.com/solution/overview/?video=play>
>>>*(tm)*
>>

Re: Resetting a VM is broken?

Posted by Marcus <sh...@gmail.com>.

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 <Ni...@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" <mi...@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.Prokharchyk@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" <mi...@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 <Ni...@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" <mi...@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
>>o: 303.746.7302
>>Advancing the way the world uses the
>>cloud<http://solidfire.com/solution/overview/?video=play>
>>*(tm)*
>

Re: Resetting a VM is broken?

Posted by Nitin Mehta <Ni...@citrix.com>.

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" <mi...@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.Prokharchyk@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" <mi...@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 <Ni...@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" <mi...@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
>o: 303.746.7302
>Advancing the way the world uses the
>cloud<http://solidfire.com/solution/overview/?video=play>
>*(tm)*

Re: Resetting a VM is broken?

Posted by Mike Tutkowski <mi...@solidfire.com>.

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.Prokharchyk@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" <mi...@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 <Ni...@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" <mi...@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*

Re: Resetting a VM is broken?

Posted by Alena Prokharchyk <Al...@citrix.com>.

Alex, 

If you gonna check the code to debug the problem, the method is
cleanupStorage(boolean recurring) in StorageManagerImpl. Its responsible
for both - cleaning up unused templates from the primary store and
removing the volumes marked for Destroy.

Alena.


On 3/20/14, 2:13 AM, "Alex Hitchins" <al...@shapeblue.com> wrote:

>Just on the storage pool cleanup - I'm looking at an issue around this.
>Seems it's not getting called. When it was, it was deleting the template
>file rather than just removing the symlink.
>
>I know this is slightly different, however though it worth mentioning.
>
>
>Regards
>
>Alex Hitchins
>
>D: +44 1892 523 587 | S: +44 2036 030 540 | M: +44 7788 423 969
>
>alex.hitchins@shapeblue.com
>
>-----Original Message-----
>From: Alena Prokharchyk [mailto:Alena.Prokharchyk@citrix.com]
>Sent: 19 March 2014 22:13
>To: dev@cloudstack.apache.org; Mike Tutkowski
>Subject: Re: Resetting a VM is broken?
>
>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" <mi...@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 <Ni...@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" <mi...@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.tutkowski@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.tutkowski@solidfire.com
>>o: 303.746.7302
>>Advancing the way the world uses the
>>cloud<http://solidfire.com/solution/overview/?video=play>
>>*(tm)*
>
>Need Enterprise Grade Support for Apache CloudStack?
>Our CloudStack Infrastructure
>Support<http://shapeblue.com/cloudstack-infrastructure-support/> offers
>the best 24/7 SLA for CloudStack Environments.
>
>Apache CloudStack Bootcamp training courses
>
>**NEW!** CloudStack 4.2.1
>training<http://shapeblue.com/cloudstack-training/>
>18th-19th February 2014, Brazil.
>Classroom<http://shapeblue.com/cloudstack-training/>
>17th-23rd March 2014, Region A. Instructor led,
>On-line<http://shapeblue.com/cloudstack-training/>
>24th-28th March 2014, Region B. Instructor led,
>On-line<http://shapeblue.com/cloudstack-training/>
>16th-20th June 2014, Region A. Instructor led,
>On-line<http://shapeblue.com/cloudstack-training/>
>23rd-27th June 2014, Region B. Instructor led,
>On-line<http://shapeblue.com/cloudstack-training/>
>
>This email and any attachments to it may be confidential and are intended
>solely for the use of the individual to whom it is addressed. Any views
>or opinions expressed are solely those of the author and do not
>necessarily represent those of Shape Blue Ltd or related companies. If
>you are not the intended recipient of this email, you must neither take
>any action based upon its contents, nor copy or show it to anyone. Please
>contact the sender if you believe you have received this email in error.
>Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue
>Services India LLP is a company incorporated in India and is operated
>under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is
>a company incorporated in Brasil and is operated under license from Shape
>Blue Ltd. ShapeBlue is a registered trademark.

RE: Resetting a VM is broken?

Posted by Alex Hitchins <al...@shapeblue.com>.

Just on the storage pool cleanup - I'm looking at an issue around this. Seems it's not getting called. When it was, it was deleting the template file rather than just removing the symlink.

I know this is slightly different, however though it worth mentioning.

Regards

Alex Hitchins

D: +44 1892 523 587 | S: +44 2036 030 540 | M: +44 7788 423 969

alex.hitchins@shapeblue.com

-----Original Message-----
From: Alena Prokharchyk [mailto:Alena.Prokharchyk@citrix.com]
Sent: 19 March 2014 22:13
To: dev@cloudstack.apache.org; Mike Tutkowski
Subject: Re: Resetting a VM is broken?

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" <mi...@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 <Ni...@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" <mi...@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.tutkowski@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.tutkowski@solidfire.com
>o: 303.746.7302
>Advancing the way the world uses the
>cloud<http://solidfire.com/solution/overview/?video=play>
>*(tm)*

Need Enterprise Grade Support for Apache CloudStack?
Our CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/> offers the best 24/7 SLA for CloudStack Environments.

Apache CloudStack Bootcamp training courses

**NEW!** CloudStack 4.2.1 training<http://shapeblue.com/cloudstack-training/>
18th-19th February 2014, Brazil. Classroom<http://shapeblue.com/cloudstack-training/>
17th-23rd March 2014, Region A. Instructor led, On-line<http://shapeblue.com/cloudstack-training/>
24th-28th March 2014, Region B. Instructor led, On-line<http://shapeblue.com/cloudstack-training/>
16th-20th June 2014, Region A. Instructor led, On-line<http://shapeblue.com/cloudstack-training/>
23rd-27th June 2014, Region B. Instructor led, On-line<http://shapeblue.com/cloudstack-training/>

This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue is a registered trademark.

Re: Resetting a VM is broken?

Posted by Alena Prokharchyk <Al...@citrix.com>.

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" <mi...@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 <Ni...@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" <mi...@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.tutkowski@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.tutkowski@solidfire.com
>o: 303.746.7302
>Advancing the way the world uses the
>cloud<http://solidfire.com/solution/overview/?video=play>
>*(tm)*

Re: Resetting a VM is broken?

Posted by Mike Tutkowski <mi...@solidfire.com>.

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 <Ni...@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" <mi...@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*(tm)*

Re: Resetting a VM is broken?

Posted by Nitin Mehta <Ni...@citrix.com>.

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" <mi...@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.tutkowski@solidfire.com
>o: 303.746.7302
>Advancing the way the world uses the
>cloud<http://solidfire.com/solution/overview/?video=play>
>*(tm)*