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

David Lutterkort dlutter at redhat.com
Thu Jul 10 21:20:46 UTC 2008


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 ?

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

David





More information about the ovirt-devel mailing list