Re: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt

2010-03-26 Thread Paolo Bonzini
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 manu

Re: [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt

2010-03-24 Thread Gerd Hoffmann
In practice I've seen this not working correctly in the past, i.e. my ^^^ br0 didn't pop up in the virt-manager nic setup page. Please file a bug: virt-manager has had bridge detection for years, so something must be going wrong. W

Re: [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt

2010-03-24 Thread Cole Robinson
On 03/24/2010 03:59 AM, Gerd Hoffmann wrote: > On 03/24/10 00:13, Jamie Lokier wrote: >> Gerd Hoffmann wrote: - networking: man, setting networking is a mess, libvirt just does it for you. >>> >>> +1 >>> >>> Even when not using libvirt for a reason or another I usually hook my >>> virt

[Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt

2010-03-24 Thread Juan Quintela
Andi Kleen wrote: > Juan Quintela writes: >> >> - networking: man, setting networking is a mess, libvirt just does it >> for you. > > Agreed it's messy, but isn't this something that the standard qemu > command line tool could potentially do better by itself? I don't see why you > need a wrapp

Re: [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt

2010-03-24 Thread Gerd Hoffmann
On 03/24/10 00:13, Jamie Lokier wrote: Gerd Hoffmann wrote: - networking: man, setting networking is a mess, libvirt just does it for you. +1 Even when not using libvirt for a reason or another I usually hook my virtual machines into virbr0 (libvirt default network). I had the opposite p

Re: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt

2010-03-23 Thread Avi Kivity
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 gue

[Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt

2010-03-23 Thread Andi Kleen
Juan Quintela writes: > > - networking: man, setting networking is a mess, libvirt just does it > for you. Agreed it's messy, but isn't this something that the standard qemu command line tool could potentially do better by itself? I don't see why you need a wrapper for that. -Andi -- a...@li

Re: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt

2010-03-23 Thread Anthony Liguori
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 gue

Re: [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt

2010-03-23 Thread Jamie Lokier
Juan Quintela wrote: > - monitor: I need a way to get to the monitor when going through > libvirt, in the past you couldn't allow this, but now it looks > possible. Now you can just start another monitor connection to qemu :-) Previously I've used a multiplexing script which accepts multiple

Re: [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt

2010-03-23 Thread Jamie Lokier
Gerd Hoffmann wrote: > >- networking: man, setting networking is a mess, libvirt just does it > > for you. > > +1 > > Even when not using libvirt for a reason or another I usually hook my > virtual machines into virbr0 (libvirt default network). I had the opposite problem. Needed to use mult

Re: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt

2010-03-23 Thread Daniel P. Berrange
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 i

[Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt

2010-03-23 Thread Juan Quintela
"Daniel P. Berrange" wrote: > On Tue, Mar 23, 2010 at 11:50:57AM +0100, Juan Quintela wrote: >> Gerd Hoffmann wrote: >> >> - networking: man, setting networking is a mess, libvirt just does it >> >>for you. >> > >> > +1 >> > >> > Even when not using libvirt for a reason or another I usually h

Re: [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt

2010-03-23 Thread Daniel P. Berrange
On Tue, Mar 23, 2010 at 11:50:57AM +0100, Juan Quintela wrote: > Gerd Hoffmann wrote: > >> - networking: man, setting networking is a mess, libvirt just does it > >>for you. > > > > +1 > > > > Even when not using libvirt for a reason or another I usually hook my > > virtual machines into virbr

[Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt

2010-03-23 Thread Juan Quintela
Gerd Hoffmann wrote: >> - networking: man, setting networking is a mess, libvirt just does it >>for you. > > +1 > > Even when not using libvirt for a reason or another I usually hook my > virtual machines into virbr0 (libvirt default network). This is a war for another day :-) I have that ve

Re: [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt

2010-03-23 Thread Gerd Hoffmann
- networking: man, setting networking is a mess, libvirt just does it for you. +1 Even when not using libvirt for a reason or another I usually hook my virtual machines into virbr0 (libvirt default network). cheers, Gerd

[Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt

2010-03-23 Thread Juan Quintela
Anthony Liguori wrote: > Hi, > > I've mentioned this to a few folks already but I wanted to start a > proper thread. > > We're struggling in qemu with usability and one area that concerns me > is the disparity in features that are supported by qemu vs what's > implemented in libvirt. > > This isn'