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.
> 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?
> 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.
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'.
> 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
Regards,
Jim
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list