All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.