Re: [libvirt] [Patch v2 3/3] apparmor: QEMU bridge helper policy updates

2012-07-06 Thread Jamie Strandboge
On Tue, 2012-07-03 at 12:05 -0400, rmar...@linux.vnet.ibm.com wrote: > Quoting Jamie Strandboge : > > > On Fri, 2012-06-29 at 14:08 -0400, rmar...@linux.vnet.ibm.com wrote: > >> From: Richa Marwaha > >> > >> This patch provides AppArmor policy updates for the QEMU bridge helper. > >> The QEMU bri

Re: [libvirt] [Qemu-devel] [PATCH v4 0/7] file descriptor passing using pass-fd

2012-07-06 Thread Corey Bryant
On 07/06/2012 01:40 PM, Corey Bryant wrote: On 07/06/2012 05:11 AM, Kevin Wolf wrote: Am 05.07.2012 19:00, schrieb Eric Blake: On 07/05/2012 10:35 AM, Corey Bryant wrote: 1. client calls 'add-fd', qemu is now tracking fd=4 in fdset1 with refcount of 0; fd=4's in-use flag is turned on 2. cl

Re: [libvirt] [Qemu-devel] [PATCH v4 0/7] file descriptor passing using pass-fd

2012-07-06 Thread Corey Bryant
On 07/06/2012 05:11 AM, Kevin Wolf wrote: Am 05.07.2012 19:00, schrieb Eric Blake: On 07/05/2012 10:35 AM, Corey Bryant wrote: 1. client calls 'add-fd', qemu is now tracking fd=4 in fdset1 with refcount of 0; fd=4's in-use flag is turned on 2. client calls 'device-add' with /dev/fdset/1 as th

Re: [libvirt] [Qemu-devel] [PATCH v4 0/7] file descriptor passing using pass-fd

2012-07-06 Thread Corey Bryant
Ugh... please disregard this. I hit send accidentally. On 07/06/2012 01:14 PM, Corey Bryant wrote: On 07/06/2012 05:11 AM, Kevin Wolf wrote: Am 05.07.2012 19:00, schrieb Eric Blake: On 07/05/2012 10:35 AM, Corey Bryant wrote: 1. client calls 'add-fd', qemu is now tracking fd=4 in fdset1 wi

Re: [libvirt] [Qemu-devel] [PATCH v4 0/7] file descriptor passing using pass-fd

2012-07-06 Thread Corey Bryant
On 07/06/2012 05:11 AM, Kevin Wolf wrote: Am 05.07.2012 19:00, schrieb Eric Blake: On 07/05/2012 10:35 AM, Corey Bryant wrote: 1. client calls 'add-fd', qemu is now tracking fd=4 in fdset1 with refcount of 0; fd=4's in-use flag is turned on 2. client calls 'device-add' with /dev/fdset/1 as th

Re: [libvirt] [fedora-virt] qemu 1.1.0 in Rawhide, and planned backport to F17 (was: Re: Upgrading qemu to 1.1 in rawhide)

2012-07-06 Thread Daniel P. Berrange
On Fri, Jul 06, 2012 at 04:26:22PM +0100, Daniel P. Berrange wrote: > On Fri, Jul 06, 2012 at 04:13:26PM +0100, Richard W.M. Jones wrote: > > On Fri, Jul 06, 2012 at 04:06:13PM +0100, Daniel P. Berrange wrote: > > > On Fri, Jul 06, 2012 at 03:51:58PM +0100, Richard W.M. Jones wrote: > > > > > > >

Re: [libvirt] [fedora-virt] qemu 1.1.0 in Rawhide, and planned backport to F17 (was: Re: Upgrading qemu to 1.1 in rawhide)

2012-07-06 Thread Daniel P. Berrange
On Fri, Jul 06, 2012 at 04:13:26PM +0100, Richard W.M. Jones wrote: > On Fri, Jul 06, 2012 at 04:06:13PM +0100, Daniel P. Berrange wrote: > > On Fri, Jul 06, 2012 at 03:51:58PM +0100, Richard W.M. Jones wrote: > > > > > > Here is the output of virsh capabilities. It seems to make no sense. > > >

