11:06 a.m.
On 03/23/2010 10:57 AM, Paul Brook wrote:
>> I think there is a serious divergence of approach there,
instanciating
>> API stating 'we are gonna deprecate them sooner or later' tell the
>> application developper 'my time is more important than yours' and not
>> really something I like to carry to the API users.
>> The main goal of libvirt remains to provide APIs needed to unify the
>> development of the virtualization layers. Having APIs which makes
>> sense only for one or 2 virtualization engines is not a problem in
>> itself, it just raises questions about the actual semantic of that API.
>> If that semantic is sound, then I see no reason to not add it, really
>> and we actually often do.
>>
> Yeah, but the problem we're facing is, I want there to be an API added
> to the management layer as part of the feature commit in qemu. If there
> has to be a discussion and decisions about how to model the API, it's
> not going to be successful.
>
I thought the monitor protocol *was* our API. If not, why not?
It is. But our API is missing key components like guest enumeration.
So the fundamental topic here is, do we introduce these missing
components to allow people to build directly to our interface or do we
make use of the functionality that libvirt already provides if they can
plumb our API directly to users.
Regards,
Anthony Liguori
Paul
1 p.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 03/23/2010 06:06 PM, Anthony Liguori wrote:
> I thought the monitor protocol *was* our API. If not, why not?
It is. But our API is missing key components like guest enumeration.
So the fundamental topic here is, do we introduce these missing
components to allow people to build directly to our interface or do we
make use of the functionality that libvirt already provides if they
can plumb our API directly to users.
Guest enumeration is another API.
Over the kvm call I suggested a qemu concentrator that would keep track
of all running qemus, and would hand out monitor connections to users.
It can do the enumeration (likely using qmp). Libvirt could talk to
that, like it does with other hypervisors.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
1:23 p.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On Tue, Mar 23, 2010 at 08:00:21PM +0200, Avi Kivity wrote:
On 03/23/2010 06:06 PM, Anthony Liguori wrote:
>>I thought the monitor protocol *was* our API. If not, why not?
>
>It is. But our API is missing key components like guest enumeration.
>So the fundamental topic here is, do we introduce these missing
>components to allow people to build directly to our interface or do we
>make use of the functionality that libvirt already provides if they
>can plumb our API directly to users.
>
Guest enumeration is another API.
Over the kvm call I suggested a qemu concentrator that would keep track
of all running qemus, and would hand out monitor connections to users.
It can do the enumeration (likely using qmp). Libvirt could talk to
that, like it does with other hypervisors.
The libvirt QEMU driver started out as a fairly simple "concentrator" not
doing much beyond spawning QEMU with argv & issuing monitor commands. The
host concentrator inevitably needs to be involved in the OS level integration
with features such as cgroups, selinux/apparmounr, host NIC management,
storage, iptables, etc. If you look at the daemons for Xen, VirtualBox,
VMWare, that other libvirt drivers talk to, they all do faaaaar more than
just enumeration of VMs. A QEMU concentrator may start out simple, but it will
end up growing over time to re-implememt much, if not all, the stuff that
libvirt already provides for QEMU in terms of host level APIs. If the core
problem here is to provide app developers access to the full range of QEMU
functionality, the re-implementing the entire of the libvirt QEMU driver is
rather over the top way to achieve that.
Regards,
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
8:05 p.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 03/23/2010 01:23 PM, Daniel P. Berrange wrote:
On Tue, Mar 23, 2010 at 08:00:21PM +0200, Avi Kivity wrote:
> On 03/23/2010 06:06 PM, Anthony Liguori wrote:
>
>>> I thought the monitor protocol *was* our API. If not, why not?
>>>
>> It is. But our API is missing key components like guest enumeration.
>> So the fundamental topic here is, do we introduce these missing
>> components to allow people to build directly to our interface or do we
>> make use of the functionality that libvirt already provides if they
>> can plumb our API directly to users.
>>
>>
> Guest enumeration is another API.
>
> Over the kvm call I suggested a qemu concentrator that would keep track
> of all running qemus, and would hand out monitor connections to users.
> It can do the enumeration (likely using qmp). Libvirt could talk to
> that, like it does with other hypervisors.
>
The libvirt QEMU driver started out as a fairly simple "concentrator" not
doing much beyond spawning QEMU with argv& issuing monitor commands. The
host concentrator inevitably needs to be involved in the OS level integration
with features such as cgroups, selinux/apparmounr, host NIC management,
storage, iptables, etc. If you look at the daemons for Xen, VirtualBox,
VMWare, that other libvirt drivers talk to, they all do faaaaar more than
just enumeration of VMs.
But with Xen, VirtualBox, and VMware, if you create a VM through the
native interfaces, you'll see that virtual machine with libvirt.
virt-top will show meaningful results for those VMs and almost all of
libvirt's functionality will work as expected.
Likewise, if you create a virtual machine with libvirt, when you do an
xm list, run the VirtualBox GUI, or use VirtualCenter, you see that
guest and you can interact with it through those interfaces.
What that means is that if you write a libvirt application and need to
use a feature that libvirt doesn't support for xen, you can also fall
back to the Xend API.
That's currently missing with qemu.
A QEMU concentrator may start out simple, but it will
end up growing over time to re-implememt much, if not all, the stuff that
libvirt already provides for QEMU in terms of host level APIs. If the core
problem here is to provide app developers access to the full range of QEMU
functionality, the re-implementing the entire of the libvirt QEMU driver is
rather over the top way to achieve that.
The goal is not to replicate libvirt but to let a more complete, qemu
specific API co-exist with libvirt just as is implemented for almost all
of the other hypervisors libvirt supports.
Regards,
Anthony Liguori
Regards,
Daniel
11:48 p.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 03/23/2010 08:23 PM, Daniel P. Berrange wrote:
On Tue, Mar 23, 2010 at 08:00:21PM +0200, Avi Kivity wrote:
> On 03/23/2010 06:06 PM, Anthony Liguori wrote:
>
>>> I thought the monitor protocol *was* our API. If not, why not?
>>>
>> It is. But our API is missing key components like guest enumeration.
>> So the fundamental topic here is, do we introduce these missing
>> components to allow people to build directly to our interface or do we
>> make use of the functionality that libvirt already provides if they
>> can plumb our API directly to users.
>>
>>
> Guest enumeration is another API.
>
> Over the kvm call I suggested a qemu concentrator that would keep track
> of all running qemus, and would hand out monitor connections to users.
> It can do the enumeration (likely using qmp). Libvirt could talk to
> that, like it does with other hypervisors.
>
The libvirt QEMU driver started out as a fairly simple "concentrator" not
doing much beyond spawning QEMU with argv& issuing monitor commands. The
host concentrator inevitably needs to be involved in the OS level integration
with features such as cgroups, selinux/apparmounr, host NIC management,
storage, iptables, etc. If you look at the daemons for Xen, VirtualBox,
VMWare, that other libvirt drivers talk to, they all do faaaaar more than
just enumeration of VMs. A QEMU concentrator may start out simple, but it will
end up growing over time to re-implememt much, if not all, the stuff that
libvirt already provides for QEMU in terms of host level APIs.
The idea is not to replace libvirt, but provide something that sits
underneath. It wouldn't do any non-qemu host-level APIs.
If the core
problem here is to provide app developers access to the full range of QEMU
functionality, the re-implementing the entire of the libvirt QEMU driver is
rather over the top way to achieve that.
It's trivial to expose all qemu functionality by exposing a qmp connection.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
2:28 p.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 03/23/2010 01:00 PM, Avi Kivity wrote:
On 03/23/2010 06:06 PM, Anthony Liguori wrote:
>> I thought the monitor protocol *was* our API. If not, why not?
>
> It is. But our API is missing key components like guest
> enumeration. So the fundamental topic here is, do we introduce these
> missing components to allow people to build directly to our interface
> or do we make use of the functionality that libvirt already provides
> if they can plumb our API directly to users.
>
Guest enumeration is another API.
Over the kvm call I suggested a qemu concentrator that would keep
track of all running qemus, and would hand out monitor connections to
users. It can do the enumeration (likely using qmp). Libvirt could
talk to that, like it does with other hypervisors.
If you think about network management, it's the difference between
having a central management server that you add physical machines to,
verses having physical machines use an advertisement mechanism (like
mDNS or SLP). The later mechanism scales better and tends to be more
robust.
For instance, it's very common for VNC servers to advertise themselves
via mDNS and it's also common for VNC clients to support this. It
requires no central server to keep track of VNC instances and generally
provides much better usability.
Regards,
Anthony Liguori
6:09 p.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
Anthony Liguori wrote:
(like mDNS or SLP). The later mechanism scales better and tends to
be more robust.
(Aside: mDNS is blocked on some larger networks because it creates too
much load. On those networks, an aggregator is essential - or a
protocol which scales better (less broadcasting)).
Doesn't libvirt use mDNS already to discover multiple hosts on a
network, for remote access?
If so, why can't exactly the same protocol be used to enumerate
multiple VMs on each host?
If not, why not?
-- Jamie
12:17 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 03/23/2010 08:00 PM, Avi Kivity wrote:
On 03/23/2010 06:06 PM, Anthony Liguori wrote:
>> I thought the monitor protocol *was* our API. If not, why not?
>
> It is. But our API is missing key components like guest
> enumeration. So the fundamental topic here is, do we introduce these
> missing components to allow people to build directly to our interface
> or do we make use of the functionality that libvirt already provides
> if they can plumb our API directly to users.
>
Guest enumeration is another API.
Over the kvm call I suggested a qemu concentrator that would keep
track of all running qemus, and would hand out monitor connections to
users. It can do the enumeration (likely using qmp). Libvirt could
talk to that, like it does with other hypervisors.
To elaborate
qemud
- daemonaizes itself
- listens on /var/lib/qemud/guests for incoming guest connections
- listens on /var/lib/qemud/clients for incoming client connections
- filters access according to uid (SCM_CREDENTIALS)
- can pass a new monitor to client (SCM_RIGHTS)
- supports 'list' command to query running guests
- async messages on guest startup/exit
qemu
- with -qemud option, connects to qemud (or maybe automatically?)
qemudc
- command-line client, can access qemu human monitor
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
5:36 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On Wed, Mar 24, 2010 at 07:17:26AM +0200, Avi Kivity wrote:
On 03/23/2010 08:00 PM, Avi Kivity wrote:
>On 03/23/2010 06:06 PM, Anthony Liguori wrote:
>>>I thought the monitor protocol *was* our API. If not, why not?
>>
>>It is. But our API is missing key components like guest
>>enumeration. So the fundamental topic here is, do we introduce these
>>missing components to allow people to build directly to our interface
>>or do we make use of the functionality that libvirt already provides
>>if they can plumb our API directly to users.
>>
>
>Guest enumeration is another API.
>
>Over the kvm call I suggested a qemu concentrator that would keep
>track of all running qemus, and would hand out monitor connections to
>users. It can do the enumeration (likely using qmp). Libvirt could
>talk to that, like it does with other hypervisors.
>
To elaborate
qemud
- daemonaizes itself
- listens on /var/lib/qemud/guests for incoming guest connections
- listens on /var/lib/qemud/clients for incoming client connections
- filters access according to uid (SCM_CREDENTIALS)
- can pass a new monitor to client (SCM_RIGHTS)
- supports 'list' command to query running guests
- async messages on guest startup/exit
My concern is that once you provide this, then next someone wants it to
list inactive guests too. Once you list inactive guests, then you'll
want this to start a guest. Once you start guests then you want cgroups
integration, selinux labelling & so on, until it ends up replicating all
of libvirt's QEMU functionality.
To be able to use the list functionality from libvirt, we need this daemon
to also guarentee id, name & uuid uniqueness for all VMs, both running and
inactive, with separate namespaces for the system vs per-user lists. Or
we have to ignore any instances listed by qemud that were not started by
libvirt, which rather defeats the purpose.
The filtering access part of this daemon is also not mapping well onto
libvirt's access model, because we don't soley filter based on UID in
libvirtd. We have it configurable based on UID, policykit, SASL, TLS/x509
already, and intend adding role based access control to further filter
things, integrating with the existing apparmour/selinux security models.
A qemud that filters based on UID only, gives users a side-channel to get
around libvirt's access control.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
5:42 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 03/24/2010 12:36 PM, Daniel P. Berrange wrote:
On Wed, Mar 24, 2010 at 07:17:26AM +0200, Avi Kivity wrote:
> On 03/23/2010 08:00 PM, Avi Kivity wrote:
>
>> On 03/23/2010 06:06 PM, Anthony Liguori wrote:
>>
>>>> I thought the monitor protocol *was* our API. If not, why not?
>>>>
>>> It is. But our API is missing key components like guest
>>> enumeration. So the fundamental topic here is, do we introduce these
>>> missing components to allow people to build directly to our interface
>>> or do we make use of the functionality that libvirt already provides
>>> if they can plumb our API directly to users.
>>>
>>>
>> Guest enumeration is another API.
>>
>> Over the kvm call I suggested a qemu concentrator that would keep
>> track of all running qemus, and would hand out monitor connections to
>> users. It can do the enumeration (likely using qmp). Libvirt could
>> talk to that, like it does with other hypervisors.
>>
>>
> To elaborate
>
> qemud
> - daemonaizes itself
> - listens on /var/lib/qemud/guests for incoming guest connections
> - listens on /var/lib/qemud/clients for incoming client connections
> - filters access according to uid (SCM_CREDENTIALS)
> - can pass a new monitor to client (SCM_RIGHTS)
> - supports 'list' command to query running guests
> - async messages on guest startup/exit
>
My concern is that once you provide this, then next someone wants it to
list inactive guests too.
That's impossible, since qemud doesn't manage config files or disk
images. It can't even launch guests!
Once you list inactive guests, then you'll
want this to start a guest. Once you start guests then you want cgroups
integration, selinux labelling& so on, until it ends up replicating all
of libvirt's QEMU functionality.
To be able to use the list functionality from libvirt, we need this daemon
to also guarentee id, name& uuid uniqueness for all VMs, both running and
inactive, with separate namespaces for the system vs per-user lists. Or
we have to ignore any instances listed by qemud that were not started by
libvirt, which rather defeats the purpose.
qemud won't guarantee name uniqueness or provide uuids.
The filtering access part of this daemon is also not mapping well
onto
libvirt's access model, because we don't soley filter based on UID in
libvirtd. We have it configurable based on UID, policykit, SASL, TLS/x509
already, and intend adding role based access control to further filter
things, integrating with the existing apparmour/selinux security models.
A qemud that filters based on UID only, gives users a side-channel to get
around libvirt's access control.
That's true. Any time you write a multiplexer these issues crop up.
Much better to stay in single process land where everything is already
taken care of.
So, at best qemud is a toy for people who are annoyed by libvirt.
--
error compiling committee.c: too many arguments to function
7:23 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 03/24/2010 05:42 AM, Avi Kivity wrote:
> The filtering access part of this daemon is also not mapping well onto
> libvirt's access model, because we don't soley filter based on UID in
> libvirtd. We have it configurable based on UID, policykit, SASL,
> TLS/x509
> already, and intend adding role based access control to further filter
> things, integrating with the existing apparmour/selinux security models.
> A qemud that filters based on UID only, gives users a side-channel to
> get
> around libvirt's access control.
That's true. Any time you write a multiplexer these issues crop up.
Much better to stay in single process land where everything is already
taken care of.
What does a multiplexer give you that making individual qemu instances
discoverable doesn't give you? The later doesn't suffer from these
problems.
Regards,
Anthony Liguori
So, at best qemud is a toy for people who are annoyed by libvirt.
7:29 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 03/24/2010 02:23 PM, Anthony Liguori wrote:
On 03/24/2010 05:42 AM, Avi Kivity wrote:
>
>> The filtering access part of this daemon is also not mapping well onto
>> libvirt's access model, because we don't soley filter based on UID in
>> libvirtd. We have it configurable based on UID, policykit, SASL,
>> TLS/x509
>> already, and intend adding role based access control to further filter
>> things, integrating with the existing apparmour/selinux security
>> models.
>> A qemud that filters based on UID only, gives users a side-channel
>> to get
>> around libvirt's access control.
>
> That's true. Any time you write a multiplexer these issues crop up.
> Much better to stay in single process land where everything is
> already taken care of.
What does a multiplexer give you that making individual qemu instances
discoverable doesn't give you? The later doesn't suffer from these
problems.
You don't get a directory filled with a zillion socket files pointing at
dead guests. Agree that's a poor return on investment.
Maybe we want a O_UNLINK_ON_CLOSE for unix domain sockets - but no,
that's not implementable.
--
error compiling committee.c: too many arguments to function
7:32 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 03/24/2010 07:29 AM, Avi Kivity wrote:
On 03/24/2010 02:23 PM, Anthony Liguori wrote:
> On 03/24/2010 05:42 AM, Avi Kivity wrote:
>>
>>> The filtering access part of this daemon is also not mapping well onto
>>> libvirt's access model, because we don't soley filter based on UID
in
>>> libvirtd. We have it configurable based on UID, policykit, SASL,
>>> TLS/x509
>>> already, and intend adding role based access control to further filter
>>> things, integrating with the existing apparmour/selinux security
>>> models.
>>> A qemud that filters based on UID only, gives users a side-channel
>>> to get
>>> around libvirt's access control.
>>
>> That's true. Any time you write a multiplexer these issues crop
>> up. Much better to stay in single process land where everything is
>> already taken care of.
>
> What does a multiplexer give you that making individual qemu
> instances discoverable doesn't give you? The later doesn't suffer
> from these problems.
>
You don't get a directory filled with a zillion socket files pointing
at dead guests. Agree that's a poor return on investment.
Deleting it on atexit combined with flushing the whole directory at
startup is a pretty reasonable solution to this (which is ultimately how
the entirety of /var/run behaves).
If you're really paranoid, you can fork() a helper with a shared pipe to
implement unlink on close.
Regards,
Anthony Liguori
Maybe we want a O_UNLINK_ON_CLOSE for unix domain sockets - but no,
that's not implementable.
7:33 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 03/24/2010 02:32 PM, Anthony Liguori wrote:
> You don't get a directory filled with a zillion socket files
pointing
> at dead guests. Agree that's a poor return on investment.
Deleting it on atexit combined with flushing the whole directory at
startup is a pretty reasonable solution to this (which is ultimately
how the entirety of /var/run behaves).
If you're really paranoid, you can fork() a helper with a shared pipe
to implement unlink on close.
My paranoia comes nowhere near to my dislike of forked helpers.
--
error compiling committee.c: too many arguments to function
7:28 p.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
Avi Kivity wrote:
On 03/24/2010 02:32 PM, Anthony Liguori wrote:
>>You don't get a directory filled with a zillion socket files pointing
>>at dead guests. Agree that's a poor return on investment.
>
>
>Deleting it on atexit combined with flushing the whole directory at
>startup is a pretty reasonable solution to this (which is ultimately
>how the entirety of /var/run behaves).
>
>If you're really paranoid, you can fork() a helper with a shared pipe
>to implement unlink on close.
My paranoia comes nowhere near to my dislike of forked helpers.
Use clone() then, it's cheaper ;-)
Anyway, Linux at least *does* have unlink-on-exit unix sockets: use
the abstract unix namespace.
Enumeration is a different problem from being able to connect to an
instance, and there are several approaches to enumerating multiple
running instances.
One of the most well known at the moment is mDNS service discovery,
and each instance registering with freedesktop's Avahi enumeration
service.
-- Jamie
11:42 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On Wed, 24 Mar 2010 12:42:16 +0200
Avi Kivity <avi(a)redhat.com> wrote:
So, at best qemud is a toy for people who are annoyed by libvirt.
Is the reason for doing this in qemu because libvirt is annoying? I don't see
how adding yet another layer/daemon is going to improve ours and user's life
(the same applies for libqemu).
If I got it right, there were two complaints from the kvm-devel flamewar:
1. Qemu has usability problems
2. There's no way an external tool can get /proc/kallsyms info from Qemu
I don't see how libqemu can help with 1) and having qemud doesn't seem
the best solution for 2) either.
Still talking about 2), what's wrong in getting the PID or having a QMP
connection in a well known location as suggested by Anthony?
2:49 p.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 03/24/2010 06:42 PM, Luiz Capitulino wrote:
On Wed, 24 Mar 2010 12:42:16 +0200
Avi Kivity<avi(a)redhat.com> wrote:
> So, at best qemud is a toy for people who are annoyed by libvirt.
>
Is the reason for doing this in qemu because libvirt is annoying?
Mostly.
I don't see
how adding yet another layer/daemon is going to improve ours and user's life
(the same applies for libqemu).
libvirt becomes optional.
If I got it right, there were two complaints from the kvm-devel
flamewar:
1. Qemu has usability problems
2. There's no way an external tool can get /proc/kallsyms info from Qemu
I don't see how libqemu can help with 1) and having qemud doesn't seem
the best solution for 2) either.
Still talking about 2), what's wrong in getting the PID or having a QMP
connection in a well known location as suggested by Anthony?
I now believe that's the best option.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
3:12 p.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On Wed, 24 Mar 2010 21:49:45 +0200
Avi Kivity <avi(a)redhat.com> wrote:
On 03/24/2010 06:42 PM, Luiz Capitulino wrote:
> On Wed, 24 Mar 2010 12:42:16 +0200
> Avi Kivity<avi(a)redhat.com> wrote:
>
>
>> So, at best qemud is a toy for people who are annoyed by libvirt.
>>
> Is the reason for doing this in qemu because libvirt is annoying?
Mostly.
> I don't see
> how adding yet another layer/daemon is going to improve ours and user's life
> (the same applies for libqemu).
>
libvirt becomes optional.
I think it should only be optional if all you want is to run a single VM
in this case what seems to be missing on our side is a _real_ GUI, bundled
with QEMU potentially written in a high-level language.
Then we make virt-manager optional and this is good because we can sync
features way faster and we don't have to care about _managing_ several
VMs, our world in terms of usability and maintainability is about one VM.
IMVHO, everything else should be done by third-party tools like libvirt,
we just provide the means for it.
3:32 p.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 03/24/2010 03:12 PM, Luiz Capitulino wrote:
On Wed, 24 Mar 2010 21:49:45 +0200
Avi Kivity<avi(a)redhat.com> wrote:
> On 03/24/2010 06:42 PM, Luiz Capitulino wrote:
>
>> On Wed, 24 Mar 2010 12:42:16 +0200
>> Avi Kivity<avi(a)redhat.com> wrote:
>>
>>
>>
>>> So, at best qemud is a toy for people who are annoyed by libvirt.
>>>
>>>
>> Is the reason for doing this in qemu because libvirt is annoying?
>>
> Mostly.
>
>
>> I don't see
>> how adding yet another layer/daemon is going to improve ours and user's life
>> (the same applies for libqemu).
>>
>>
> libvirt becomes optional.
>
I think it should only be optional if all you want is to run a single VM
in this case what seems to be missing on our side is a _real_ GUI, bundled
with QEMU potentially written in a high-level language.
That's a separate problem.
Then we make virt-manager optional and this is good because we can
sync
features way faster and we don't have to care about _managing_ several
VMs, our world in terms of usability and maintainability is about one VM.
IMVHO, everything else should be done by third-party tools like libvirt,
we just provide the means for it.
We need to have a common management interface for third party tools.
libvirt cannot be that today because of the fact that it doesn't support
all of our features. What we need to figure out is how we can work with
the libvirt team to fix this.
So far, a libqemu.so with a flexible transport that could be used
directly by a libvirt user (ala cairo/gdk type interactions) seems like
the best solution to me.
Regards,
Anthony Liguori
3:54 p.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 24.03.2010, at 21:32, Anthony Liguori wrote:
On 03/24/2010 03:12 PM, Luiz Capitulino wrote:
> On Wed, 24 Mar 2010 21:49:45 +0200
> Avi Kivity<avi(a)redhat.com> wrote:
>
>
>> On 03/24/2010 06:42 PM, Luiz Capitulino wrote:
>>
>>> On Wed, 24 Mar 2010 12:42:16 +0200
>>> Avi Kivity<avi(a)redhat.com> wrote:
>>>
>>>
>>>
>>>> So, at best qemud is a toy for people who are annoyed by libvirt.
>>>>
>>>>
>>> Is the reason for doing this in qemu because libvirt is annoying?
>>>
>> Mostly.
>>
>>
>>> I don't see
>>> how adding yet another layer/daemon is going to improve ours and user's
life
>>> (the same applies for libqemu).
>>>
>>>
>> libvirt becomes optional.
>>
> I think it should only be optional if all you want is to run a single VM
> in this case what seems to be missing on our side is a _real_ GUI, bundled
> with QEMU potentially written in a high-level language.
>
That's a separate problem.
> Then we make virt-manager optional and this is good because we can sync
> features way faster and we don't have to care about _managing_ several
> VMs, our world in terms of usability and maintainability is about one VM.
>
> IMVHO, everything else should be done by third-party tools like libvirt,
> we just provide the means for it.
>
We need to have a common management interface for third party tools. libvirt cannot be
that today because of the fact that it doesn't support all of our features. What we
need to figure out is how we can work with the libvirt team to fix this.
The feature problem isn't the only one. It's also about ease of use. I personally
find the qemu command line easier to use than anything libvirt-derived.
So far, a libqemu.so with a flexible transport that could be used
directly by a libvirt user (ala cairo/gdk type interactions) seems like the best solution
to me.
ACK.
One thing I was thinking is that it might be a good idea to split the qemu command line
version off as well. The qemu backend would then only speak QMP with an empty device case
and the actual "qemu" command would run that, connect to it via QMP and
instanciate everything.
That way we'd get a consistent interface for management apps while keeping an easy to
use CLI.
Alex
4:33 p.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On Wed, 24 Mar 2010 21:54:09 +0100
Alexander Graf <agraf(a)suse.de> wrote:
On 24.03.2010, at 21:32, Anthony Liguori wrote:
> On 03/24/2010 03:12 PM, Luiz Capitulino wrote:
>> On Wed, 24 Mar 2010 21:49:45 +0200
>> Avi Kivity<avi(a)redhat.com> wrote:
>>
>>
>>> On 03/24/2010 06:42 PM, Luiz Capitulino wrote:
>>>
>>>> On Wed, 24 Mar 2010 12:42:16 +0200
>>>> Avi Kivity<avi(a)redhat.com> wrote:
>>>>
>>>>
>>>>
>>>>> So, at best qemud is a toy for people who are annoyed by libvirt.
>>>>>
>>>>>
>>>> Is the reason for doing this in qemu because libvirt is annoying?
>>>>
>>> Mostly.
>>>
>>>
>>>> I don't see
>>>> how adding yet another layer/daemon is going to improve ours and
user's life
>>>> (the same applies for libqemu).
>>>>
>>>>
>>> libvirt becomes optional.
>>>
>> I think it should only be optional if all you want is to run a single VM
>> in this case what seems to be missing on our side is a _real_ GUI, bundled
>> with QEMU potentially written in a high-level language.
>>
>
> That's a separate problem.
>
>> Then we make virt-manager optional and this is good because we can sync
>> features way faster and we don't have to care about _managing_ several
>> VMs, our world in terms of usability and maintainability is about one VM.
>>
>> IMVHO, everything else should be done by third-party tools like libvirt,
>> we just provide the means for it.
>>
>
> We need to have a common management interface for third party tools. libvirt cannot
be that today because of the fact that it doesn't support all of our features. What
we need to figure out is how we can work with the libvirt team to fix this.
The feature problem isn't the only one. It's also about ease of use. I personally
find the qemu command line easier to use than anything libvirt-derived.
Because your a developer and it does make sense to have a good CLI,
on the other hand we also have use cases for a GUI bundled in QEMU
and libvirt-derived things, which know how to deal with several
VMs and integrates well with lots of other things.
2:49 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 24.03.2010, at 22:33, Luiz Capitulino wrote:
On Wed, 24 Mar 2010 21:54:09 +0100
Alexander Graf <agraf(a)suse.de> wrote:
>
> On 24.03.2010, at 21:32, Anthony Liguori wrote:
>
>> On 03/24/2010 03:12 PM, Luiz Capitulino wrote:
>>> On Wed, 24 Mar 2010 21:49:45 +0200
>>> Avi Kivity<avi(a)redhat.com> wrote:
>>>
>>>
>>>> On 03/24/2010 06:42 PM, Luiz Capitulino wrote:
>>>>
>>>>> On Wed, 24 Mar 2010 12:42:16 +0200
>>>>> Avi Kivity<avi(a)redhat.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> So, at best qemud is a toy for people who are annoyed by
libvirt.
>>>>>>
>>>>>>
>>>>> Is the reason for doing this in qemu because libvirt is annoying?
>>>>>
>>>> Mostly.
>>>>
>>>>
>>>>> I don't see
>>>>> how adding yet another layer/daemon is going to improve ours and
user's life
>>>>> (the same applies for libqemu).
>>>>>
>>>>>
>>>> libvirt becomes optional.
>>>>
>>> I think it should only be optional if all you want is to run a single VM
>>> in this case what seems to be missing on our side is a _real_ GUI, bundled
>>> with QEMU potentially written in a high-level language.
>>>
>>
>> That's a separate problem.
>>
>>> Then we make virt-manager optional and this is good because we can sync
>>> features way faster and we don't have to care about _managing_ several
>>> VMs, our world in terms of usability and maintainability is about one VM.
>>>
>>> IMVHO, everything else should be done by third-party tools like libvirt,
>>> we just provide the means for it.
>>>
>>
>> We need to have a common management interface for third party tools. libvirt
cannot be that today because of the fact that it doesn't support all of our features.
What we need to figure out is how we can work with the libvirt team to fix this.
>
> The feature problem isn't the only one. It's also about ease of use. I
personally find the qemu command line easier to use than anything libvirt-derived.
Because your a developer and it does make sense to have a good CLI,
on the other hand we also have use cases for a GUI bundled in QEMU
and libvirt-derived things, which know how to deal with several
VMs and integrates well with lots of other things.
Oh I certainly would use a GUI if it was easy to use for me.
Imagine we had a full machine description configuration, similar to a .vmx file. A GUI
would simply use that. Whenever I add a feature or want to test something out, I'd use
that .vmx file with the GUI and everything would be great.
In fact, I'd prefer that over remembering weird command line options for qemu. And you
can always just expose something like the monitor interface using the GUI.
Alex
4:25 p.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On Wed, 24 Mar 2010 15:32:42 -0500
Anthony Liguori <anthony(a)codemonkey.ws> wrote:
On 03/24/2010 03:12 PM, Luiz Capitulino wrote:
> On Wed, 24 Mar 2010 21:49:45 +0200
> Avi Kivity<avi(a)redhat.com> wrote:
>
>
>> On 03/24/2010 06:42 PM, Luiz Capitulino wrote:
>>
>>> On Wed, 24 Mar 2010 12:42:16 +0200
>>> Avi Kivity<avi(a)redhat.com> wrote:
>>>
>>>
>>>
>>>> So, at best qemud is a toy for people who are annoyed by libvirt.
>>>>
>>>>
>>> Is the reason for doing this in qemu because libvirt is annoying?
>>>
>> Mostly.
>>
>>
>>> I don't see
>>> how adding yet another layer/daemon is going to improve ours and user's
life
>>> (the same applies for libqemu).
>>>
>>>
>> libvirt becomes optional.
>>
> I think it should only be optional if all you want is to run a single VM
> in this case what seems to be missing on our side is a _real_ GUI, bundled
> with QEMU potentially written in a high-level language.
>
That's a separate problem.
I see it as a related problem, because what seems to be under discussion
is the quality of our interfaces with humans and tools.
Also, when we were discussing the usuability problems I remember that
you
*WARNING: I might be wrong here, please correct me if so*
you said that you don't push users to libvirt because it's out of sync with
our features. The point is that, even if this true and even if we solve that,
I don't think it will solve the problem of a good experience for a
'single VM user', because libvirt is more than that and people will likely
be annoyed as much as they are today.
I believe this problem is up to us to solve.
> Then we make virt-manager optional and this is good because we
can sync
> features way faster and we don't have to care about _managing_ several
> VMs, our world in terms of usability and maintainability is about one VM.
>
> IMVHO, everything else should be done by third-party tools like libvirt,
> we just provide the means for it.
>
We need to have a common management interface for third party tools.
QMP? :-)
libvirt cannot be that today because of the fact that it doesn't
support
all of our features. What we need to figure out is how we can work with
the libvirt team to fix this.
Agreed.
So far, a libqemu.so with a flexible transport that could be used
directly by a libvirt user (ala cairo/gdk type interactions) seems like
the best solution to me.
I tend to disagree.
First, I think we should invest our time and effort on the text protocol
business, which is QMP. Having yet another public interface will likely split
efforts a bit and will make clients' life harder (which one should I choose?
What if they get out of sync?). Not to mention that I think Paul has a point,
if QMP is not useful here, why do we have it in the first place (vs. a C library
from the beginning)?
You mentioned dynamic dispatch, but this is useful only for C clients right?
If so, what C clients you expected beyond libvirt? Note that libvirt has added
a new events API recently.
The second most important point for me is: why do you believe that
libqemu.so is going to improve things? Do you expect that libvirt will
sync faster? If this is the case, I think it will be as slower as it's
currently, as the problem is not the availability of interfaces, but
most likely community integration.
I like the idea of having a transient qemu-specific API in libvirt,
as suggested by someone in this thread.
4:40 p.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 03/24/2010 04:25 PM, Luiz Capitulino wrote:
I see it as a related problem, because what seems to be under discussion
is the quality of our interfaces with humans and tools.
Also, when we were discussing the usuability problems I remember that
you
*WARNING: I might be wrong here, please correct me if so*
you said that you don't push users to libvirt because it's out of sync with
our features.
Yes.
The point is that, even if this true and even if we solve that,
I don't think it will solve the problem of a good experience for a
'single VM user', because libvirt is more than that and people will likely
be annoyed as much as they are today.
I believe this problem is up to us to solve.
With my qemu hat on, I'm happy to ignore libvirt and say we need to own
our interfaces and to compete with libvirt for users.
But with my Linux virtualization hat on, I want to see a single
management interface that users can use without having to make a choice
between libvirt features or libqemu features.
>> Then we make virt-manager optional and this is good
because we can sync
>> features way faster and we don't have to care about _managing_ several
>> VMs, our world in terms of usability and maintainability is about one VM.
>>
>> IMVHO, everything else should be done by third-party tools like libvirt,
>> we just provide the means for it.
>>
>>
> We need to have a common management interface for third party tools.
>
QMP? :-)
Only if QMP is compatible with libvirt. I don't want a user to have to
choose between QMP and libvirt.
> So far, a libqemu.so with a flexible transport that could be
used
> directly by a libvirt user (ala cairo/gdk type interactions) seems like
> the best solution to me.
>
I tend to disagree.
First, I think we should invest our time and effort on the text protocol
business, which is QMP. Having yet another public interface will likely split
efforts a bit and will make clients' life harder (which one should I choose?
What if they get out of sync?). Not to mention that I think Paul has a point,
if QMP is not useful here, why do we have it in the first place (vs. a C library
from the beginning)?
You mentioned dynamic dispatch, but this is useful only for C clients right?
If so, what C clients you expected beyond libvirt?
Users want a C API. I don't agree that libvirt is the only C interface
consumer out there.
Note that libvirt has added
a new events API recently.
The second most important point for me is: why do you believe that
libqemu.so is going to improve things? Do you expect that libvirt will
sync faster?
With GDK and Cairo, when Cairo adds a new feature, GDK doesn't have to
do anything to support it. Users just get a cairo context from GDK and
use the cairo API directly.
GDK provides a higher level interface for 2d operations that is more
platform agnostic, and users can choice to use that or write directly to
the cairo API.
If this is the case, I think it will be as slower as it's
currently, as the problem is not the availability of interfaces, but
most likely community integration.
I like the idea of having a transient qemu-specific API in libvirt,
as suggested by someone in this thread.
I really think what we want is for a libvirt user to be able to call
libqemu functions directly. There shouldn't have to be libvirt specific
functions for every operation we expose.
Regards,
Anthony Liguori
3:26 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 24/03/10 21:40, Anthony Liguori wrote:
> If so, what C clients you expected beyond libvirt?
Users want a C API. I don't agree that libvirt is the only C
interface consumer out there.
(I've seen this written too many times ...)
How do you know that ? did you do a poll or something where *actual*
users vote/tell ?
From my point of view, i wouldn't want to write a high level management
toolstack in C, specially
since the API is well defined JSON which is easily available in all high
level language out there.
--
Vincent
3:49 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 03/25/2010 10:26 AM, Vincent Hanquez wrote:
On 24/03/10 21:40, Anthony Liguori wrote:
>> If so, what C clients you expected beyond libvirt?
>
> Users want a C API. I don't agree that libvirt is the only C
> interface consumer out there.
(I've seen this written too many times ...)
How do you know that ? did you do a poll or something where *actual*
users vote/tell ?
From my point of view, i wouldn't want to write a high level
management toolstack in C, specially
since the API is well defined JSON which is easily available in all
high level language out there.
Strongly agreed. Even the managementy bits of qemu (anything around
QObject) are suffering from the lowleveledness of C.
--
error compiling committee.c: too many arguments to function
7:33 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 03/25/2010 03:26 AM, Vincent Hanquez wrote:
On 24/03/10 21:40, Anthony Liguori wrote:
>> If so, what C clients you expected beyond libvirt?
>
> Users want a C API. I don't agree that libvirt is the only C
> interface consumer out there.
(I've seen this written too many times ...)
How do you know that ? did you do a poll or something where *actual*
users vote/tell ?
From my point of view, i wouldn't want to write a high level
management toolstack in C, specially
since the API is well defined JSON which is easily available in all
high level language out there.
There's a whole world of C based management toolstacks (CIM).
Regards,
Anthony Liguori
7:37 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 03/25/2010 02:33 PM, Anthony Liguori wrote:
> From my point of view, i wouldn't want to write a high level
> management toolstack in C, specially
> since the API is well defined JSON which is easily available in all
> high level language out there.
There's a whole world of C based management toolstacks (CIM).
Gratefully I know very little about CIM, but isn't it language independent?
The prominent open source implementation, pegasus, is written in C++.
Or are you referring to specific management apps written in C? If they
go through CIM, how can they talk qmp?
--
error compiling committee.c: too many arguments to function
8:44 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 03/25/2010 07:37 AM, Avi Kivity wrote:
On 03/25/2010 02:33 PM, Anthony Liguori wrote:
>> From my point of view, i wouldn't want to write a high level
>> management toolstack in C, specially
>> since the API is well defined JSON which is easily available in all
>> high level language out there.
>
>
> There's a whole world of C based management toolstacks (CIM).
>
Gratefully I know very little about CIM, but isn't it language
independent?
The prominent open source implementation, pegasus, is written in C++.
There is also SFCB which is written in C.
But an awful lot of the providers for pegasus are written in C.
The point is, C is a lowest common denominator and it's important to
support in a proper way.
Regards,
Anthony Liguori
Or are you referring to specific management apps written in C? If
they go through CIM, how can they talk qmp?
8:48 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 03/25/2010 03:44 PM, Anthony Liguori wrote:
On 03/25/2010 07:37 AM, Avi Kivity wrote:
> On 03/25/2010 02:33 PM, Anthony Liguori wrote:
>>> From my point of view, i wouldn't want to write a high level
>>> management toolstack in C, specially
>>> since the API is well defined JSON which is easily available in all
>>> high level language out there.
>>
>>
>> There's a whole world of C based management toolstacks (CIM).
>>
>
> Gratefully I know very little about CIM, but isn't it language
> independent?
>
> The prominent open source implementation, pegasus, is written in C++.
There is also SFCB which is written in C.
Ok.
But an awful lot of the providers for pegasus are written in C.
But we're concerned with only one, the virt provider. None of the
others will use libqemu?
The point is, C is a lowest common denominator and it's important
to
support in a proper way.
Problem is, it means horrible support for everyone else.
--
error compiling committee.c: too many arguments to function
8:57 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 03/25/2010 08:48 AM, Avi Kivity wrote:
>
> But an awful lot of the providers for pegasus are written in C.
But we're concerned with only one, the virt provider. None of the
others will use libqemu?
> The point is, C is a lowest common denominator and it's important to
> support in a proper way.
Problem is, it means horrible support for everyone else.
Why?
We can provide a generic QMP dispatch interface that high level
languages can use. Then they can do fancy dispatch, treat QErrors as
exceptions, etc.
We just ought to also provide some simple C wrappers for all of the
functions. Yes, the C interface is inferior to the generic interface
but that's fine.
Regards,
Anthony Liguori
9:09 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On Thu, 25 Mar 2010 08:57:36 -0500
Anthony Liguori <anthony(a)codemonkey.ws> wrote:
On 03/25/2010 08:48 AM, Avi Kivity wrote:
>>
>> But an awful lot of the providers for pegasus are written in C.
>
> But we're concerned with only one, the virt provider. None of the
> others will use libqemu?
>
>> The point is, C is a lowest common denominator and it's important to
>> support in a proper way.
>
> Problem is, it means horrible support for everyone else.
Why?
Because it's useless for non C clients. QMP is language independent,
libqemu is a full machinery for C clients only.
We can provide a generic QMP dispatch interface that high level
languages can use. Then they can do fancy dispatch, treat QErrors as
exceptions, etc.
They can do that by accessing QMP directly. Why would a Python developer
get in the mess of writing a Python binding for libqemu if they call do
the exactly same thing by using its native json module?
Man, opening a QMP connection from Python and sending commands can be
done with a few lines.
We just ought to also provide some simple C wrappers for all of the
functions. Yes, the C interface is inferior to the generic interface
but that's fine.
Why don't we start with my simple lib suggestion and wait one or two
releases to see what happens?
10:59 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 03/25/2010 09:09 AM, Luiz Capitulino wrote:
> We can provide a generic QMP dispatch interface that high level
> languages can use. Then they can do fancy dispatch, treat QErrors as
> exceptions, etc.
>
They can do that by accessing QMP directly. Why would a Python developer
get in the mess of writing a Python binding for libqemu if they call do
the exactly same thing by using its native json module?
Man, opening a QMP connection from Python and sending commands can be
done with a few lines.
Problem is, without a libqemu, libvirt cannot return a QMPContext that
can be used by python bindings. This is the problem that all high
level languages have with respect to RPC transports.
You need libqemu to deal with establishing the transport. That code
needs to be common and shared across languages.
Dispatch can be handled by the high level language.
> We just ought to also provide some simple C wrappers for all of
the
> functions. Yes, the C interface is inferior to the generic interface
> but that's fine.
>
Why don't we start with my simple lib suggestion and wait one or two
releases to see what happens?
I have no problem starting without the generated C wrappers. But we
need the core library to have the right abstractions with respect to
transports.
Regards,
Anthony Liguori
9:11 p.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
Anthony Liguori wrote:
On 03/25/2010 09:09 AM, Luiz Capitulino wrote:
>
>>We can provide a generic QMP dispatch interface that high level
>>languages can use. Then they can do fancy dispatch, treat QErrors as
>>exceptions, etc.
>>
> They can do that by accessing QMP directly. Why would a Python developer
>get in the mess of writing a Python binding for libqemu if they call do
>the exactly same thing by using its native json module?
>
> Man, opening a QMP connection from Python and sending commands can be
>done with a few lines.
>
Problem is, without a libqemu, libvirt cannot return a QMPContext that
can be used by python bindings. This is the problem that all high
level languages have with respect to RPC transports.
You need libqemu to deal with establishing the transport. That code
needs to be common and shared across languages.
We can't libvirt talk QMG with Python over a pipe or local socket?
So that the Python can talk to native qemu and via libvirt with the
same code.
That would be much easier from Python person than writing a wrapper
around the C library. Multiplied by each high-level language...
-- Jamie
9:21 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 03/25/2010 03:57 PM, Anthony Liguori wrote:
On 03/25/2010 08:48 AM, Avi Kivity wrote:
>>
>> But an awful lot of the providers for pegasus are written in C.
>
> But we're concerned with only one, the virt provider. None of the
> others will use libqemu?
>
>> The point is, C is a lowest common denominator and it's important to
>> support in a proper way.
>
> Problem is, it means horrible support for everyone else.
Why?
We can provide a generic QMP dispatch interface that high level
languages can use. Then they can do fancy dispatch, treat QErrors as
exceptions, etc.
Sure, with high level wrappers everything's fine.
--
error compiling committee.c: too many arguments to function
9:22 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On Thu, Mar 25, 2010 at 08:57:36AM -0500, Anthony Liguori wrote:
Why?
We can provide a generic QMP dispatch interface that high level
languages can use. Then they can do fancy dispatch, treat QErrors as
exceptions, etc.
Because more than likely it will be more efforts than doing the same work in
the native language, forcing certains designs [1] up to high-level-language
developers throats, and possibly less stability (segfault, memory corruption,
memory leak, ..) specially in development phase.
[1] lack of separation between IO and pure functions, file descriptor versus
stream, C memory functions instead of GC based, and probably lots of other
things easily accessible from high level language.
--
Vincent
11:50 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
Anthony Liguori <anthony(a)codemonkey.ws> writes:
On 03/25/2010 07:37 AM, Avi Kivity wrote:
> On 03/25/2010 02:33 PM, Anthony Liguori wrote:
>>> From my point of view, i wouldn't want to write a high level
>>> management toolstack in C, specially
>>> since the API is well defined JSON which is easily available in
>>> all high level language out there.
>>
>>
>> There's a whole world of C based management toolstacks (CIM).
>>
>
> Gratefully I know very little about CIM, but isn't it language
> independent?
>
> The prominent open source implementation, pegasus, is written in C++.
There is also SFCB which is written in C.
But an awful lot of the providers for pegasus are written in C.
The point is, C is a lowest common denominator and it's important to
support in a proper way.
No. The lowest truly common denominator is plain text. And we got that
covered already.
A developer encountered the problem of talking a simple text protocol.
He thought "I know, I'll create a 1:1 C API for that". Now he got two
problems.
12:40 p.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 03/25/2010 11:50 AM, Markus Armbruster wrote:
> The point is, C is a lowest common denominator and it's important to
> support in a proper way.
>
No. The lowest truly common denominator is plain text. And we got that
covered already.
A developer encountered the problem of talking a simple text protocol.
He thought "I know, I'll create a 1:1 C API for that". Now he got two
problems.
I've done a poor job communicating in this thread.
The C API's primary purpose is *not* to providing 1:1 wrapping functions
for QMP functions. That's a minor, add on feature, that I really would
like, but it not at all useful for high level languages.
The importances of libqemu is:
1) Providing a common QMP transport implementation that is extensible by
third parties
2) Providing a set of common transports that support automatic discovery
of command line launched guests
3) Providing a generic QMP dispatch function
Yes, this means you can't just create a JSON-RPC object in Python and
talk QMP that way, but that's less desirable than you think it is.
You could if you really wanted to, but you wouldn't get the benefits of
the common transports.
IOW, imagine qemu-cmd. You want it to support:
# qmp_new_by_name("Fedora")
qemu-cmd Fedora set_link on
# libqemu-ssh.so - ssh_qmp_new()
qemu-cmd ssh://anthony@lab1.ibm/Fedora set_link on
# qmp_new_by_fd()
qemu-cmd -c /path/to/domain/socket set_link on
# libvirt-qemu.so - virDomainGetQMP()
qemu-cmd -b qemu+ssh://lab1.ibm/system Fedora set_link on
This requires a high level transport.
Regards,
Anthony Liguori
2:37 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
Anthony Liguori <anthony(a)codemonkey.ws> writes:
On 03/25/2010 11:50 AM, Markus Armbruster wrote:
>
>> The point is, C is a lowest common denominator and it's important to
>> support in a proper way.
>>
> No. The lowest truly common denominator is plain text. And we got that
> covered already.
>
> A developer encountered the problem of talking a simple text protocol.
> He thought "I know, I'll create a 1:1 C API for that". Now he got two
> problems.
>
I've done a poor job communicating in this thread.
The C API's primary purpose is *not* to providing 1:1 wrapping
functions for QMP functions. That's a minor, add on feature, that I
really would like, but it not at all useful for high level languages.
The importances of libqemu is:
1) Providing a common QMP transport implementation that is extensible
by third parties
2) Providing a set of common transports that support automatic
discovery of command line launched guests
3) Providing a generic QMP dispatch function
Adding to this C wrappers for QMP commands threatens to make QMP command
arguments part of the library ABI. Compatible QMP evolution (like
adding an optional argument) turns into a libqmp soname bump.
Counter-productive. How do you plan to avoid that?
Yes, this means you can't just create a JSON-RPC object in Python
and
talk QMP that way, but that's less desirable than you think it is.
You could if you really wanted to, but you wouldn't get the benefits
of the common transports.
IOW, imagine qemu-cmd. You want it to support:
# qmp_new_by_name("Fedora")
qemu-cmd Fedora set_link on
# libqemu-ssh.so - ssh_qmp_new()
qemu-cmd ssh://anthony@lab1.ibm/Fedora set_link on
# qmp_new_by_fd()
qemu-cmd -c /path/to/domain/socket set_link on
# libvirt-qemu.so - virDomainGetQMP()
qemu-cmd -b qemu+ssh://lab1.ibm/system Fedora set_link on
This requires a high level transport.
All I'd want from such a transport is a file descriptor. No need to
drag in yet another JSON library via libqmp.
4:26 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
Adding to this C wrappers for QMP commands threatens to make QMP
command
arguments part of the library ABI. Compatible QMP evolution (like
adding an optional argument) turns into a libqmp soname bump.
Counter-productive. How do you plan to avoid that?
.so versioning. Ugly as hell to do manually, but if the library was
automatically generated it would not be difficult.
Paolo
4:51 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 03/26/2010 10:37 AM, Markus Armbruster wrote:
> The importances of libqemu is:
>
> 1) Providing a common QMP transport implementation that is extensible
> by third parties
> 2) Providing a set of common transports that support automatic
> discovery of command line launched guests
> 3) Providing a generic QMP dispatch function
>
Adding to this C wrappers for QMP commands threatens to make QMP command
arguments part of the library ABI. Compatible QMP evolution (like
adding an optional argument) turns into a libqmp soname bump.
Counter-productive. How do you plan to avoid that?
You could make the API use QObjects; then you're completely isolated
from high level protocol changes. Of course, this is less useful than
the full API.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
7:53 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 03/26/2010 04:51 AM, Avi Kivity wrote:
On 03/26/2010 10:37 AM, Markus Armbruster wrote:
>
>> The importances of libqemu is:
>>
>> 1) Providing a common QMP transport implementation that is extensible
>> by third parties
>> 2) Providing a set of common transports that support automatic
>> discovery of command line launched guests
>> 3) Providing a generic QMP dispatch function
> Adding to this C wrappers for QMP commands threatens to make QMP command
> arguments part of the library ABI. Compatible QMP evolution (like
> adding an optional argument) turns into a libqmp soname bump.
> Counter-productive. How do you plan to avoid that?
You could make the API use QObjects; then you're completely isolated
from high level protocol changes. Of course, this is less useful than
the full API.
You want both. You want a very high level QObject based API and then
you want automatically generated wrappers with C friendly data types.
The later API loses a little bit but that's okay.
Regards,
Anthony Liguori
8:53 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 03/26/2010 02:37 AM, Markus Armbruster wrote:
Adding to this C wrappers for QMP commands threatens to make QMP
command
arguments part of the library ABI. Compatible QMP evolution (like
adding an optional argument) turns into a libqmp soname bump.
Counter-productive. How do you plan to avoid that?
I had thought about this. I think there's a couple ways to handle it.
You could ignore it and just not change existing symbols. You could
also introduce new functions any time an optional argument is added.
Another option is to add a struct as a final argument whenever such a
change happens that's padded. Then new optional arguments can be added
to the struct.
> Yes, this means you can't just create a JSON-RPC object in
Python and
> talk QMP that way, but that's less desirable than you think it is.
>
> You could if you really wanted to, but you wouldn't get the benefits
> of the common transports.
>
> IOW, imagine qemu-cmd. You want it to support:
>
> # qmp_new_by_name("Fedora")
> qemu-cmd Fedora set_link on
>
> # libqemu-ssh.so - ssh_qmp_new()
> qemu-cmd ssh://anthony@lab1.ibm/Fedora set_link on
>
> # qmp_new_by_fd()
> qemu-cmd -c /path/to/domain/socket set_link on
>
> # libvirt-qemu.so - virDomainGetQMP()
> qemu-cmd -b qemu+ssh://lab1.ibm/system Fedora set_link on
>
> This requires a high level transport.
>
All I'd want from such a transport is a file descriptor. No need to
drag in yet another JSON library via libqmp.
Then you don't standardize creation which is probably where most of the
complexity occurs.
Regards,
Anthony Liguori
8:37 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
Anthony Liguori wrote:
On 03/25/2010 03:26 AM, Vincent Hanquez wrote:
> On 24/03/10 21:40, Anthony Liguori wrote:
>>> If so, what C clients you expected beyond libvirt?
>>
>> Users want a C API. I don't agree that libvirt is the only C
>> interface consumer out there.
>
> (I've seen this written too many times ...)
> How do you know that ? did you do a poll or something where *actual*
> users vote/tell ?
>
> From my point of view, i wouldn't want to write a high level
> management toolstack in C, specially
> since the API is well defined JSON which is easily available in all
> high level language out there.
There's a whole world of C based management toolstacks (CIM).
Regards,
Anthony Liguori
That huge companies have developped over-complicated c-based management
toolstacks doesn't necessarily mean that this is the best way to do it.
It just mean that they have enough qualified ressources to do it.
A simple, language-neutral API is always preferable in my opinion, since
it lowers the prerequisites/entry price, and will allow more people to
use it, including system engineers.
Ensuring that the new API will be easy to use by new comers will also
ensure that it will be easy to use by existing stacks including libvirt.
Also I second Avi's opinion in another mail that "all command line
options [should] have qmp equivalents": it is vital for
flexibility/manageability to be able to programatically change setups
after a VM was started.
To quote the automation part of the "James White Manifesto"[1], a
document that is gaining a lot of traction in the sysadmin/devops community:
"The provided API must have all functionality that the application provides.
The provided API must be tailored to more than one language and platform."
Regards,
Gildas
--
[1] You can find a copy of it here:
http://www.kartar.net/2010/03/james-whites-rules-for-infrastructure/
8:59 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On Thu, Mar 25, 2010 at 08:26:09AM +0000, Vincent Hanquez wrote:
On 24/03/10 21:40, Anthony Liguori wrote:
>>If so, what C clients you expected beyond libvirt?
>
>Users want a C API. I don't agree that libvirt is the only C
>interface consumer out there.
(I've seen this written too many times ...)
How do you know that ? did you do a poll or something where *actual*
users vote/tell ?
From my point of view, i wouldn't want to write a high level management
toolstack in C, specially
since the API is well defined JSON which is easily available in all high
level language out there.
It was pretty straightforward for libvirt to talk to the JSON protocol
from C using the YAJL library, so I don't think it is all that much of
a barrier for low level languages like C either. If we want to make life
easy for app/library developers working against QEMU, then the far more
important aspect is to guarentee stability of all the QEMU interfaces
since that is where all the serious pain occurs over time.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
9:56 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On Thu, Mar 25, 2010 at 01:59:22PM +0000, Daniel P. Berrange wrote:
> From my point of view, i wouldn't want to write a high level
management
> toolstack in C, specially
> since the API is well defined JSON which is easily available in all high
> level language out there.
It was pretty straightforward for libvirt to talk to the JSON protocol
from C using the YAJL library, so I don't think it is all that much of
a barrier for low level languages like C either.
note, that it's not the talking JSON part that's difficult to do in C (it's
just midly annoying compare to a highlevel language), but all the other part of
a toolstack. Since there's no performance requirements, writing in C is just a
bit of a waste ot time, but that's up to the developpers to choose the tools he
wants, even if it's not the most appropriate one ;)
If we want to make life easy for app/library developers working
against QEMU,
then the far more important aspect is to guarentee stability of all the QEMU
interfaces since that is where all the serious pain occurs over time.
if you're talking about the QMP interface then I agree with you. This need to
be back/forward compatible as much as possible and stable.
the other interface (i.e. the user monitor) has no business beeing
backward-compatible though, since it should never be used to talk a RPC.
--
Vincent
10:07 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On Thu, Mar 25, 2010 at 02:56:52PM +0000, Vincent Hanquez wrote:
On Thu, Mar 25, 2010 at 01:59:22PM +0000, Daniel P. Berrange wrote:
> > From my point of view, i wouldn't want to write a high level management
> > toolstack in C, specially
> > since the API is well defined JSON which is easily available in all high
> > level language out there.
>
> It was pretty straightforward for libvirt to talk to the JSON protocol
> from C using the YAJL library, so I don't think it is all that much of
> a barrier for low level languages like C either.
note, that it's not the talking JSON part that's difficult to do in C (it's
just midly annoying compare to a highlevel language), but all the other part of
a toolstack. Since there's no performance requirements, writing in C is just a
bit of a waste ot time, but that's up to the developpers to choose the tools he
wants, even if it's not the most appropriate one ;)
> If we want to make life easy for app/library developers working against QEMU,
> then the far more important aspect is to guarentee stability of all the QEMU
> interfaces since that is where all the serious pain occurs over time.
if you're talking about the QMP interface then I agree with you. This need to
be back/forward compatible as much as possible and stable.
the other interface (i.e. the user monitor) has no business beeing
backward-compatible though, since it should never be used to talk a RPC.
I agree apps shouldn't use it for RPC, but admins using the interactive user
monitor are just as deserving of stable commands & args.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
10:14 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On Thu, Mar 25, 2010 at 03:07:20PM +0000, Daniel P. Berrange wrote:
I agree apps shouldn't use it for RPC, but admins using the
interactive user
monitor are just as deserving of stable commands & args.
I think, once QMP is completely there, admins would be better using a qemu-cmd
that's just serialise it's command line arguments into a JSON command.
(something like dbus-send for dbus).
--
Vincent
10:16 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On Thu, Mar 25, 2010 at 03:14:24PM +0000, Vincent Hanquez wrote:
On Thu, Mar 25, 2010 at 03:07:20PM +0000, Daniel P. Berrange wrote:
> I agree apps shouldn't use it for RPC, but admins using the interactive user
> monitor are just as deserving of stable commands & args.
I think, once QMP is completely there, admins would be better using a qemu-cmd
that's just serialise it's command line arguments into a JSON command.
Then, after a qemu-cmd is introduced, we should mark the user monitor deprecated
along with a specific date/release its future for removal.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
11:01 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 03/25/2010 10:16 AM, Daniel P. Berrange wrote:
On Thu, Mar 25, 2010 at 03:14:24PM +0000, Vincent Hanquez wrote:
> On Thu, Mar 25, 2010 at 03:07:20PM +0000, Daniel P. Berrange wrote:
>
>> I agree apps shouldn't use it for RPC, but admins using the interactive user
>> monitor are just as deserving of stable commands& args.
>>
> I think, once QMP is completely there, admins would be better using a qemu-cmd
> that's just serialise it's command line arguments into a JSON command.
>
Then, after a qemu-cmd is introduced, we should mark the user monitor deprecated
along with a specific date/release its future for removal.
I'm not sure. The human monitor has some features that are not
appropriate for QMP. For instance, the ability to deal with formula
input and some commands meant to add debugging.
I guess you could do that in qemu-cmd but I don't see a compelling
reason to.
Regards,
Anthony Liguori
Daniel
11:30 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
Anthony Liguori wrote:
On 03/25/2010 10:16 AM, Daniel P. Berrange wrote:
> On Thu, Mar 25, 2010 at 03:14:24PM +0000, Vincent Hanquez wrote:
>
>> On Thu, Mar 25, 2010 at 03:07:20PM +0000, Daniel P. Berrange wrote:
>>
>>> I agree apps shouldn't use it for RPC, but admins using the
>>> interactive user
>>> monitor are just as deserving of stable commands& args.
>>>
>> I think, once QMP is completely there, admins would be better using
>> a qemu-cmd
>> that's just serialise it's command line arguments into a JSON command.
>>
> Then, after a qemu-cmd is introduced, we should mark the user monitor
> deprecated
> along with a specific date/release its future for removal.
>
I'm not sure. The human monitor has some features that are not
appropriate for QMP. For instance, the ability to deal with formula
input and some commands meant to add debugging.
I guess you could do that in qemu-cmd but I don't see a compelling
reason to.
As I mentioned before, I'd love to see the qemu binary (incl. monitor
interface) being implemented as a pure QMP user. Then libvirt and
friends can be 100% that they can achieve everything using QMP because
we don't live in the same address space anymore and can't pull tricks.
Alex
9:18 p.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
Anthony Liguori wrote:
I'm not sure. The human monitor has some features that are not
appropriate for QMP. For instance, the ability to deal with formula
input and some commands meant to add debugging.
I guess you could do that in qemu-cmd but I don't see a compelling
reason to.
Would it be all that much work to just rip out the human monitor
altogether, moving it's functionality to qemu-cmd? That'd be a great
way to confirm that QMP has all the functionality.
It doesn't have to be written in C, by the way ;-)
-- Jamie
8:23 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On Wed, 24 Mar 2010 16:40:18 -0500
Anthony Liguori <anthony(a)codemonkey.ws> wrote:
>> We need to have a common management interface for third
party tools.
>>
> QMP? :-)
Only if QMP is compatible with libvirt. I don't want a user to have to
choose between QMP and libvirt.
Why not? If all they want is a simple qemu session, they can use
QMP directly, on the other hand if what they want is more complex,
what's the problem of using a management API like libivrt?
Again, one important point of the this discussion is: what interfaces
should qemu provide and how/when should qemu rely on libvirt?
IMO, we should rely on libvirt for a management interface for all the
reasons that have already been exposed: it has a established community,
it provides a well tested and stable API, it does VM management, it
integrates with several other services like cgroups, SELinux, etc.
Now, regarding qemu:
> You mentioned dynamic dispatch, but this is useful only for C
clients right?
> If so, what C clients you expected beyond libvirt?
Users want a C API. I don't agree that libvirt is the only C interface
consumer out there.
Actually, I do agree. Maybe, we don't have other C consumers because they
weren't crazy enough to parse the crap of the user Monitor (or they do,
but for simple things).
One possible future client is perf, for example.
Here is my solution (actually it's not mine, you have suggested
it some time ago): let's provide a convenient way for C clients to
use QMP. That is, let's have an overly simple library which takes
QDitcs, sends them to qemu through QMP and returns others QDicts.
Something like the _sketch_ below:
// Open a connection
int qmp_open(..., QDict **greeting);
// Register a callback for async messages, BUT note that the async message
// object is passed verbatim
void qmp_async_mes_handler(..., void (*async_mes_handler)(QDict *mes));
// Send a QMP command
int qmp_send(..., const char *command, QDict *params, QDict **res);
Obviously that we'll need a QMPContext and maybe additional functions,
but the two main ideas are:
1. We don't do management
2. QMP is our standard interface
I really think what we want is for a libvirt user to be able to call
libqemu functions directly. There shouldn't have to be libvirt specific
functions for every operation we expose.
Not sure if this is too crazy but, considering this user wants to
use qemu features not implemented by libvirt yet, what about using both
libqmp (above) and libvirt at the same time?
8:55 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 03/25/2010 08:23 AM, Luiz Capitulino wrote:
On Wed, 24 Mar 2010 16:40:18 -0500
Anthony Liguori<anthony(a)codemonkey.ws> wrote:
>>> We need to have a common management interface for third party tools.
>>>
>>>
>> QMP? :-)
>>
> Only if QMP is compatible with libvirt. I don't want a user to have to
> choose between QMP and libvirt.
>
Why not? If all they want is a simple qemu session, they can use
QMP directly, on the other hand if what they want is more complex,
what's the problem of using a management API like libivrt?
My point is that libvirt should not be a separate management API but
effectively an add-on API that provides higher level features, better
integration with Linux host services, etc.
You mentioned dynamic dispatch, but this is useful only for C clients right?
>> If so, what C clients you expected beyond libvirt?
>>
> Users want a C API. I don't agree that libvirt is the only C interface
> consumer out there.
>
Actually, I do agree. Maybe, we don't have other C consumers because they
weren't crazy enough to parse the crap of the user Monitor (or they do,
but for simple things).
One possible future client is perf, for example.
Here is my solution (actually it's not mine, you have suggested
it some time ago): let's provide a convenient way for C clients to
use QMP. That is, let's have an overly simple library which takes
QDitcs, sends them to qemu through QMP and returns others QDicts.
Something like the _sketch_ below:
// Open a connection
int qmp_open(..., QDict **greeting);
// Register a callback for async messages, BUT note that the async message
// object is passed verbatim
void qmp_async_mes_handler(..., void (*async_mes_handler)(QDict *mes));
// Send a QMP command
int qmp_send(..., const char *command, QDict *params, QDict **res);
Yes, this is the core API. It's missing a mechanism to create a
QMPContext. I'll also argue that we want a set of auto generated
wrappers like:
QError *qmp_last_error(QMPContext *context);
int qmp_set_link(QMPContext *context, const char *name, bool up);
That's a thin wrapper around qmp_send(). You can autogenerate this
fairly easy with an IDL like:
None:qmp_set_link:String:name,Boolean:up
Which is fairly easy to output using introspection on a QMP session.
Obviously that we'll need a QMPContext and maybe additional
functions,
And for a QMPContext, we need functions like:
/* use qemu's default advertisement mechanism to find a guest */
QMPContext *qmp_context_new_by_uuid(uuid_t uuid);
QMPContext *qmp_context_new_by_name(const char *name);
/* connect to an already established QMP session */
QMPContext *qmp_context_new_by_fd(int fd);
QMPContext *qmp_context_new_by_iops(QMPIOOps *ops);
libvirt could use qmp_context_new_by_iops() to implement a
virQemuGetQMP(). It can support this either by having a second QMP
connection or even by parsing the QMP traffic and relaying commands over
it QMP session (which gives it a chance to snoop on anything it's
interested in). I think the former approach is less difficult technically.
We can certainly make it easier to create dynamic QMP sessions.
but the two main ideas are:
1. We don't do management
I really believe we need to stop thinking this way. I'm not saying that
qemu-devel is the place where we design virt-manager, but we ought to
consider the whole stack as part of "we".
> I really think what we want is for a libvirt user to be able to
call
> libqemu functions directly. There shouldn't have to be libvirt specific
> functions for every operation we expose.
>
Not sure if this is too crazy but, considering this user wants to
use qemu features not implemented by libvirt yet, what about using both
libqmp (above) and libvirt at the same time?
Yes, that's *exactly* what I want. Except I want to call it libqemu
because qmp is an implementation detail.
Regards,
Anthony Liguori
7:52 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On Thu, 25 Mar 2010 08:55:42 -0500
Anthony Liguori <anthony(a)codemonkey.ws> wrote:
On 03/25/2010 08:23 AM, Luiz Capitulino wrote:
> On Wed, 24 Mar 2010 16:40:18 -0500
> Anthony Liguori<anthony(a)codemonkey.ws> wrote:
>
>
>>>> We need to have a common management interface for third party tools.
>>>>
>>>>
>>> QMP? :-)
>>>
>> Only if QMP is compatible with libvirt. I don't want a user to have to
>> choose between QMP and libvirt.
>>
> Why not? If all they want is a simple qemu session, they can use
> QMP directly, on the other hand if what they want is more complex,
> what's the problem of using a management API like libivrt?
>
My point is that libvirt should not be a separate management API but
effectively an add-on API that provides higher level features, better
integration with Linux host services, etc.
Okay, I fully agree here.
>>> If so, what C clients you expected beyond libvirt?
>>>
>> Users want a C API. I don't agree that libvirt is the only C interface
>> consumer out there.
>>
> Actually, I do agree. Maybe, we don't have other C consumers because they
> weren't crazy enough to parse the crap of the user Monitor (or they do,
> but for simple things).
>
> One possible future client is perf, for example.
>
> Here is my solution (actually it's not mine, you have suggested
> it some time ago): let's provide a convenient way for C clients to
> use QMP. That is, let's have an overly simple library which takes
> QDitcs, sends them to qemu through QMP and returns others QDicts.
>
> Something like the _sketch_ below:
>
> // Open a connection
> int qmp_open(..., QDict **greeting);
>
> // Register a callback for async messages, BUT note that the async message
> // object is passed verbatim
> void qmp_async_mes_handler(..., void (*async_mes_handler)(QDict *mes));
>
> // Send a QMP command
> int qmp_send(..., const char *command, QDict *params, QDict **res);
>
Yes, this is the core API. It's missing a mechanism to create a
QMPContext. I'll also argue that we want a set of auto generated
wrappers like:
Having the wrappers is one of the points we disagree, but as we have agreed
on starting with the core only, I don't see why keep arguing here.
If, in the near feature, the need of having wrappers become evident
I'll be all for it (this statement is a bit dangerous though, as
this need can be subjective).
[...]
> but the two main ideas are:
>
> 1. We don't do management
>
I really believe we need to stop thinking this way. I'm not saying that
qemu-devel is the place where we design virt-manager, but we ought to
consider the whole stack as part of "we".
Depends, if you mean that we should be involved with libvirt development,
than I completely agree.
On the other hand, if you mean than qemu should provide its own management
API, than I tend to disagree. And I think this is a very important point of
the whole discussion, if you think this way I guess we should start a new
thread to collect feedback, listing pros and cons.
>> I really think what we want is for a libvirt user to be able
to call
>> libqemu functions directly. There shouldn't have to be libvirt specific
>> functions for every operation we expose.
>>
> Not sure if this is too crazy but, considering this user wants to
> use qemu features not implemented by libvirt yet, what about using both
> libqmp (above) and libvirt at the same time?
>
Yes, that's *exactly* what I want. Except I want to call it libqemu
because qmp is an implementation detail.
libqemu is fine.
1:37 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 03/24/2010 10:32 PM, Anthony Liguori wrote:
So far, a libqemu.so with a flexible transport that could be used
directly by a libvirt user (ala cairo/gdk type interactions) seems
like the best solution to me.
libqemu.so would be a C API. C is not the first choice for writing GUIs
or management applications. So it would need to be further wrapped.
We also need to allow qemu to control the display directly, without
going through vnc.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
3:18 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 25.03.2010, at 07:37, Avi Kivity wrote:
On 03/24/2010 10:32 PM, Anthony Liguori wrote:
>
> So far, a libqemu.so with a flexible transport that could be used directly by a
libvirt user (ala cairo/gdk type interactions) seems like the best solution to me.
libqemu.so would be a C API. C is not the first choice for writing GUIs or management
applications. So it would need to be further wrapped.
We also need to allow qemu to control the display directly, without going through vnc.
For the current functionality I tend to disagree. All that we need is an shm vnc extension
that allows the GUI and qemu to not send image data over the wire, but only the dirtyness
information.
As soon as we get to 3D things might start to look different.
Alex
11:01 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 03/25/2010 10:18 AM, Alexander Graf wrote:
> libqemu.so would be a C API. C is not the first choice for writing GUIs or
management applications. So it would need to be further wrapped.
>
> We also need to allow qemu to control the display directly, without going through
vnc.
>
For the current functionality I tend to disagree. All that we need is an shm vnc
extension that allows the GUI and qemu to not send image data over the wire, but only the
dirtyness information.
It still means an extra copy. I don't think we want to share the guest
framebuffer (it includes offscreen bitmaps), so we'll need to copy it
somewhere else. It's even worse with qxl/spice where there is no
framebuffer.
As soon as we get to 3D things might start to look different.
Very different.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
7:19 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 03/24/2010 12:17 AM, Avi Kivity wrote:
On 03/23/2010 08:00 PM, Avi Kivity wrote:
> On 03/23/2010 06:06 PM, Anthony Liguori wrote:
>>> I thought the monitor protocol *was* our API. If not, why not?
>>
>> It is. But our API is missing key components like guest
>> enumeration. So the fundamental topic here is, do we introduce
>> these missing components to allow people to build directly to our
>> interface or do we make use of the functionality that libvirt
>> already provides if they can plumb our API directly to users.
>>
>
> Guest enumeration is another API.
>
> Over the kvm call I suggested a qemu concentrator that would keep
> track of all running qemus, and would hand out monitor connections to
> users. It can do the enumeration (likely using qmp). Libvirt could
> talk to that, like it does with other hypervisors.
>
To elaborate
qemud
- daemonaizes itself
- listens on /var/lib/qemud/guests for incoming guest connections
- listens on /var/lib/qemud/clients for incoming client connections
- filters access according to uid (SCM_CREDENTIALS)
- can pass a new monitor to client (SCM_RIGHTS)
- supports 'list' command to query running guests
- async messages on guest startup/exit
Then guests run with the wrong security context.
Regards,
Anthony Liguori
qemu
- with -qemud option, connects to qemud (or maybe automatically?)
qemudc
- command-line client, can access qemu human monitor
7:27 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 03/24/2010 02:19 PM, Anthony Liguori wrote:
> qemud
> - daemonaizes itself
> - listens on /var/lib/qemud/guests for incoming guest connections
> - listens on /var/lib/qemud/clients for incoming client connections
> - filters access according to uid (SCM_CREDENTIALS)
> - can pass a new monitor to client (SCM_RIGHTS)
> - supports 'list' command to query running guests
> - async messages on guest startup/exit
Then guests run with the wrong security context.
Why? They run with the security context of whoever launched them (could
be libvirtd).
--
error compiling committee.c: too many arguments to function
7:30 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 03/24/2010 07:27 AM, Avi Kivity wrote:
On 03/24/2010 02:19 PM, Anthony Liguori wrote:
>> qemud
>> - daemonaizes itself
>> - listens on /var/lib/qemud/guests for incoming guest connections
>> - listens on /var/lib/qemud/clients for incoming client connections
>> - filters access according to uid (SCM_CREDENTIALS)
>> - can pass a new monitor to client (SCM_RIGHTS)
>> - supports 'list' command to query running guests
>> - async messages on guest startup/exit
>
>
> Then guests run with the wrong security context.
Why? They run with the security context of whoever launched them
(could be libvirtd).
Because it doesn't have the same security context as qemud and since
clients have to connect to qemud, qemud has to implement access control.
It's far better to have the qemu instance advertise itself such that and
client connects directly to it. Then all of the various authorization
models will be applied correctly to it.
Regards,
Anthony Liguori
7:32 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 03/24/2010 02:30 PM, Anthony Liguori wrote:
On 03/24/2010 07:27 AM, Avi Kivity wrote:
> On 03/24/2010 02:19 PM, Anthony Liguori wrote:
>>> qemud
>>> - daemonaizes itself
>>> - listens on /var/lib/qemud/guests for incoming guest connections
>>> - listens on /var/lib/qemud/clients for incoming client connections
>>> - filters access according to uid (SCM_CREDENTIALS)
>>> - can pass a new monitor to client (SCM_RIGHTS)
>>> - supports 'list' command to query running guests
>>> - async messages on guest startup/exit
>>
>>
>> Then guests run with the wrong security context.
>
> Why? They run with the security context of whoever launched them
> (could be libvirtd).
Because it doesn't have the same security context as qemud and since
clients have to connect to qemud, qemud has to implement access control.
Yeah.
It's far better to have the qemu instance advertise itself such
that
and client connects directly to it. Then all of the various
authorization models will be applied correctly to it.
Agreed. qemud->exit().
--
error compiling committee.c: too many arguments to function
1:07 p.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On Tue, Mar 23, 2010 at 11:06:20AM -0500, Anthony Liguori wrote:
On 03/23/2010 10:57 AM, Paul Brook wrote:
>>>I think there is a serious divergence of approach there, instanciating
>>>API stating 'we are gonna deprecate them sooner or later' tell the
>>>application developper 'my time is more important than yours' and
not
>>>really something I like to carry to the API users.
>>>The main goal of libvirt remains to provide APIs needed to unify the
>>>development of the virtualization layers. Having APIs which makes
>>>sense only for one or 2 virtualization engines is not a problem in
>>>itself, it just raises questions about the actual semantic of that API.
>>>If that semantic is sound, then I see no reason to not add it, really
>>>and we actually often do.
>>>
>>Yeah, but the problem we're facing is, I want there to be an API added
>>to the management layer as part of the feature commit in qemu. If there
>>has to be a discussion and decisions about how to model the API, it's
>>not going to be successful.
>>
>I thought the monitor protocol *was* our API. If not, why not?
It is. But our API is missing key components like guest enumeration.
So the fundamental topic here is, do we introduce these missing
components to allow people to build directly to our interface or do we
make use of the functionality that libvirt already provides if they can
plumb our API directly to users.
There's two levels of API here
- VM level API - essentially APIs for the QMP protocol & qdev ARGV format
- Host level API - guest enumeration, integration with other OS services
like cgroups, selinux, etc
QEMU has historically only cared about the per-VM level, but has not
actually provided any formal library APIs even for the monitor protocol
or command line syntax.
libvirt has obviously focused on the host level APIs, and directly figured
out the implicit VM level "API" that was exposed from QEMU. I think this is
a good split to maintain, because when you get to the host level API you
start interacting / integrating beyond just QEMU with OS services like
cgroups, selinux, iptables, host networking, etc. QEMU might start with
a simple daemon for enumerating VMs....but that's how libvirt's QEMU driver
started off. Over time that "simple" demon would grow to end up doing all
the things that libvirt currently does. This duplication of functionality
doesn't seem like a good use of development resources to me.
Now libvirt does not currently directly expose the two VM level APIs that
QEMU has (qdev ARGV, and QMP protocol), which is where our feature timelag
comes from. If we can figure out a way to expose those two, then there
shouldn't be a need for QEMU to get into duplicate host-level APIs like
enumeration.
There could still be useful APIs that QEMU can expose those. For example,
consider if QEMU provided
- libqmp.so - API(s) for each monitor command that serialized to/from JSON
format string
- libqdev.so - API(s) for constructing qdev strings, that can then be used
as ARGV values, or QMP parameter values.
Next consider if libvirt provided a way to pass extra ARGV down to QEMU,
and also provided a way to send/recv JSON commands/events.
The libqmp.so & libqdev.so could then be used both directly against a single
QEMU process spawned manually, but also indirectly via libvirt. eg, to use
snapshots with libvirt, an app would use libqmp.so to generate a QMP command
for snapshotting, send it to the VM via the libvirt API for monitor injection
and get the response. The nice aspect of this is that libvirt is actually
adding value to libqmp.so, because users would now have secure remote
access to the QEMU monitor, tunnelled via libvirtd. It also avoids adding an
arbitrary number of extra APIs to libvirt - we just need the API to send
and recv JSON in libvirt, and libqmp.so can then be used ontop of that
In ascii art you'd end up with two models
Interacting with a single VM directly:
Application -> libqmp.so/libqdev.so -> QEMU
Interacting with many VMs via libvirt
Application -------------> libvirt API ----> libvirtd ----> QEMU
| ^
| |
+--------> libqmp.so ---+
+--------> libqdev.so --+
So primarily an app would still use libvirt as the host level management
API, but libqmp.so proxied via libvirt would also allow access to arbitrary
extra features. This avoids the big overlap in functionality between libvirt
& QEMU apis, which would occurr if QEMU started doing multiple VM mgmt too.
Regards,
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
2:24 p.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 03/23/2010 01:07 PM, Daniel P. Berrange wrote:
On Tue, Mar 23, 2010 at 11:06:20AM -0500, Anthony Liguori wrote:
> On 03/23/2010 10:57 AM, Paul Brook wrote:
>
>>>> I think there is a serious divergence of approach there, instanciating
>>>> API stating 'we are gonna deprecate them sooner or later' tell
the
>>>> application developper 'my time is more important than yours' and
not
>>>> really something I like to carry to the API users.
>>>> The main goal of libvirt remains to provide APIs needed to unify the
>>>> development of the virtualization layers. Having APIs which makes
>>>> sense only for one or 2 virtualization engines is not a problem in
>>>> itself, it just raises questions about the actual semantic of that API.
>>>> If that semantic is sound, then I see no reason to not add it, really
>>>> and we actually often do.
>>>>
>>>>
>>> Yeah, but the problem we're facing is, I want there to be an API added
>>> to the management layer as part of the feature commit in qemu. If there
>>> has to be a discussion and decisions about how to model the API, it's
>>> not going to be successful.
>>>
>>>
>> I thought the monitor protocol *was* our API. If not, why not?
>>
> It is. But our API is missing key components like guest enumeration.
> So the fundamental topic here is, do we introduce these missing
> components to allow people to build directly to our interface or do we
> make use of the functionality that libvirt already provides if they can
> plumb our API directly to users.
>
There's two levels of API here
- VM level API - essentially APIs for the QMP protocol& qdev ARGV format
- Host level API - guest enumeration, integration with other OS services
like cgroups, selinux, etc
QEMU has historically only cared about the per-VM level, but has not
actually provided any formal library APIs even for the monitor protocol
or command line syntax.
We also provide an API for guest creation (the qemu command line). When
we create a guest, we don't integrate with things like cgroups and
selinux and we probably never will. This is a place where libvirt adds
value.
The fundamental problem we have is that once you create a qemu instance,
you cannot find it from a third party tool. That's a problem we ought
to solve and I'd like to see that be common across qemu and libvirt. I
don't see that as us growing our scope into libvirt's space.
I think libvirt does two things. It provides a generic interface to
hypervisors and if people write to this interface, they get better
portability and the ability to management many platforms. It also
provides a certain amount of host services management that can include
things not directly related to qemu (like network management) and
services that further connect qemu to host services (like selinux
labelling).
What I would like to see is that a user can write to the libvirt API and
then call out to qemu specific functions when necessary. I'd also like
a user be able to interact directly with qemu without using the libvirt
generic API. The user should be able to still see the VMs and
ultimately interact with them through libvirt. The user should be able
to use libvirt to deal with host services too (like storage and network
pools).
The key is not to have two mutual exclusive management mechanisms but a
set of complementary APIs. The biggest obstacle I see is libvirt's
remote management interface. I think it's addressable though. For
instance, if libqemu.so provided a QMP IO interface, libvirt-qemu could
basically provide an interface to create that context and otherwise have
users use the libqemu.so interfaces directly.
IOW, libqemu.so would provide interfaces that looked like:
QMPContext *qemu_connect_by_name(const char *name);
int qemu_pci_add(QMPContext *ctxt, ...);
And libvirt would provide interfaces that looked like:
virQemuPtr *virDomainGetQemuPtr(virDomainPtr *ptr);
QMPContext *virQemuCreateQMPContext(virQemuPtr *ptr);
With respect to keep tracking of which operations are done through qemu,
we should discuss the technical challenges of this and figure out how we
can solve them.
The libqmp.so& libqdev.so could then be used both directly
against a single
QEMU process spawned manually, but also indirectly via libvirt.
That's not quite what I'm looking for because then it's really two
separate interfaces. I'd rather see complementary interfaces much like
how Cairo integrates with GTK/GDK or even how GDK integrates with X11.
Regards,
Anthony Liguori
12:49 a.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
On 03/23/2010 09:24 PM, Anthony Liguori wrote:
We also provide an API for guest creation (the qemu command line).
As an aside, I'd like to see all command line options have qmp
equivalents (most of them can be implemented with a 'set' command that
writes qdev values). This allows a uniform way to control a guest,
whether at startup or runtime. You start with a case, cold-plug a
motherboard, cpus, memory, disk controllers, and power it on.
I would also like a way to read the entire qdev tree from qmp.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
6:22 p.m.
New subject: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
Anthony Liguori wrote:
On 03/23/2010 10:57 AM, Paul Brook wrote:
>I thought the monitor protocol *was* our API. If not, why not?
It is. But our API is missing key components like guest enumeration.
Is that simply enumerating running qemu instances, and asking each one
about things like it's name, VNC port, etc.?
Having each qemu publish itself through D-Bus or Avahi (to find the
list of running instances), and every info query go through the
monitor, would seem a clean solution to that.
Are there any other missing key components?
-- Jamie
5355
days inactive
5358
days old
65 comments
10 participants
participants (10)
-
Alexander Graf -
Anthony Liguori -
Avi Kivity -
Daniel P. Berrange -
Gildas Le Nadan -
Jamie Lokier -
Luiz Capitulino -
Markus Armbruster -
Paolo Bonzini -
Vincent Hanquez