[Xen-devel] [Hackathon] libvirt session notes

[Lars Kurth <lars.kurth@xxxxxxx>]

Thank you to Anil for taking notes.
Lars

== Attendees ==
daniel berrange (redhat)
george dunlap (citrix)
ian jackson (citrix)
dario (citrix)
dave scott (citrix)
olivier lambert (Vates)
julien fontanet  (Vates)
dan keningsberg (ovirt lead)
john garbutt (rackspace)
?? (rackspace)

== what is it overview? ==

JonL describes the xapi project and how it fits together with the toolstacks.  
xend being deprecated for xen 4.5 (planned), and replaced by libxl.  libxl is a 
C interface that's designed to be backwards compatible. libxl in xen 4.4 has 
forward API compatibility, but not backwards (but this is not as important).

Some features such as cancellation are discussed.  libxl has no support for 
task cancellation. Daniel says that libvirt has some support for job 
cancellation, but not all operations (only the ones designated as asynchronous 
ones).

Live migration: multiple apis in libvirt for migration, none are supported xl. 
Dario suggests that we'll have some migration soon in libxl.  libvirt doesnt 
require that all hypervisor drivers support the same features, but enumerates 
things like device models.

GeorgeD points that out that implementation details from one hypervisor can 
leak through (e.g. USB models).  DanielB notes that much of the Xen basics are 
already in libvirt due to the xend support.

libvirt's approach is to be quite explicit when talking to underlying layers, 
to ensure that it doesn't depend on defaults change downstream in the future.  
Discussion of machine types in libvirt and how this interacts with various 
drivers.   Some hypervisor-specific features like qemu monitor support are put 
into a separate libvirt-qemu library, that can be deprecated more easily than 
if they were integrated directly.

How do these tools all interact if you use them at the same time?  Overall, 
libxl is stateless and so tries to deal with other things working on the host.

IanJ asks about consoles.  There's a notification mechanism in libvirt that can 
be wired up for this, and libvirt has a more extensible design to make it 
easier to hook this stuff in.

Who is using libvirt?  There are now automated libvirt tests as part of osstest 
(IanJ/GeorgeD/IanC).  So new versions of libvirt are tested to see if they 
break Xen, and vice versa.  Does not include live migration yet.

Is there a libxl to libvirt xml -- feed it an xm config file and some fixing 
up.  Not fully ported to xl yet, but all agree this would be useful to have on 
the wiki.  IanJ suggests it'll be useful to take the libxl config parser and 
expose the struct directly.

== What's not supported in libvirt?  ==

Migration is known.  DaveS notes that networking also had problems since 
default networking type isn't supported.  There's a list of APIs support and 
which work under Xen. virt-manager is a good one to test, but it exposes too 
many options (e.g. Spice on qemu) which wont work on Xen.  It needs the ability 
to query the driver capabilities and make the GUI sensible.

Error handling is variable -- some come from the underlying driver, some use 
the structured reporting mechanism. libvirt doesnt have enough structure 
available though, and Dan notes that it's difficult to figure out where errors 
are coming from.  General agreement that the reporting isn't satisfactory at 
the moment and needs to be improved.

JohnG asks what the plan to fix it is:

Who is responsible for packaging end-to-end?  Fedora generally has the best 
support (Dario uses it).  CentOS needs work (George to lead discussion 
tomorrow).

Dario points out manpower working on libxl driver is a problem.  The matrix on 
the libvirt is useful, but its hard to map it to concrete patches. IanJ 
suggests improving the capability support in libvirt so you dont have to 
attempt an API call before you know it'll work or not.   Daniel says that host 
capability can do some of that, but it's not complete.  A side project to 
libvirt is libosinfo, which attempts to query the host and build a database of 
information like list of guest OS, hypervisors, and which works on what.

guest agents: outside the scope of libvirt.  One useful guest agent is the 
Spice qemu support in libvirt.

JohnG: what's the adoption level on the libosinfo?  Daniel: it's used in an 
application called Gnome boxes (the gnome virt box) and also into virt-manager, 
and the long term goal is to integrate into OpenStack. We would like to walk up 
to an OpenStack cloud and have it match the guest OS and hypervisor.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel