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

[Michael DeHaan]

Cole Robinson wrote:
> 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
>   

Do you have examples of what this might look like for VirtualDisk?   I'm 
interested in teaching koan how to install on remote hosts.

> 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.
>   
Basically the use cases I care about are:

Install to a specific path and/or filename
Install to an existing partition
Install to a new partition in an existing LVM volume group.

As koan needed to do this before the storage stuff (IIRC) I have code in 
koan to manage LVM.    I'll need to keep it around for support of RHEL 
5.older and F8-previous, so if the new stuff works relatively the same 
that would be great.

Basically if I can pass in a path or LVM volume group name, I'm happy.   
Needing to grok any XML would make me unhappy :)

> 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
>   

What is "managed vs unmanaged" here?

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

What's a pool in context here?     I'm basically trying to make sure 
this is usable without requiring ovirt.

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

A path to a volume group is ok too as we know that just lives under 
/dev/mapper and is easy to get to.


> 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.
>   
IMHO, autodetection would be very nice if it worked just like it was a 
path on the remote system and the only difference was that you were
using a different connection string.   This makes remote work as close 
to local as possible.   If that's not doable that's ok.

> 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 :/
>   

Again, I'm not sure what a "pool" here in context of this library.   
LVMs, mount points, I get :)

Hope that helps?

--Michael


> 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
>
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> et-mgmt-tools mailing list
> et-mgmt-tools at redhat.com
> https://www.redhat.com/mailman/listinfo/et-mgmt-tools