[et-mgmt-tools] [Fwd: Cobbler -> virt-image.xml mapping]

Bryan Kearney bkearney at redhat.com
Tue Nov 4 15:09:27 UTC 2008


I sent the following email to the cobbler list. If folks have any 
comments on Cobbler -> Virt-image mappings I would love to hear them.

The goal is to be able to create an image with the appliance tools, and 
push that image into cobbler for provisioning. Ideally, cobbler would 
hold all the information required to drive the virt-image logic from 
within koan.

If you follow a link in the email you can see see a WIP code. It is 
deploying the images on a local machine, but not yet assigning networks.

-- bk

-------- Original Message --------
Subject: Cobbler -> virt-image.xml mapping
Date: Tue, 04 Nov 2008 10:06:30 -0500
From: Bryan Kearney <bkearney at redhat.com>
To: cobbler mailing list <cobbler at lists.fedorahosted.org>
References: <49021DA9.3010106 at redhat.com> 
<490A37EA.6040708 at redhat.com>	<490A3798.2060102 at redhat.com> 
<490B2494.3060002 at redhat.com>	<490B24C2.80400 at redhat.com> 
<490B2F4D.6030308 at redhat.com>	<490F7684.9050308 at redhat.com> 
<490F7E30.7040801 at redhat.com>	<490FA1FD.3050303 at redhat.com> 
<490FA56D.302 at redhat.com>

As part of adding the ability to deploy images in Cobbler via koan and
virt-image I did a quick mapping between the Cobbler Image metadata and
the metadata in the virt-image xml file. The mapping is below. I have 4
issues which I believe need to be addressed in the image metadata.

Current code (deploys with no networks) can be seen here at [1]

-- bk


Mapping
=======
Cobbler :: Virt-Image-XML :: Notes
CobblerImage.name :: image.name :: Overridden at command line
CobblerImage.arch :: None :: Need to translate this since virt-image
seems to use i686 not i386
CobblerImage.file :: image.domain.boot.drive | image.storage.disk at file
:: What is lost is the ability to denote boot drives
CobblerImage.parent :: None :: Not needed as this is internal cobbler logic
CobblerImage.depth :: None :: Not needed as this is internal cobbler logic
CobblerImage.owners :: None :: Not needed as this is internal cobbler logic
CobblerImage.virt_ram :: image.domain.devices.memory ::
CobblerImage.virt_file_size :: None ::
CobblerImage.virt_path :: :: See issue 3
CobblerImage.virt_cpus :: image.domain.devices.vcpu ::
CobblerImage.virt_type :: image.domain.boot at type |
image.domain.boot.os.loader at dev :: See Issue 4
CobblerImage.virt_bridge :: :: See issue 1
CobblerImage.xml_file :: None :: No need to store the file, virt-image
is called directlry
CobblerImage.image_type :: virt-clone :: May need to break this down
once we resolve the issues below
CobblerImage.breed, :: None ::
CobblerImage.os_version, :: None ::


Issues
======
1) Cobbler supports one bridge while the virt-image.xml can support
denoting more then one interface.
2) How to specify more then one file, and which one is a boot drive.
2.1) In addition, how to model a disk as hda, hdb, etc
2.2) How to model a disk as system, user, scratch
3) Should the image be copied? I believe so, and then perhaps virt_path
is used
4) Virt-image supports defining pygub with a kernel and initrd. There is
no way to model this in the image data



Defined at install time, not in metadata
========================================
image.domain.devices.graphics


Optional: Not Mapped
====================
image.name at version
image.name at release
image.label
image.description
image.boot.features.pae
image.boot.features.acpi
image.boot.features.apic
image.storage.disk at size
image.storage.disk at format
image.storage.disk.checksum


[1] http://github.com/bkearney/koan/tree/devel





More information about the et-mgmt-tools mailing list