[libvirt] xl and libvirt.

[Alvin Starr]

On 05/28/2014 02:04 AM, Jim Fehlig wrote:
> Alvin Starr wrote:
>
> Adding to Eric's comments...
>
>> 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.
> Just to clarify terminology, libxl is the new interface for managing a
> xen host.  xl (not lx) is one client of this interface.  The libvirt
> libxl driver is another.
Some times I am a bit dyslexic and xl becomes lx.
I guess I could have phrased that better but the short and long was that 
I was forced to use lx because virsh/libvirt did not have enough control 
over the domains to do what I needed.

>
>> 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.
> Right.  They are different libxl clients, and one could argue this is a
> way to determine that.
>
>> This means that libvirt domains cannot be manged with xl or xl domains
>> managed by libvirt.
> Which is correct behavior, right?  I.e., one libxl client should not be
> able to manipulate the domains of another?

I can be convinced I am wrong but my take on this would be that the 
domains are not owned by the tool used to create them but are owned by 
the underlying technology(ie. xen).
 From this perspective all tools should be able to manipulate to some 
level any xen domain.
So either xl needs to be able to read and parse libvirt-xml userdata or 
libvirt needs to be able  to read xl userdata.

By analogy I would use libc/linux as an example.
Nobody would try to argue that programs created in one programing 
language should be excluded from interacting with programs created in 
another programming language.
Just think how life would be if perl programs could not invoke C 
programs or python programs.

Ok. Now that I have flogged that one to death...

>> 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.
> Ideally, the libvirt libxl driver should support all the configuration
> options supported by xl, allowing it to be used in place of xl.
I agree here completely.
>
> WRT importing an xl domain to libvirt, I think Eric's suggestion to use
> domxml-{to,from}-native is the way to go.  The libxl driver would need
> to learn 'xen-xl' (slightly different than xen-xm) and 'xen-json'
> formats so one could e.g. do
>
> virsh domxml-from-native xen-xl /path/to/dom-cfg.xl > dom-cfg.xml
> virsh define dom-cfg.xml
>
> or
>
> xl list --long dom > dom-json.cfg
> virsh domxml-from-native xen-json dom-json.cfg > dom-cfg.xml
> virsh define dom-cfg.xml
>
> I suppose another option would be to support the equivalent of 'virsh
> qemu-attach'.
The metadata is stored in files like

userdata-d.28.da587c68-da14-11e3-b2d6-37945c264b9d.libvirt-xml
or
userdata-d.2.62d064fb-3eb4-5b46-3298-47dcb1b6c13f.xl

where the suffix is the persistant data format.
It would be possible to  use domxml-to/from-native to convert one to the 
other but my quick try just now kicked out a virsh internal error.

So domxml conversion needs to be fixed.

I guess the question would be.
Should there be a new xen-lx format  or is extending xen-xm enough?
If there is to be a new xen-lx format should it be built into the new 
libxl code or just added to the xen code?

Since the xend/xm interface is being replaced with libxl/xl will the xen 
driver go away?


>> To achieve my original goal of managing a nested HVM environment from
>> libvirt I need to get the CPUID flags working but I do believe that it
>> would be nice to have the various xen and libvirt tools being able to
>> talk to each other.
> It should be possible to support specifying CPUID flags if that is
> exposed through the libxl interface.  I think it is just a matter of
> mapping libvirt's CPU model options to Xen's CPUID flags
>
> http://libvirt.org/formatdomain.html#elementsCPU
It looks to be doable.

>
> Regards,
> Jim
>


-- 
Alvin Starr                   ||   voice: (905)513-7688
Netvel Inc.                   ||   Cell:  (416)806-0133
alvin at netvel.net              ||