On 10/15/2012 06:29 PM, Radhika Niranjan wrote: Since your <hostdev> used managed='yes', you should use it here too: <interface type='hostdev' managed='yes'> <model> is unused for interface type='hostdev', so that line is harmless, but also meaningless. (actually it should probably log an error when it sees that, but currently just ignores it). This is a bit odd. It means that some code path has returned an error without logging an error message. I tried removing "managed='yes'" and adding <model type='virtio'/> to a similar interface definition on the one machine where I have an SR-IOV card, and it failed to start, but gave a slightly less meaningless message: error: Unable to read from monitor: Connection reset by peer (This is less meaningless because that generally indicates that the qemu-kvm process encountered an error and exited, so I know I can look in /var/log/libvirt/qemu/$guest.log for an error. And indeed, when I look there I see this: Failed to assign device "hostdev0" : Device or resource busy qemu-kvm: -device pci-assign,host=03:10.1,id=hostdev0,configfd=32,bus=pci.0,addr=0x7: Device 'pci-assign' could not be initialized which makes sense. That file is used to save the previous MAC address and vlan tag of the VF for restoration when the guest is finished with it. I'm not sure why that error wasn't propogated back to virsh. (btw, this error isn't the root error anyway - it would only be issued if a failure happened while attempting to save the old MAC address/vlan of the VF. Perhaps there's a failure in that bit of code that fails without logging an error.) How handy are you at running gdb? If you could install the debuginfo for libvirt, then attach gdb and set a breakpoint on the function qemuDomainHostdevNetConfigReplace then single step, I'm pretty sure whatever failure you're encountering is somewhere within one of the functions called by that function. Otherwise we can probably find it by manual examination, but that will take *much* more effort/time.