[Ovirt-devel] Details about pending cobbler image support & ovirt integration

[Michael DeHaan]

David Lutterkort wrote:
> On Wed, 2008-07-09 at 09:28 -0400, Michael DeHaan wrote:
>   
>> Images are the new object.   We want cobbler to track them like other 
>> objects.
>>
>>     # cobbler image add --name=QuestionableRemondInstallISO 
>> --file=/mnt/nfs/blah/foo.img
>>     
>
> Are images also meant for bare-metal installs or only for VM installs ?
>   

Hopefully both ... I'm doing VMs first.     If Linux must be a 
hypervisor for non-Linux
OS's that is not such a bad universe :)

>> After that, we also teach "cobbler image add" to track images that can 
>> be fed to virt-image, AKA virt disk images.   This will have a similar 
>> syntax, most likely...
>>
>> # cobbler image add --name=MysteryOS --file=/mnt/nfs/blah/foo.img 
>> --image-type=blah [--virt-ram=] [--virt-disk=] [etc]
>>
>> The --virt parameters will work basically as they do with cobbler 
>> profiles today.
>>     
>
> It would be much simpler for VM images to tell cobbler to add an
> image.xml; all the parameters above are listed in that, and adding a VM
> image to a cobbler server would be as simple as
>         
>         # cobbler image add /foo/bar/image.xml
>   

That would be doable for virt-image cloning where we have a way to 
source it from.   For ISO installs, admins generally don't like to create
XML, so as with virt-install, there needs to be a way to enter it.

To do the above, I really need a utility to extract the XML config 
needed by virt-image from a running/happy guest.
Can we do that?

>         
> and koan would basically take the same command line args as virt-image;
> the only thing on top of what virt-image does is that koan would have to
> make the actual disk files available on the local host.
>
> There's one small wrinkle: when you instantiate from an image, you can
> treat that image either as an immutable template (in which case you'd
> have to copy the disk files) or as the image for a specific VM (in which
> case you'd directly use the disk files to back the VM)
>
>   
>> The next logical step after handling virt-images is perhaps teaching 
>> cobbler about physical images and cloning tools, though I'm much more 
>> interested in the virt case, as I have no problem if all the hypervisors 
>> out there have to run Linux :)
>>     
>
> Heh .. yeah, definitely the more interesting first step.
>
>   
>> The other thing we might want to talk about are cobbler triggers, which 
>> could be written to notify ovirt of changes to the cobbler configuration 
>> -- this is similar to something we are planning with Spacewalk.   In 
>> general, I think ovirt would mostly be giving orders to cobbler, but if 
>> someone makes a change outside of cobbler, like deleting a virt-image 
>> ovirt wants to have used, it should probably have a way of knowing it 
>> should re-scan cobbler XMLRPC to see what changed.
>>     
>
> Yeah, might definitely be useful; though very very soon we'll all be
> talking amqp, and ovirt can just pick notifications off the bus, right ?
>   

An AMQP notification trigger is definitely possible.  (or dbus, though 
remoteness is always
preferable).

> David
>
>
>