Bug 333221

Summary: Unable to run more than 1 guest simultaneously
Product: [Fedora] Fedora Reporter: David Aquilina <dwa>
Component: libvirtAssignee: Daniel Berrangé <berrange>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 8CC: flanagan, hbrock, jhutar
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 0.4.1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-04-04 16:05:03 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Strip auto-genereted vnetXXXX interfaces
none
Strip autogenerated vnet target devs none

Description David Aquilina 2007-10-15 22:01:09 UTC
Description of problem:

When I attempt to run more than 1 guest at a time, I receive the following error
when I attempt to start the second guest: 

virDomainCreate() failed Failed to add tap interface 'vnet0' to bridge 'virbr0'
: Device or resource busy

Version-Release number of selected component (if applicable):

$ rpm -qa | grep virt
libvirt-0.3.3-1.fc8
python-virtinst-0.300.1-1.fc8
virt-manager-0.5.2-1.fc8
virt-viewer-0.0.2-1.fc8
libvirt-python-0.3.3-1.fc8

$ uname -a
Linux dalek 2.6.23-5.fc8 #1 SMP Wed Oct 10 19:25:16 EDT 2007 x86_64 x86_64
x86_64 GNU/Linux

How reproducible:

always

Steps to Reproduce:
1. Install 2 guests with shared networking
2. Start 1st guest
3. Start 2nd guest
  
Actual results:

Second guest does not start

Expected results:

Second guest starts

Additional info:

These are QEMU/KVM guests.

Here's the full backtrace: 

Unable to start virtual machine '<class 'libvirt.libvirtError'>
virDomainCreate() failed Failed to add tap interface 'vnet0' to bridge 'virbr0'
: Device or resource busy
Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/console.py", line 520, in control_vm_run
    self.vm.startup()
  File "/usr/share/virt-manager/virtManager/domain.py", line 377, in startup
    self.vm.create()
  File "/usr/lib64/python2.5/site-packages/libvirt.py", line 228, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: virDomainCreate() failed Failed to add tap interface 'vnet0' to
bridge 'virbr0' : Device or resource busy
'

Comment 1 David Aquilina 2007-11-05 19:16:57 UTC
It seems if you give each guest a unique vnetX device, it works. 

For the benefit of anyone who comes across this: 

virsh --connect qemu:///system dumpxml guest-name > /tmp/guest

Edit /tmp/guest and replace vnet0 with vnet1

virsh --connect qemu:///system define /tmp/guest 



Comment 2 Jan Hutař 2007-11-29 09:59:23 UTC
Seems to me, that when "<target dev='vnet5'/>" is missing, it is determined 
correctly, when I start the system. Am I right?

kernel-2.6.23.1-49.fc8
kvm-36-7.fc8
libvirt-0.3.3-2.fc8
libvirt-python-0.3.3-2.fc8
python-virtinst-0.300.1-3.fc8
qemu-0.9.0-5.fc8
virt-manager-0.5.2-2.fc8

Comment 3 Daniel Berrangé 2007-12-04 15:36:05 UTC
Created attachment 277111 [details]
Strip auto-genereted  vnetXXXX  interfaces

The last libvirt release extended the domain XML to include the <target
dev="vnetXXX"/> device details, so apps can then lookup I/O stats.
Unfortunately, when virt-manager then feeds this XML back into libvirt (eg when
changing a VM config param), this auto-generated vnetXXX device node gets saved
permanently. There is high liklihood that you'll get a clash between two
domains after this has happened a couple of times (depends on exact sequence of
ops in virt-manager).

This patch strips out the auto-generated vnetXXX devices when starting a guest.
If someone would like to this fix, you can apply it to the libvirt source RPM &
rebuild. Be sure to restart libvirtd after installing a rebuilt version.

Comment 4 Daniel Berrangé 2007-12-04 16:57:46 UTC
Created attachment 277161 [details]
Strip autogenerated  vnet target devs

Previous patch was flawed

Comment 5 Daniel Berrangé 2008-04-04 16:05:03 UTC
This is fixed in current F8 updates.