meta-virtualization structure

meta-virtualization structure

[Prica, Mihai]

[-- Attachment #1: Type: text/plain, Size: 516 bytes --]

Hi,

I wanted to include my work with meta-kvm into the new layer(meta-virtualization) and I was thinking about the best method of doing this.  The problem is there are different kernel configs depending on the hypervisor and different values for the PACKAGECONFIG in libvirt.

One solution would be to move all the common pieces into a meta layer and group the hypervisor configurations into a specific directory (meta-kvm, meta-xen), all of them in meta-virtualization. Is there another way ?
Thanks,
Mihai

[-- Attachment #2: Type: text/html, Size: 2362 bytes --]

Re: meta-virtualization structure

[Raymond Danks]

[-- Attachment #1: Type: text/plain, Size: 979 bytes --]

On 12/05/2012 05:02 AM, Prica, Mihai wrote:
>
> Hi,
>
> I wanted to include my work with meta-kvm into the new 
> layer(meta-virtualization) and I was thinking about the best method of 
> doing this.  The problem is there are different kernel configs 
> depending on the hypervisor and different values for the PACKAGECONFIG 
> in libvirt.
>
> One solution would be to move all the common pieces into a meta layer 
> and group the hypervisor configurations into a specific directory 
> (meta-kvm, meta-xen), all of them in meta-virtualization. Is there 
> another way ?
>

It seems to me the choice of hypervisor should be made in the distro 
configuration.  Can't this be handled with the addition of a HYPERVISOR 
definition there?

> Thanks,
>
> Mihai
>
>
>
> _______________________________________________
> meta-virtualization mailing list
> meta-virtualization@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-virtualization


[-- Attachment #2: Type: text/html, Size: 3555 bytes --]

Re: meta-virtualization structure

[David Nyström]

On 12/05/2012 07:57 PM, Raymond Danks wrote:
> On 12/05/2012 05:02 AM, Prica, Mihai wrote:
>>
>> Hi,
>>
>> I wanted to include my work with meta-kvm into the new
>> layer(meta-virtualization) and I was thinking about the best method of
>> doing this.  The problem is there are different kernel configs
>> depending on the hypervisor and different values for the PACKAGECONFIG
>> in libvirt.
>>
>> One solution would be to move all the common pieces into a meta layer
>> and group the hypervisor configurations into a specific directory
>> (meta-kvm, meta-xen), all of them in meta-virtualization. Is there
>> another way ?
>>
>
> It seems to me the choice of hypervisor should be made in the distro
> configuration.  Can't this be handled with the addition of a HYPERVISOR
> definition there?

For kernel Kconfig I think this will be a good idea for config options 
which  cannot be set to =m, and are mutually exclusive.

Different values for PACKAGECONF in libvirt for xen/kvm is not 
neccesarily needed, unless your focus is to optimize binary package 
sizes. libvirt drivers for xen/kvm should not be mutually exclusive 
during build/packaging/runtime afaik.
Trying to use a hypervisor driver in runtime where the underlying tech. 
is not available will result in libvirt runtime errors.

Adding specific binary size optimizations flavours, such as xen-minimal 
et.c. of course also be done from DISTRO or local.conf.

>
>> Thanks,
>>
>> Mihai
>>
>>
>>
>> _______________________________________________
>> meta-virtualization mailing list
>> meta-virtualization@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/meta-virtualization
>
>
>
>
> _______________________________________________
> meta-virtualization mailing list
> meta-virtualization@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-virtualization
>

Re: meta-virtualization structure

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 3857 bytes --]

On Thu, Dec 6, 2012 at 4:44 AM, David Nyström <david.nystrom@enea.com>wrote:

>
>
> On 12/05/2012 07:57 PM, Raymond Danks wrote:
>
>> On 12/05/2012 05:02 AM, Prica, Mihai wrote:
>>
>>>
>>> Hi,
>>>
>>> I wanted to include my work with meta-kvm into the new
>>> layer(meta-virtualization) and I was thinking about the best method of
>>> doing this.  The problem is there are different kernel configs
>>> depending on the hypervisor and different values for the PACKAGECONFIG
>>> in libvirt.
>>>
>>> One solution would be to move all the common pieces into a meta layer
>>> and group the hypervisor configurations into a specific directory
>>> (meta-kvm, meta-xen), all of them in meta-virtualization. Is there
>>> another way ?
>>>
>>>
>> It seems to me the choice of hypervisor should be made in the distro
>> configuration.  Can't this be handled with the addition of a HYPERVISOR
>> definition there?
>>
>
> For kernel Kconfig I think this will be a good idea for config options
> which  cannot be set to =m, and are mutually exclusive.
>
>
If we want to stay consistent with the model that we are trying to develop
with
other Yocto and BSP layers it would be nice to come up with some focussed
configuration fragments. These would be available for for re-use and
something
that we can trigger to created tuned kernels for one hypervisor + features
or another.

It's always tempting to create configurations that include lots of items
"just
in case", but for many of the embedded use cases, starting with something
that
is stripped down and building up is what we promote as well, since I know
for
a fact that there are some really tight kernel and disk
space constraints that
will use this configuration.

It also allows the guest and the host to be built from the same base,
varying on
the configs that are required.

I went a bit off topic there, but I can have a look at this once more
changes are
in the tree and come up with some proposals.


> Different values for PACKAGECONF in libvirt for xen/kvm is not neccesarily
> needed, unless your focus is to optimize binary package sizes. libvirt
> drivers for xen/kvm should not be mutually exclusive during
> build/packaging/runtime afaik.
> Trying to use a hypervisor driver in runtime where the underlying tech. is
> not available will result in libvirt runtime errors.
>

I agree with this in many cases, that configuring libvirt to control many
different
backends simulataneously is a good idea and something that I personally use
in my projects.



> Adding specific binary size optimizations flavours, such as xen-minimal
> et.c. of course also be done from DISTRO or local.conf.
>
>
And this make sense to me.

Cheers,

Bruce


>
>
>>  Thanks,
>>>
>>> Mihai
>>>
>>>
>>>
>>> ______________________________**_________________
>>> meta-virtualization mailing list
>>> meta-virtualization@**yoctoproject.org<meta-virtualization@yoctoproject.org>
>>> https://lists.yoctoproject.**org/listinfo/meta-**virtualization<https://lists.yoctoproject.org/listinfo/meta-virtualization>
>>>
>>
>>
>>
>>
>> ______________________________**_________________
>> meta-virtualization mailing list
>> meta-virtualization@**yoctoproject.org<meta-virtualization@yoctoproject.org>
>> https://lists.yoctoproject.**org/listinfo/meta-**virtualization<https://lists.yoctoproject.org/listinfo/meta-virtualization>
>>
>>  ______________________________**_________________
> meta-virtualization mailing list
> meta-virtualization@**yoctoproject.org<meta-virtualization@yoctoproject.org>
> https://lists.yoctoproject.**org/listinfo/meta-**virtualization<https://lists.yoctoproject.org/listinfo/meta-virtualization>
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"

[-- Attachment #2: Type: text/html, Size: 5691 bytes --]