xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Jim Fehlig <jfehlig@suse.com>
To: George Dunlap <dunlapg@umich.edu>
Cc: Fabio Fantoni <fabio.fantoni@m2r.biz>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Lars Kurth <lars.kurth@xen.org>
Subject: Re: [Hackathon] libvirt session notes
Date: Thu, 05 Jun 2014 11:41:28 -0600	[thread overview]
Message-ID: <5390ABC8.7080700@suse.com> (raw)
In-Reply-To: <CAFLBxZabDXTh7QtK63xw8hJReRqVZg9GTVrD35Va44P-HgHbxQ@mail.gmail.com>

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

http://libvirt.org/git/?p=libvirt.git;a=commit;h=9b8d6e1eefba6b09cde515cb4ef588ac0951b2f7

>>>   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 :-).

Regards,
Jim

  reply	other threads:[~2014-06-05 17:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-03  9:41 [Hackathon] libvirt session notes Lars Kurth
2014-06-03 10:41 ` Fabio Fantoni
2014-06-03 12:08   ` George Dunlap
2014-06-05 17:41     ` Jim Fehlig [this message]
     [not found] <379133F4-ABF0-4D35-B90F-AE53D8CD1CAA@recoil.org>
2014-06-02 14:19 ` George Dunlap

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5390ABC8.7080700@suse.com \
    --to=jfehlig@suse.com \
    --cc=dunlapg@umich.edu \
    --cc=fabio.fantoni@m2r.biz \
    --cc=lars.kurth@xen.org \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).