[Hackathon] libvirt session notes

[George Dunlap <george.dunlap@eu.citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 4890 bytes --]

Thanks to Anil for taking these.
  -George

-------- Original Message --------
Subject: 	libvirt session notes
Date: 	Thu, 29 May 2014 11:33:29 +0100
From: 	Anil Madhavapeddy <anil@recoil.org>
To: 	George Dunlap <George.Dunlap@eu.citrix.com>, Ian Jackson 
<Ian.Jackson@eu.citrix.com>, Dario Faggioli <dario.faggioli@citrix.com>, 
David Scott <Dave.Scott@eu.citrix.com>, John Garbutt 
<John.Garbutt@rackspace.co.uk>, Lars Kurth <lars.kurth@xen.org>



Could someone post this on the Xen wiki? libvirt session notes.

attendees:
daniel berrange (redhat)
george dunlap (citrix)
ian jackson (citrix)
dario (citrix)
dave scott (citrix)
xen orchestra folks
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.




[-- Attachment #1.2: Type: text/html, Size: 6473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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