Michael DeHaan wrote:
Bryan Kearney wrote:
> Michael DeHaan wrote:
>
>> Bryan Kearney wrote:
>>
>>> 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
>>>
>>>
>> Additionally if not overriden on the command line, it's a combination of
>> the object name and the date.
>>
>>> CobblerImage.arch :: None :: Need to translate this since virt-image
>>> seems to use i686 not i386
>>>
>>>
>> I'd say go ahead and do that.
>>
>>> CobblerImage.file :: image.domain.boot.drive | image.storage.disk@file
>>> :: What is lost is the ability to denote boot drives
>>>
>>>
>> Drives or partitions? If it's just drives, the first one in the list
>> could be the boot drive, no?
>>
> Which list. Can I have more then one entry in the CobblerImage.file
> attribute? If so, how is it seperated?
>
>
Something like
--file=nfs://server/path/image1.raw,nfs://server/path/image2.raw is how
multiple virt disks are handled (except with a different parameter).
Most people do not use more than one virtual disk for traditional
installations.
If --file wanted to store internally as an array, that would be fine by
me, or it could just look for ","'s and split on them if found.
I will look to test out the functionality of a comma separated list.
>>> 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
>>>
>>>
>> Agreed.
>>
>>> 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
>>>
>>>
>> Yep, I've been wanting to remove this, this is related to an earlier
>> attempt to implement this.
>>
>>> 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.
>>>
>>>
>> Cobbler supports any number of bridges, one per interface. You need to
>> define a system object.
>>
>> If you look at xencreate.py and qcreate.py, you can see how this is handled.
>>
> So, in this case I dont think I want to create a system object. The
> virt-image data defines that "This image requires N network interfaces"
> it is at provisioning time this is turned into bridges, or direct
> connections. I would like to be able to deinf the number of nics in in
> the CobblerImage type.
>
Well, you don't know what to do with respect to the configuration of
those nics, in that case, you'd only know how many there were.
Yes, that would be ideal. Then.. allow the user to define this on the
command line. Would you be willing to add this bit of metadata to the
image object?
If you were to assign a mac address, you would have to create the system
object.
So, in this case, the record of the image that acts as the clonable
source is just an image record, but each /installation/ of that image
would need a new corresponding system record in order to assign (and
know) the MAC address of the NICs.
Since that is required to get the IP's reserved and DNS going, system
records are unavoidable.
If you're just using the appliance for ISV demoware, sure, but otherwise
you need to know (and therefore store in cobbler) all of that
information. Since Cobbler is in play, were are talking about datacenter
deployment, and not the demo case.
Given, pending features such as the "auto assign interfaces from network
object" feature we've been talking about for some time, as well as being
able to auto-assign MAC addresses from a free pool will, in the future,
substantially reduce the amount of information you need to feed in to
get this working.
Currently virtual koan per-profile installations get 1 NIC, if you want
more, you have to use system objects.
Can you explain again how systems and images intersect?
>
>>> 2) How to specify more then one file, and which one is a boot drive.
>>>
>>>
>> Currently we can specify more than one virt-disk, though the syntax is a
>> bit kludgy.
>>
>> Basically you just specify multiple --virt-paths, with each value being
>> comma seperated. Internally, I believe this is stored as an array.
>>
>> --virt-path=VolGroup00,VolGroup01 is an example of how you could use two
>> LVM partitions for a virtual machine.
>>
>> --virt-path=/opt/images,/opt/images is another example
>>
>> In the case of using the paths cobbler will name them using the name of
>> the virtual machine image and the disk number, so that they do not collide.
>>
> See the question above, since I will have f raw file already, can I do
> this in the file attribute?
>
>
Sorry, what do you mean by "f raw file" ?
You answered above.. thanks!
>>> 2.1) In addition, how to model a disk as hda, hdb, etc
>>>
>>>
>> I'd be tempted to just use the order here. (Also everything should be
>> /dev/sda now in newer kernels)
>>
>>
>>> 2.2) How to model a disk as system, user, scratch
>>>
>>>
>> I don't understand this part, can you elaborate? They don't just show up
>> as physical disks?
>>
> The metadata allows for the delivery of scratch files. I do not know if
> it is used much. Let me reach out to David on this one.
>
>
>>> 3) Should the image be copied? I believe so, and then perhaps virt_path
>>> is used
>>>
>>>
>> Absolutely needs to be copied. The --file values are going to be NFS
>> sources (just like installer ISO's), but unlike installer ISOs we need
>> to ensure each machine gets it's own storage or the tool won't be very
>> effective. Definitely want to use --virt-path for this.
>>
>>
>>> 4) Virt-image supports defining pygub with a kernel and initrd. There is
>>> no way to model this in the image data
>>>
>>>
>> I'm not sure I understand why virt-image would want to do this. It seems
>> like it would rather want to boot off the disk images and we'd use
>> regular koan (as before) to do kernel+initrd installs.
>>
>> I assume this /might/ be for replacing the kernel+initrd before booting
>> the image though this seems to be a slightly weird use case because it
>> doesn't treat the virtual system like a physical system -- you could
>> also just yum update the kernel, no?
>>
> Again, the virt-image data lets me bundle this as a transportable item.
> If the goal is to push the image data into cobbler, and hten back out, I
> would need a place to store this.
>
>
I need to understand the use case here. Perhaps this feature could just
not be supported? If we are talking about a workflow that is:
(A) install a virt image however and customize it
(B) copy it into cobbler using the appliance tools for mass-cloning
(C) use koan to mass-clone it
It doesn't seem like there is a need to keep the kernel/initrd outside
when they are already in the disk image. Pygrub is a Xen paravirt thing,
sure, but in that case it dives inside the image to get the
kernel+initrd out, so you wouldn't have to track it seperately. No?
The use case which I was assuming was the following:
(I) I have a an appliance bundle. Defined as a virt-image.xml file and
1-n disks. This is an output of the appliance-creator, virt-converter,
or some other means.
(II) I install it to cobber for mass cloning. This represents all
necessary virt-image.xml data as cobbler metadata.
(III) use koan to mass clone it.
The issue is that the appliance bundler supports 2 different modesl. One
is a HVM model where the kernel and initrd are in the image. The second
is a PV model where the kernel and inird are external to the image (but
in the bundle). I currently have no way to model the second type in the
cobbler metadata.
One last thing, can you take a peek at the latest version at [1]? It
implements most of what we discussed except for the the multiple files.
Since the virt-install libraries are an abstraction layer themselves, I
would like to know the user provided virt-type in order to use the
correct connection. Would you have an issue with adding this to the
start_install API?
-- bk
[1]
http://github.com/bkearney/koan/tree/devel