[libvirt] xl and libvirt.

[Alvin Starr]

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 at netvel.net              ||