Re: [libvirt] xl and libvirt.
On 05/27/2014 03:44 PM, Eric Blake wrote:
On 05/26/2014 08:18 PM, Alvin Starr wrote:
> I have been trying do some simulations of an openstack environment on my
> workstation that is running xen and libvirt.
> I managed to create nested HVM environments under lx but found a number
> of shortfalls in libxl code.
>
I'm not a libxl user myself, but can at least answer some things:
> I have added a nestedhvm as a domain feature and was looking at
> inspecting the domain configuration when I realized that the persistant
> data is keept in config files in /var/lib/xen/userdata.....
>
> Libvirt and lx have incompatible file names and are using different
> config formats.
> Libvirt keeps the data as XML and xl keeps them as xm config files.
>
> This means that libvirt domains cannot be manged with xl or xl domains
> managed by libvirt.
> Part of me thinks that sticking with the XL file format would be nice
> from the point of view of being able to use xenlight tools once the
> domain is configured.
> At the very least it may make sense to keep an XL copy of the config
> file in a format that xenlight can use.
Libvirt is a higher layer than xl. The design decision is that if you
use libvirt to manage domains, you should use libvirt syntax (and not xl
syntax), because it makes it easier to translate between libxl or qemu
as your hypervisor all while being used to the common libvirt framework
(in fact, the reason libvirt exists at all is because of xen vs. qemu
issues 7 years ago needing a common wrapper). So libxl should NOT learn
libvirt XML config; but rather, libvirt should have a translation both
into and out of lower-layer config formats.
What has driven me to this point is
that libvirt does not have enough
control over a xen domain to let me run nested domains.
So I started doing stuff with libxl and the xl command.
I can understand livirt not being able to work with xl created domains
since xl is a lower level tool set but I would expect that xl should be
able to work with libvirt created domains and that cannot happen now.
I have added a few patches already to get some features enabled but I
will need to do some serious surgery to get things like CPUID enabled.
I was thinking of domxml-to/from-native and just using that code but it
exists as part of the old xm toolchain.
So I can use it more or less as it is or hack it into the xl toolchain.
I believe that the xm config format is a subset of the xl config format
but I am not really sure.
For my simple cases they do seem to be interchangeable.
I am happy to supply patches back to the community but I would like to
make sure that before I commit some real hackery that I am moving in the
right direction.
That being said what should I use for my software base to generate
patches against.
Right now I am working against the F20 SRPMs but I know that is wrong
for providing usable patches.
Such a command already exists, in the form of 'virsh domxml-from-native'
and 'domxml-to-native'; and according to the source code, the libvirt
driver for libxl domains has already supported conversions for the
"xen-xm" and "xen-sxpr" formats since libvirt 0.9.0. If the xl
config
format you are talking about is different than xen-xm or xen-sxpr, then
it's merely a matter of patching
src/libxl/libxl_driver:libxlConnectDomainXML{To,From}Native to
understand a third format. Patches welcome :)
--
Alvin Starr || voice: (905)513-7688
Netvel Inc. || Cell: (416)806-0133
alvin(a)netvel.net ||