Re: [Xen-devel] [Hackathon] libvirt session notes

[Fabio Fantoni <fabio.fantoni@xxxxxxx>]

Il 03/06/2014 11:41, Lars Kurth ha scritto:
> 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. 
I use spice on xen since the end of 2011.
What is your problem with spice on xen exactly? Lack of domUs pv 
support? Is it some spice option supported in libvirt (with kvm) but not 
supported in libxl yet?
Thanks for any reply.

> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel