I would like to discuss a problem that is going to affect VM creation in the new
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 manipulated
by the API.

My preference would be #2 because: it makes the API more closely follow RESTful
principles, it maintains parity with the cluster-level VM manipulation API, and
it makes the API easier to use in standalone mode.

Here is my idea on how this could be accomplished without committing to stateful
host storage.  In the past we have discussed adding an API for storing arbitrary
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 area.

* 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 is
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
later.

* 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 parameters
specified.

* 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.  This
could be done any time a domain is: attached as master, deactivated, and
periodically.

How does this idea sound?  I am certain that it can be improved by those of you
with more experience and different viewpoints.  Thoughts and comments?

-- 
Adam Litke <a...@us.ibm.com>
IBM Linux Technology Center

_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to