[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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 redhat com>
To: cobbler mailing list <cobbler lists fedorahosted org>
References: <49021DA9 3010106 redhat com> <490A37EA 6040708 redhat com> <490A3798 2060102 redhat com> <490B2494 3060002 redhat com> <490B24C2 80400 redhat com> <490B2F4D 6030308 redhat com> <490F7684 9050308 redhat com> <490F7E30 7040801 redhat com> <490FA1FD 3050303 redhat com> <490FA56D 302 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 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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]