Cole Robinson wrote:
Michael DeHaan wrote:
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.
I've attached a pretty ugly script I was using just to basically test
this stuff at first. It has hardcoded values specific to my machine
so it won't work if you run it. However it has an example that covers
both of the above cases.
Please read my below comments though regarding the libvirt storage
apis.
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 :)
There won't be any need to mess with xml here.
<snip>
Excellent!
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?
Managed = Libvirt storage APIs. The libvirt storage APIs are how
we know what exists on remote systems, and how we tell remote
systems to create this file with this format, or that partition
with that size, etc.
The 'pool' and 'volume' terminology is all part of this.
http://libvirt.org/storage.html
The gist of it is:
A 'pool' is some resource that can be carved up into units to be
used directly by VMs. Pool types are a directory, nfs mount,
filesystem mount (all carved into flat files), lvm volgroup,
raw disk devices (carved into smaller blk devs), and iscsi
(which creation isn't supported on).
A 'volume' is the carved up unit, directly usable as storage for
a VM.
All this remote guest creation stuff won't 'just work' if the user
passes the correct parameters, the remote host will have to be
configured in advance to teach libvirt about what storage is
available. This could either be done on the command line using
virsh pool-create-as, or use virt-manager and use wizards to
do all this fun stuff (not posted yet. 95% completed and
working, just hasn't been polished up, and it's dependent on
some not committed virtinst work).
Here's what I think would be an interesting use case: I'm looking to
teach koan to do this fully-remotely. The idea is that you have a
provisioning server and you want to be able to remotely declare what you
want to have it it can help make it come into reality.
So in the WebUI for "cobbler system add", I have a button now that says
"Save". I want to be able to have another button that says "Save &
Create On Host" and you could type in what host. Obviously, the
command line for cobbler is where most people would be using it, but
that's another example of how this could be seen to work.
We should probably have libvirt set up a default storage
pool for /var/lib/libvirt/images so that there would be
a typical out of the box option for users.
That would be very good.
If I can do the pool-add stuff remotely via libvirt-remote that would
also be nice, though if I have to do it over SSH that is just the same
as we'd be using the SSH version of libvirt-remote most likely anyway.
I'm pretty sure that either way we can get it to work for a heavily
scriptable remote-deploy API kind of solution. Neat.
- Cole
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
