Michael: Looks like there is no current support for doing images via virt-image. Is that correct? If so... are you open to looking at that type of integration? -- bk _______________________________________________ cobbler mailing list cobbler(a)lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler

Michael DeHaan wrote: > Bryan Kearney wrote: > >> Michael: >> >> Looks like there is no current support for doing images via virt-image. >> Is that correct? If so... are you open to looking at that type of >> integration? >> >> -- bk >> _______________________________________________ >> cobbler mailing list >> cobbler(a)lists.fedorahosted.org >> https://fedorahosted.org/mailman/listinfo/cobbler >> >> > We are entirely interested in this. > > The idea is to do: > > cobbler image add --name=foo --type=virtimage > --file=nfs://server/path/to/img.foo > > koan --virt --image=foo --server=cobbler.example.com > > and to be able to use cobbler for image cloning. > > To do this, we must have a simple way for users to get the XML data from > something like virt-convert and save it in cobbler. > > This way users will be able to go into cobbler and up the RAM amounts > (or override them in koan) without having to hand-edit XML. > > Then, from koan, we essentially would be regenerating the XML from the > template and calling virt-image. > > Somewhat complicated ... but something I've wanted to do for a while. > I've been waiting for virt-convert to gain some features, which I > suspect are here now? > > Yes, I believe so. Or.. I could see passing in the image add with all the necessary data (see earlier post on ruby). Do you have some time tomorrow to whiteboard/gobby this up? I think the next interesting steps for the adk would be to begin to resolve getting these images into cobbler (and then onto disk).

-- bk _______________________________________________ cobbler mailing list cobbler(a)lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler

Michael DeHaan wrote: > Bryan Kearney wrote: > >> Michael DeHaan wrote: >> >> >>> Bryan Kearney wrote: >>> >>> >>>> Michael: >>>> >>>> Looks like there is no current support for doing images via virt-image. >>>> Is that correct? If so... are you open to looking at that type of >>>> integration? >>>> >>>> -- bk >>>> _______________________________________________ >>>> cobbler mailing list >>>> cobbler(a)lists.fedorahosted.org >>>> https://fedorahosted.org/mailman/listinfo/cobbler >>>> >>>> >>>> >>> We are entirely interested in this. >>> >>> The idea is to do: >>> >>> cobbler image add --name=foo --type=virtimage >>> --file=nfs://server/path/to/img.foo >>> >>> koan --virt --image=foo --server=cobbler.example.com >>> >>> and to be able to use cobbler for image cloning. >>> >>> To do this, we must have a simple way for users to get the XML data from >>> something like virt-convert and save it in cobbler. >>> >>> This way users will be able to go into cobbler and up the RAM amounts >>> (or override them in koan) without having to hand-edit XML. >>> >>> Then, from koan, we essentially would be regenerating the XML from the >>> template and calling virt-image. >>> >>> Somewhat complicated ... but something I've wanted to do for a while. >>> I've been waiting for virt-convert to gain some features, which I >>> suspect are here now? >>> >>> >>> >> Yes, I believe so. Or.. I could see passing in the image add with all >> the necessary data (see earlier post on ruby). Do you have some time >> tomorrow to whiteboard/gobby this up? I think the next interesting steps >> for the adk would be to begin to resolve getting these images into >> cobbler (and then onto disk). >> >> > Yeah, if the ADK could just generate "cobbler image add" line with all > of the associated parameters that would make sense to me. > We got that! > We would still need to koan to form up the command line to instantiate > it on the other end, but that would be pretty easy. > > If you are going to be deploying virt-images instead of kickstarting > them, most likely folks are doing it to heavily customize the image, so > going > that way through the toolchain seems completely reasonable. > > (Otherwise folks can install as they do now with koan). > So.. this is what I would like to chat about. How would you see this being implemented? -- bk _______________________________________________ cobbler mailing list cobbler(a)lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler

