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
It's in the API as well, not just the command line.
Would be happy to help however needed, just let me know.
I would think it would be possible to make the XML file be rendered out
by Cheetah if we do it right, though I'm not entirely clear on specifics
yet. We might want to add another API call for that
(get_image_xml_for_image, get_image_xml_for_system ?)
--Michael
> (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