cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Abhinandan Prateek <>
Subject Re: [DISCUSS] Virtual machine's Base Image Updatation Facility
Date Fri, 18 Jan 2013 08:47:23 GMT

+1 (binding) to start implementation.

I see that all the changes have been incorporated in the FS


On 03/01/13 6:00 AM, "Hari Kannan" <> wrote:

>I wish to restate this a bit differently -
>The orchestration being requested here is:
>* (possibly) stop vm
>* disconnect root disk
>* destroy root disk
>* create a new disk from (possibly new) template
>* attach new disk as root disk to the vm
>* (possibly) start vm.
>This is something we support for system vms already.
>The existing api is restoreVm(vm_id)
>The changed api is restoreVm(vm_id, new_template_id)
>In addition, I wish to add the following -
>A third parameter (a flag) can be specified whether to restart or not (or
>we can assume always start after stop).  i.e. have a method that resets a
>VM on reboot.   The use cases for this are:
>- Secure environments that need a fresh start on every boot
>- Desktops that should not retain state
>Hari Kannan
>-----Original Message-----
>From: Alex Huang []
>Sent: Friday, December 28, 2012 10:31 AM
>Subject: RE: [DISCUSS] Virtual machine's Base Image Updatation Facility
>> -----Original Message-----
>> From: David Nalley []
>> Sent: Thursday, December 27, 2012 7:40 AM
>> To:
>> Subject: Re: [DISCUSS] Virtual machine's Base Image Updatation
>> Facility
>> On Wed, Dec 26, 2012 at 3:47 PM, Chiradeep Vittal
>> <> wrote:
>> > Templates should be immutable --if there is a new version created,
>> > then it is another template.
>> > The api should just take a reference to the new template and not try
>> > to deal with trickiness around updating templates. That workflow
>> > (versioning
>> > templates) is a different ball of wax entirely.
>> >
>> Agreed.
>> Templates should be immutable.
>> Additionally - the sysadmin side of me doesn't understand why I'd want
>> to do this at all. The template exists to get me to JEOS running - not
>> to manage updates. I (should) have tools that handle keeping all of my
>> deployed VMs in a consistent state, and updated to the proper version.
>> Trying to turn CloudStack into a patch management/package management
>> service seems a bit too much scope creep IMO.
>I would modify that just a little bit.  Deployed templates are immutable.
> So if someone updates a template, only new VMs are deployed with the
>update.  Original VMs are still based off the original.  I see a ton of
>problems if we try to rebase the VMs to the new template.  To take care
>of the corruption case (corruption of the base on the primary storage),
>you can rebase but it's to the exact copy of the original template so
>that shouldn't be a problem.
>I think this feature can only be used for operators who deployed links to
>the templates and don't want to keep updating links when they update
>templates, which makes sense.  But it can be done with the following
>small change.
>Feature implementation
>- Provide an externally created unique id on vm template.
>- Allow access to templates based on externally created ids.
>NOTE: In the end that this really means is the uuid column can actually
>be set by the caller as long as it's unique.
>For the operator
>- someone creates the template with an externally created unique id.
>- All references to that template is with the externally created unique
>id.  So if they put the link to that template on a page, it has to be
>with their ids.
>- When a template should be updated, just delete the old one and create a
>new one with the same externally created id.
>Is there any other use case requirements?

View raw message