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
next prev parent 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).