No comments at all on this??
On Wed, May 09, 2012 at 09:35:29AM -0500, Adam Litke wrote:
> I would like to discuss a problem that is going to affect VM creation in the
> REST API. This topic has come up previously and I want to revive that
> discussion because it is blocking a proper implementation of VM.create().
> Consider a RESTful VM creation sequence:
> POST /api/vms/define - Define a new VM in the system
> POST /api/vms/<id>/disks/add - Add a new disk to the VM
> POST /api/vms/<id>/cdroms/add - Add a cdrom
> POST /api/vms/<id>/nics/add - Add a NIC
> PUT /api/vms/<id> - Change boot sequence
> POST /api/vms/<id>/start - Boot the VM
> Unfortunately this is not possible today with vdsm because a VM must be
> fully-specified at the time of creation and it will be started immediately.
> As I see it there are two ways forward:
> 1.) Deviate from a REST model and require a VM resource definition to include
> all sub-collections inline.
> -- or --
> 2.) Support storage of vm definitions so that powered off VMs can be
> by the API.
> My preference would be #2 because: it makes the API more closely follow
> principles, it maintains parity with the cluster-level VM manipulation API,
> it makes the API easier to use in standalone mode.
> Here is my idea on how this could be accomplished without committing to
> host storage. In the past we have discussed adding an API for storing
> metadata blobs on the master storage domain. If this API were available we
> could use it to create a transient VM "construction site". Let's walk through
> the above RESTful sequence again and see how my idea would work in practice:
> * POST /api/vms/define - Define a new VM in the system
> A new VM definition would be written to the master storage domain metadata
> * GET /api/vms/<new-uuid>
> The normal 'list' API is consulted as usual. The VM will not be found there
> because it is not yet created. Next, the metadata area is consulted. The VM
> found there and will be returned. The VM state will be 'New'.
> * POST /api/vms/<id>/disks/add - Add a new disk to the VM
> For 'New' VMs, this will update the VM metadata blob with the new disk
> information. Otherwise, this will call the hotplugDisk API.
> * POST /api/vms/<id>/cdroms/add - Add a cdrom
> For 'New' VMs, this will update the VM metadata blob with the new cdrom
> information. If we want to support hotplugged CDROMs we can call that API
> * POST /api/vms/<id>/nics/add - Add a NIC
> For 'New' VMs, this will update the VM metadata blob with the new nic
> information. Otherwise it triggers the hotplugNic API.
> * PUT /api/vms/<id> - Change boot sequence
> Only valid for 'New' VMs. Updates the metadata blob according to the
> * POST /api/vms/<id>/start - Boot the VM
> Load the metadata from the master storage domain metadata area. Call the
> VM.create() API. Remove the metadata from the master storage domain.
> VDSM will automatically purge old metadata from the master storage domain.
> could be done any time a domain is: attached as master, deactivated, and
> How does this idea sound? I am certain that it can be improved by those of
> with more experience and different viewpoints. Thoughts and comments?
> Adam Litke <a...@us.ibm.com>
> IBM Linux Technology Center
> vdsm-devel mailing list
Adam Litke <a...@us.ibm.com>
IBM Linux Technology Center
vdsm-devel mailing list