11:20 a.m.
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.
>> 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.
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.
>> 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" ?
>> 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?
>> Defined at install time, not in metadata
>> ========================================
>> image.domain.devices.graphics
>>
>>
>>
>>
> This is the "use VNC or not"? With KVM, you have to use VNC, otherwise
> you have no console.
>
> We could, if needed, look at adding this to cobbler
> profiles/images/systems as an option and then replace koan's --nogfx
> with --graphics=0/1 if absolutely needed, though in general I'd say
> leave it on all the time.
>
> Most people will be using the image options with KVM, and to disable the
> KVM console makes it relatively useless -- there is no "virsh" analog
> set up by default.
>
>
>> 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
>>
>> _______________________________________________
>> cobbler mailing list
>> cobbler(a)lists.fedorahosted.org
>> https://fedorahosted.org/mailman/listinfo/cobbler
>>
>>
> _______________________________________________
> cobbler mailing list
> cobbler(a)lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/cobbler
>
_______________________________________________
cobbler mailing list
cobbler(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler