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@xxxxxxxxxx>
To: cobbler mailing list <cobbler@xxxxxxxxxxxxxxxxxxxxxx>
References: <49021DA9.3010106@xxxxxxxxxx>
<490A37EA.6040708@xxxxxxxxxx> <490A3798.2060102@xxxxxxxxxx>
<490B2494.3060002@xxxxxxxxxx> <490B24C2.80400@xxxxxxxxxx>
<490B2F4D.6030308@xxxxxxxxxx> <490F7684.9050308@xxxxxxxxxx>
<490F7E30.7040801@xxxxxxxxxx> <490FA1FD.3050303@xxxxxxxxxx>
<490FA56D.302@xxxxxxxxxx>
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@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@type |
image.domain.boot.os.loader@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@version
image.name@release
image.label
image.description
image.boot.features.pae
image.boot.features.acpi
image.boot.features.apic
image.storage.disk@size
image.storage.disk@format
image.storage.disk.checksum
[1] http://github.com/bkearney/koan/tree/devel
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
