Thanks for looping me in here David. The initial goal for the meta-xen
layer was in fact to encompass Xen Cloud Platform. As such, the intent
was to contain both hypervisor and user-space applications. Indeed, the
xen distribution itself includes xm/libxl; hypervisor abstraction would
be somewhat tedious in my opinion.
The layer just received commits for expanding the libvirt build to
support qemu. The commonalities and shared packaged between xen, qemu,
and kvm implementations are such that I would also agree that meta-xen
should be expanded/renamed to encompass all virtualization types; I also
support the move to meta-virtualization.
As far as a meta-cloud layer is concerned, I'm not sure I am
knowledgeable enough in this area to weigh in. I'm currently
researching a filesystem implementation for OpenStack and have stumbled
across Ceph/RBD and Gluster modules that look promising. On top of this,
XCP is documented to include support for VastSky and can be integrated
with DRBD. And, the storage and hypervisor are only two pieces of the
puzzle for a cloud implementation!
I think I would encourage you to also include OpenStack in a
meta-virtualization layer until it has matured to the point where
abstraction is more warranted. Since you've already created a presence
at github, would it be possible to rename your layer to
meta-virtualization and absorb the entire meta-xen layer? I can push
any changes for Xen/XCP here, it sounds like it is a central place for
libvirt and could also contain Bruce's kernel modifications.
Alternatively, I can create a meta-virtualization project. In any case,
those on the To and CC list should receive access to this layer as a
starting point.
Just my two cents. :)
Ray
On 11/29/2012 01:41 AM, David Nyström wrote:
Adding Ray Danks to CC.
Ray, how do you want to go forward with the meta-xen layer ?
From my perspective, having the actual hypervisor technology abstracted
from the userspace virtualization stuff is preferable. So a user could
pick-and-place hypervisor layer/s depending on needs. (And good for
use-case benchmarks as well).
libvirt package and others are smart enough to autodetect underlying
hypervisor tech capabilities, and should work out-of-the-box from that
aspect.
As to where all this will finally end up, anything goes as far as I'm
concerned. I'll continue working in meta-cloud for now, until
consensus is reached on the final whereabouts for the virtualization
specific recipes.
If anyone want to join me on github, send me an email.
Best Regards,
David
On 11/28/2012 06:25 PM, Bruce Ashfield wrote:
On Wed, Nov 28, 2012 at 11:22 AM, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
On Wed, 2012-11-28 at 17:10 +0100, David Nyström wrote:
Hello everyone,
I'm working on getting a minimal Yocto/oe-core based OpenStack setup
running with the meta-cloud layer, with bits and pieces "borrowed"
from
the meta-xen layer.
Great news!
It might be worth growing meta-xen into a meta-virtualisation layer
since kvm, openstack and xen all seem to be sharing a lot of pieces.
This depends on the maintainers but it would seem to be logical rather
than many small interdependent layers.
FWIW. I'd like to see this as well, and can contribute/help where
possible.
I
was considering a meta-ovs (Open Virtualization Solutions), but if
there are
already plans afoot for a meta-virtualization, then anything I did
could be
pushed down keeping any other layers small.
In particular I'm keen to drive some common kernel configuration, and
work
on consolidating kernel features in trees versus having a whole set
of out
of
tree modules with better tie in's to userspace enabling features
dynamically.
So I'll keep an eye out for things as well and help where possible.
Cheers,
Bruce
Still in its infancy, and lots of stuff is still missing and/or not
working properly.
Have a look if your interested, not much to see yet though.
https://github.com/nysan/meta-cloud.git
Any thoughts on floating layer ML:s, i.e. an ML for so called
"out-of-tree" layers ? Or is the common thought that all new recipes
should eventually go into oe-core ?
The Yocto Project has been using the Yocto list for that and
OpenEmbedded has openembedded-devel. Its not expected for everything to
end up in OE-Core, quite the opposite.
Cheers,
Richard
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
