[meta-virtualization] meta-virtualization structure

[Bruce Ashfield]

On Thu, Dec 6, 2012 at 4:44 AM, David Nyström <david.nystrom at 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 at 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 at 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 at 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"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-virtualization/attachments/20121206/6ce3710d/attachment.html>