Re: [libvirt] [fedora-virt] qemu 1.1.0 in Rawhide, and planned backport to F17 (was: Re: Upgrading qemu to 1.1 in rawhide)

2012-07-06 Thread Richard W.M. Jones
On Fri, Jul 06, 2012 at 04:06:13PM +0100, Daniel P. Berrange wrote: > On Fri, Jul 06, 2012 at 03:51:58PM +0100, Richard W.M. Jones wrote: > > > > Here is the output of virsh capabilities. It seems to make no sense. > > But it might indicate that something about detection of the > > qemu-kvm-1.1.0

Re: [libvirt] [fedora-virt] qemu 1.1.0 in Rawhide, and planned backport to F17 (was: Re: Upgrading qemu to 1.1 in rawhide)

2012-07-06 Thread Richard W.M. Jones
On Fri, Jul 06, 2012 at 04:13:26PM +0100, Richard W.M. Jones wrote: > LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin > /usr/bin/qemu-system-x86_64 -device ? -device pci-assign,? -device > virtio-blk-pci,? -device virtio-net-pci,? -device scsi-disk,? Actually, this command works

Re: [libvirt] [fedora-virt] qemu 1.1.0 in Rawhide, and planned backport to F17 (was: Re: Upgrading qemu to 1.1 in rawhide)

2012-07-06 Thread Daniel P. Berrange
On Fri, Jul 06, 2012 at 03:51:58PM +0100, Richard W.M. Jones wrote: > > Here is the output of virsh capabilities. It seems to make no sense. > But it might indicate that something about detection of the > qemu-kvm-1.1.0 binary fails, so libvirt assumes that it's not working. With luck libvirt sh

Re: [libvirt] [fedora-virt] qemu 1.1.0 in Rawhide, and planned backport to F17 (was: Re: Upgrading qemu to 1.1 in rawhide)

2012-07-06 Thread Richard W.M. Jones
Here is the output of virsh capabilities. It seems to make no sense. But it might indicate that something about detection of the qemu-kvm-1.1.0 binary fails, so libvirt assumes that it's not working. Rich. $ sudo virsh capabilities 2b8c6f80-b15c-11df-9cfd-b727e82cf6bb x86_64

Re: [libvirt] [fedora-virt] qemu 1.1.0 in Rawhide, and planned backport to F17 (was: Re: Upgrading qemu to 1.1 in rawhide)

2012-07-06 Thread Richard W.M. Jones
[On the topic of qemu 1.1.0 in Fedora 17] I'm seeing some very peculiar problems with virt-install that might be due to libvirt. Is libvirt in F17 too old for qemu 1.1.0? --- (1) Just installing qemu-system-x86 isn't enough for libvirt to recognize any hypervisors: ERRORHost does not s

Re: [libvirt] libvirt and qemu

2012-07-06 Thread Dave Allan
On Wed, Jul 04, 2012 at 02:43:20PM +0200, mattias wrote: > when i do > virsh connect qemu:///system > i can connect > but virsh list > dosent show anything Are your VMs running? virsh list will only show running VMs, so show non-running VMs use: virsh list --all Dave > my qemu vms are not cre

Re: [libvirt] [Qemu-devel] [PATCH v4 0/7] file descriptor passing using pass-fd

2012-07-06 Thread Kevin Wolf
Am 05.07.2012 18:37, schrieb Corey Bryant: > There is one case I'm aware of where we need to be careful: Before > opening an image, qemu may probe the format. In this case, the image > gets opened twice, and the first close comes before the second open. > I'm > not entirely sure

Re: [libvirt] [Qemu-devel] [PATCH v4 0/7] file descriptor passing using pass-fd

2012-07-06 Thread Kevin Wolf
Am 05.07.2012 19:00, schrieb Eric Blake: > On 07/05/2012 10:35 AM, Corey Bryant wrote: >> 1. client calls 'add-fd', qemu is now tracking fd=4 in fdset1 with >> refcount of 0; fd=4's in-use flag is turned on >> 2. client calls 'device-add' with /dev/fdset/1 as the backing filename, >> so qemu_open()