2:10 p.m.
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
5:39 p.m.
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
5:40 p.m.
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?
--Michael
10:30 a.m.
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 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).
--Michael
-- bk
_______________________________________________
cobbler mailing list
cobbler(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler
10:31 a.m.
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
11:16 a.m.
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).
4:09 p.m.
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
4:41 p.m.
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.
(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
7:14 p.m.
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
7:29 p.m.
Bryan Kearney wrote:
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
9:06 a.m.
New subject: Cobbler -> virt-image.xml mapping
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
9:21 a.m.
New subject: Cobbler -> virt-image.xml mapping
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?
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.
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.
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?
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?
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
10:26 a.m.
New subject: Cobbler -> virt-image.xml mapping
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
11:20 a.m.
New subject: Cobbler -> virt-image.xml mapping
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
3:59 p.m.
New subject: Cobbler -> virt-image.xml mapping
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
3:59 p.m.
New subject: Cobbler -> virt-image.xml mapping
>> 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?
Yes, this sounds reasonable.
--required-interfaces=N, default=1 ?
> 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?
There are two object chains possible in Cobbler:
distro -> profile -> system
image -> system
Basically a system is binding of another cobbler object to a specific
hardware, with additional customizations applied on top.
(Profiles can also have "repos" which are the last object type. Images
do not have repos).
>>>> 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.
For traditional paravirt, the kernel and initrd are in the disk image,
pygrub just rips them out, but they are transported
with the image. So I don't see why this needs to be tracked, you can say
"uses pygrub", but you don't need the kernel+initrd
outside the image because pygrub takes care of that, right?
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?
Ok, it's n my list after I get some patches merged and finish
implementing a few rounds of XMLRPC tests to help out the Spacewalk effort.
That API addition sounds fine to me.
-- bk
[1] http://github.com/bkearney/koan/tree/devel
_______________________________________________
cobbler mailing list
cobbler(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler
5666
days inactive
5678
days old
cobbler@lists.fedorahosted.org
15 comments
2 participants
participants (2)
-
Bryan Kearney -
Michael DeHaan