Re: [libvirt] Supporting hypervisor specific APIs in libvirt

2010-03-24 Thread Juan Quintela
Andi Kleen a...@firstfloor.org wrote: Juan Quintela quint...@redhat.com 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

Re: [libvirt] Supporting hypervisor specific APIs in libvirt

2010-03-24 Thread Andi Kleen
Juan Quintela quint...@redhat.com 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.

Re: [libvirt] Supporting hypervisor specific APIs in libvirt

2010-03-23 Thread Daniel P. Berrange
On Mon, Mar 22, 2010 at 04:49:21PM -0500, Anthony Liguori wrote: On 03/22/2010 03:10 PM, Daniel P. Berrange wrote: This isn't necessarily libvirt's problem if it's mission is to provide a common hypervisor API that covers the most commonly used features. That is more or less our current

Re: [libvirt] Supporting hypervisor specific APIs in libvirt

2010-03-23 Thread Juan Quintela
Gerd Hoffmann kra...@redhat.com 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

Re: [libvirt] Supporting hypervisor specific APIs in libvirt

2010-03-23 Thread Juan Quintela
Anthony Liguori anth...@codemonkey.ws 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.

Re: [libvirt] Supporting hypervisor specific APIs in libvirt

2010-03-23 Thread Juan Quintela
Daniel P. Berrange berra...@redhat.com wrote: On Tue, Mar 23, 2010 at 11:50:57AM +0100, Juan Quintela wrote: Gerd Hoffmann kra...@redhat.com 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

Re: [libvirt] Supporting hypervisor specific APIs in libvirt

2010-03-23 Thread Daniel Veillard
On Mon, Mar 22, 2010 at 02:25:00PM -0500, Anthony Liguori wrote: Hi, Hi Anthony, 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

Re: [libvirt] Supporting hypervisor specific APIs in libvirt

2010-03-23 Thread Anthony Liguori
On 03/23/2010 09:51 AM, Daniel Veillard wrote: On Mon, Mar 22, 2010 at 02:25:00PM -0500, Anthony Liguori wrote: Hi, Hi Anthony, 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

[libvirt] Supporting hypervisor specific APIs in libvirt

2010-03-22 Thread Anthony Liguori
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't necessarily libvirt's problem if

Re: [libvirt] Supporting hypervisor specific APIs in libvirt

2010-03-22 Thread Daniel P. Berrange
On Mon, Mar 22, 2010 at 02:25:00PM -0500, 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

Re: [libvirt] Supporting hypervisor specific APIs in libvirt

2010-03-22 Thread Anthony Liguori
On 03/22/2010 03:10 PM, Daniel P. Berrange wrote: This isn't necessarily libvirt's problem if it's mission is to provide a common hypervisor API that covers the most commonly used features. That is more or less our current mission. If this mission leads to QEMU creating a non-libvirt