Michael DeHaan wrote: > Bryan Kearney wrote: > >> Michael DeHaan wrote: >> >> >>> Bryan Kearney wrote: >>> >>> >>>> Michael DeHaan wrote: >>>> >>>> >>>> >>>>> Bryan Kearney wrote: >>>>> >>>>> >>>>> >>>>>> Michael: >>>>>> >>>>>> Looks like there is no current support for doing images via virt-image. >>>>>> Is that correct? If so... are you open to looking at that type of >>>>>> integration? >>>>>> >>>>>> -- bk >>>>>> _______________________________________________ >>>>>> cobbler mailing list >>>>>> cobbler(a)lists.fedorahosted.org >>>>>> https://fedorahosted.org/mailman/listinfo/cobbler >>>>>> >>>>>> >>>>>> >>>>>> >>>>> We are entirely interested in this. >>>>> >>>>> The idea is to do: >>>>> >>>>> cobbler image add --name=foo --type=virtimage >>>>> --file=nfs://server/path/to/img.foo >>>>> >>>>> koan --virt --image=foo --server=cobbler.example.com >>>>> >>>>> and to be able to use cobbler for image cloning. >>>>> >>>>> To do this, we must have a simple way for users to get the XML data from >>>>> something like virt-convert and save it in cobbler. >>>>> >>>>> This way users will be able to go into cobbler and up the RAM amounts >>>>> (or override them in koan) without having to hand-edit XML. >>>>> >>>>> Then, from koan, we essentially would be regenerating the XML from the >>>>> template and calling virt-image. >>>>> >>>>> Somewhat complicated ... but something I've wanted to do for a while. >>>>> I've been waiting for virt-convert to gain some features, which I >>>>> suspect are here now? >>>>> >>>>> >>>>> >>>>> >>>> Yes, I believe so. Or.. I could see passing in the image add with all >>>> the necessary data (see earlier post on ruby). Do you have some time >>>> tomorrow to whiteboard/gobby this up? I think the next interesting steps >>>> for the adk would be to begin to resolve getting these images into >>>> cobbler (and then onto disk). >>>> >>>> >>>> >>> Yeah, if the ADK could just generate "cobbler image add" line with all >>> of the associated parameters that would make sense to me. >>> >>> >> We got that! >> >> >> >>> We would still need to koan to form up the command line to instantiate >>> it on the other end, but that would be pretty easy. >>> >>> If you are going to be deploying virt-images instead of kickstarting >>> them, most likely folks are doing it to heavily customize the image, so >>> going >>> that way through the toolchain seems completely reasonable. >>> >>> (Otherwise folks can install as they do now with koan). >>> >>> >> So.. this is what I would like to chat about. How would you see this >> being implemented? >> >> -- bk >> _______________________________________________ >> cobbler mailing list >> cobbler(a)lists.fedorahosted.org >> https://fedorahosted.org/mailman/listinfo/cobbler >> >> > Most likely koan just needs something along the lines of "xencreate.py" > and "qcreate.py" except for images. There's a function in koan's app.py > that chooses which module to use. > > Right now the image objects can also be used to deploy installer media > ISOs (use case example: deploying Windows on KVM when the Windows ISO > resides on NFS), so you'll also want to pay attention of the "image > type" (which will be something like "raw" instead of "iso") as well as > the "virt-type" (which should use something like "virtimage" as the > value in koan/Cobbler). > I am beginning to add the code, which you can see here (does not run yet): http://github.com/bkearney/koan/tree/e0df23996363c638e9dfb30f3091f57f0164... Just off the top of my head, I can see the following things which I may want to discuss: 1) Images which have multiple disks 2) Images which have multiple nics 3) Image copying and nfs But I will summarize when I get a running version. -- bk

_______________________________________________ cobbler mailing list cobbler(a)lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler

