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

[Michael DeHaan]

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