[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

George Dunlap wrote:
> On Tue, Jun 3, 2014 at 11:41 AM, Fabio Fantoni <fabio.fantoni@xxxxxxx> wrote:
>> 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.

I just committed patches yesterday that introduce basic migration support


>>>   DaveS notes that networking also had problems since
>>> default networking type isn't supported.

I assume this means <interface type='network'>?  I'm working on patches
for that now.

>>>   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?
> libxl supports spice, and the libvirt driver for KVM knows how to
> enable spice, but I don't think the libvirt driver for libxl knows how
> to enable it in libxl yet.

Correct.  The libvirt qemu driver supports spice but the libxl one
doesn't.  Patches kindly welcomed :-).


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.