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