Michael DeHaan wrote: > Bryan Kearney wrote: > >> Michael DeHaan wrote: >> >> >>> Bryan Kearney wrote: >>> >>> >>>> Michael DeHaan wrote: >>>> >>>> >>>> >>>>> Bryan Kearney wrote: >>>>> >>>>> >>>>> >>>>>> Michael DeHaan wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Bryan Kearney wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Michael: >>>>>>>> >>>>>>>> Looks like there is no current support for doing images via virt-image. >>>>>>>> Is that correct? If so... are you open to looking at that type of >>>>>>>> integration? >>>>>>>> >>>>>>>> -- bk >>>>>>>> _______________________________________________ >>>>>>>> cobbler mailing list >>>>>>>> cobbler(a)lists.fedorahosted.org >>>>>>>> https://fedorahosted.org/mailman/listinfo/cobbler >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> We are entirely interested in this. >>>>>>> >>>>>>> The idea is to do: >>>>>>> >>>>>>> cobbler image add --name=foo --type=virtimage >>>>>>> --file=nfs://server/path/to/img.foo >>>>>>> >>>>>>> koan --virt --image=foo --server=cobbler.example.com >>>>>>> >>>>>>> and to be able to use cobbler for image cloning. >>>>>>> >>>>>>> To do this, we must have a simple way for users to get the XML data from >>>>>>> something like virt-convert and save it in cobbler. >>>>>>> >>>>>>> This way users will be able to go into cobbler and up the RAM amounts >>>>>>> (or override them in koan) without having to hand-edit XML. >>>>>>> >>>>>>> Then, from koan, we essentially would be regenerating the XML from the >>>>>>> template and calling virt-image. >>>>>>> >>>>>>> Somewhat complicated ... but something I've wanted to do for a while. >>>>>>> I've been waiting for virt-convert to gain some features, which I >>>>>>> suspect are here now? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Yes, I believe so. Or.. I could see passing in the image add with all >>>>>> the necessary data (see earlier post on ruby). Do you have some time >>>>>> tomorrow to whiteboard/gobby this up? I think the next interesting steps >>>>>> for the adk would be to begin to resolve getting these images into >>>>>> cobbler (and then onto disk). >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Yeah, if the ADK could just generate "cobbler image add" line with all >>>>> of the associated parameters that would make sense to me. >>>>> >>>>> >>>>> >>>> We got that! >>>> >>>> >>>> >>>> >>>>> We would still need to koan to form up the command line to instantiate >>>>> it on the other end, but that would be pretty easy. >>>>> >>>>> If you are going to be deploying virt-images instead of kickstarting >>>>> them, most likely folks are doing it to heavily customize the image, so >>>>> going >>>>> that way through the toolchain seems completely reasonable. >>>>> >>>>> (Otherwise folks can install as they do now with koan). >>>>> >>>>> >>>>> >>>> So.. this is what I would like to chat about. How would you see this >>>> being implemented? >>>> >>>> -- bk >>>> _______________________________________________ >>>> cobbler mailing list >>>> cobbler(a)lists.fedorahosted.org >>>> https://fedorahosted.org/mailman/listinfo/cobbler >>>> >>>> >>>> >>> Most likely koan just needs something along the lines of "xencreate.py" >>> and "qcreate.py" except for images. There's a function in koan's app.py >>> that chooses which module to use. >>> >>> Right now the image objects can also be used to deploy installer media >>> ISOs (use case example: deploying Windows on KVM when the Windows ISO >>> resides on NFS), so you'll also want to pay attention of the "image >>> type" (which will be something like "raw" instead of "iso") as well as >>> the "virt-type" (which should use something like "virtimage" as the >>> value in koan/Cobbler). >>> >>> >> I am beginning to add the code, which you can see here (does not run yet): >> >> http://github.com/bkearney/koan/tree/e0df23996363c638e9dfb30f3091f57f0164... >> >> Just off the top of my head, I can see the following things which I may >> want to discuss: >> >> 1) Images which have multiple disks >> 2) Images which have multiple nics >> 3) Image copying and nfs >> >> But I will summarize when I get a running version. >> >> -- bk >> >> >> >> > Haven't looked at the above yet, but... > > (1) --virt-disks is already dealt with in koan to support multiple > disks, so I expect we could do similar. > (2) see how interfaces are dealt with in koan (particularly when using > --system instead of --profile) ... it defaults to 1 interface unless the > system record has more, in which case it pulls that information from the > system interface and you can have any number. > I will look at this, but I have been looking to map the virt-image.xml file into the image description.. so if it is command line only it may be an issue. But.. I will look! -- bk

> (3) Possibly we could use --virt-path for the destination to copy to, > should LVM volume group destinations also be supported? We do this for > Xen and KVM presently. > > > >> _______________________________________________ >> 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

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 _______________________________________________ cobbler mailing list cobbler(a)lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler

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?

>> 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.

>> 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?

>> 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.

>> 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

>> 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?

>>>> 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 _______________________________________________ cobbler mailing list cobbler(a)lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler