[et-mgmt-tools] [RFC] virt-install: remote guest creation

[Cole Robinson]

I've taken a stab at getting remote guest creation up and running
for virt-install. Most of the existing code translates well to the
remote case, but the main issue is storage: how does the user tell
us where to create and find existing storage/media, and how can we
usefully validate this info. The libvirt storage API is the lower
level mechanism that allows this fun stuff to happen, its really
just a matter of choosing a sane interface for it all.

The two interface problems we have are:

- Changes to VirtualDisk to handle storage apis
- Changes to virt-install cli to allow specifying storage info

For VirtualDisk, I added two options
   - volobj     : a libvirt virStorageVol instance
   - volinstall : a virtinst StorageVolume instance

If the user wants the VirtualDisk to use existing storage, they
will need to query libvirt for the virStorageVol and pass this
to the VirtualDisk, which will take care of the rest.

If the user wants to create a new managed volume, they populate
a StorageVolume object (posted earlier but not yet committed)
and pass this VirtualDisk. VirtualDisk will map the setup and
is_size_conflict commands as appropriate, so all current
infrastructure will just work.

Now there wasn't a lot of functionality that needed to be added
to accomplish this, but VirtualDisk was becoming unmaintainable
so I took this opportunity to break it out into it's own file
and clean it up quite a bit. I also added a parent VirtualDevice
class which I will move all the other device classes over to in
the future, but it's not an immediate priority.

The other choices here are to offload looking up storage volumes
to VirtualDisk, or maybe add an option to attempt to lookup
the 'path' parameter as a storage volume if we are on a remote
connection. These could just be options added later though.


The next piece is how the interface changes for virt-install.
Here are the storage use cases we now have:

1) use existing non-managed (local) disk
   - signified by --file /some/real/path

2) create non-managed (local) disk
   - signified by --file /some/real/dir/idontexist

3) create managed disk
   - all we would really need is the pool name to install on.

4) use existing managed disk
   - could be a pool name, vol name combo, or perhaps
     even an absolute path representing a volume.

5) use existing non-managed media (cdrom)
   - signified by --cdrom /some/real/path

6) use existing managed media
   - same syntax as existing managed disk

The options I see are:

A) overload existing options (--file, --cdrom): we can detect we
   are using a remote connection, and try to lookup a passed path
   as a volume. if the user wants to specify pool/vol by name, we
   can use something like 'poolname:volname' for some reasonable
   delimiter. however this could collide with some legitimate 
   storage names so it may not feasible. We could always get
   fancy and allow escaping characters though.

B) Add extra options. To completely get away without having to
   add some 'poolname:volname' type format as above, we would
   probably need a --pool-name and --vol-name, and someway to
   indicate that we want these for cdrom media as well :/

I've currently been testing this with a hacked up version of A.

The only remaining issue is some trouble with Guest objects
expecting the install location to be local, but I'm still
playing with that.

Attached are the new VirtualDisk and VirtualDevice files, this
all works and passes validation testing but I haven't given it
any real polish yet.

Any feedback is appreciated.

Thanks,
Cole


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: VirtualDevice.py
URL: <http://listman.redhat.com/archives/et-mgmt-tools/attachments/20080730/4ee4543a/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: VirtualDisk.py
URL: <http://listman.redhat.com/archives/et-mgmt-tools/attachments/20080730/4ee4543a/attachment-0001.ksh>