Cool, we'll take a look at CreateCommand. I like your suggestion to tweak the execute method to accomplish this.
We are literally getting our feet wet at this point, and have some ideas that we are looking to implement in a NetApp plugin to CS. Hopefully we'll get to meet some of you at the CCC in a couple of weeks and share some of those ideas. David La Motta Technical Marketing Engineer Citrix Solutions NetApp 919.476.5042 dlamo...@netapp.com<mailto:dlamo...@netapp.com> On Jun 13, 2013, at 11:37 AM, Marcus Sorensen <shadow...@gmail.com<mailto:shadow...@gmail.com>> wrote: CreateCommand in the agent code is responsible for making a template into a new volume. With Xen and VMware, you're limited to what the hypervisor is capable of as far as storage cloning to create a new copy from an existing template on your primary storage. With KVM, you can create your own storage adapter and handle this however you want. That said, we've used the plugin functionality of CloudStack to create a few convenience commands (mostly simple things like getting the vnc port/host for a vm so we don't have to rely on the consoleproxy vm), and one of the things we have done is a clone volume. The plugin provides an API call that accepts an existing volume id, talks to the backend storage to do the clone, then creates a new volume object and persists it to the database. I'm sure this will be made easier by Edison's storage framework. Another thing we've done via plugin is to extend the deployVirtualMachine call so that we can create a VM and add resource tags to it in one call. The deployVirtualMachine api call has two primary methods, create and execute. By leaving create intact, and overriding execute, you can do fun things like edit the vm definition before it gets started for the first time. Looking through the deploy code, it looks like if the VM's associated root volume is in a ready state, it will ignore the template and just start the VM. So you could create a registerVirtualMachine api call whose execute method generates a volume via some clone method (or accepts some parameter that identifies a volume path or whatever is needed), sets the ROOT volume for the vm to be that volume, and then starts the vm (or not, depending on whether the startvm parameter from deployVirtualMachine was set). Once we figured out the plugin system we realized that we can do *almost* anything we want in cloudstack, but it requires some developer time. On Thu, Jun 13, 2013 at 7:49 AM, La Motta, David <david.lamo...@netapp.com<mailto:david.lamo...@netapp.com>> wrote: Looking at this in more detail, that's not going to do it. If we have to create a template and call deployVirtualMachine, that will do--intentionally--what it was intended to do: spin up a new VM in the hypervisor and allocate a chunk of disk out of primary storage. What we are looking to do, while still attempting to maintain vendor neutrality, would require a registerVirtualMachine method. With such a thing, anybody can drop an instance (thinking in terms of a root volume, and/or a data disk) on primary storage, then invoke the register method to make CloudStack _and_ the hypervisor aware of the new instance. This would allow rapid cloning of VMs to be offloaded to the storage layer, and then the registration just connects the dots between CS and the hypervisor, which would be another fast operation. If there is a way to do that today, by all means we are happy to take a look and go down that path. If there isn't, it seems that this registerVirtualMachine method could be a modified version of deployVirtualMachine, without the disk creation piece. Of course, there are other intricacies to take care of (UUIDs, naming and such), so by no means a super trivial task. Is there any expert in this area who can shed some light on the topic? We (NetApp) have created other products which have plugins for XenServer and vSphere that do just that: take advantage of hardware level cloning techniques, then make those clones available to the hypervisor. So, with all the CS code for dealing with the hypervisors, to me it seems like we could be close to providing such a registerVirtualMachine, given a pointer to the actual disk on storage. How that VM disk makes it to storage is another story, one that CS doesn't have to concern itself, IMO. Thx! David La Motta Technical Marketing Engineer Citrix Solutions NetApp 919.476.5042 dlamo...@netapp.com<mailto:dlamo...@netapp.com><mailto:dlamo...@netapp.com> On Jun 12, 2013, at 10:57 AM, "La Motta, David" <david.lamo...@netapp.com<mailto:david.lamo...@netapp.com><mailto:david.lamo...@netapp.com>> wrote: Nope! That's the one I was looking for. Too close to destroyVirtualMachine… didn't even see it ;-) Thanks again. David La Motta Technical Marketing Engineer Citrix Solutions NetApp 919.476.5042 dlamo...@netapp.com<mailto:dlamo...@netapp.com><mailto:dlamo...@netapp.com><mailto:dlamo...@netapp.com> On Jun 12, 2013, at 10:54 AM, Chip Childers <chip.child...@sungard.com<mailto:chip.child...@sungard.com><mailto:chip.child...@sungard.com><mailto:chip.child...@sungard.com>> wrote: On Wed, Jun 12, 2013 at 02:49:42PM +0000, La Motta, David wrote: Ok, thanks. So it is doable. The question now being how fast this process will be, since the VM creation will ultimately be done on the hypervisor. What is the API that I could use to create a VM from a template? I am looking at the 4.1 REST API and there is nothing for creating under the Virtual Machine section for Root, Domain, or User. Thanks, Chip. You always have to specify a templateid param for the deployVirtualMachine API call [1]. Are you looking at some other API call? -chip [1] http://cloudstack.apache.org/docs/api/apidocs-4.1/user/deployVirtualMachine.html
