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 [mailto:alex.hu...@citrix.com] Sent: Friday, December 28, 2012 10:31 AM To: cloudstack-dev@incubator.apache.org Subject: RE: [DISCUSS] Virtual machine's Base Image Updatation Facility > -----Original Message----- > From: David Nalley [mailto:da...@gnsa.us] > Sent: Thursday, December 27, 2012 7:40 AM > To: cloudstack-dev@incubator.apache.org > Subject: Re: [DISCUSS] Virtual machine's Base Image Updatation > Facility > > On Wed, Dec 26, 2012 at 3:47 PM, Chiradeep Vittal > <chiradeep.vit...@citrix.com> 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? --Alex
