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