Bug 333221 - Unable to run more than 1 guest simultaneously
Unable to run more than 1 guest simultaneously
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Berrange
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-10-15 18:01 EDT by David Aquilina
Modified: 2014-06-23 20:14 EDT (History)
3 users (show)

See Also:
Fixed In Version: 0.4.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-04-04 12:05:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Strip auto-genereted vnetXXXX interfaces (2.08 KB, patch)
2007-12-04 10:36 EST, Daniel Berrange
no flags Details | Diff
Strip autogenerated vnet target devs (1.63 KB, patch)
2007-12-04 11:57 EST, Daniel Berrange
no flags Details | Diff

  None (edit)
Description David Aquilina 2007-10-15 18:01:09 EDT
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

$ 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:


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
  File "/usr/share/virt-manager/virtManager/domain.py", line 377, in startup
  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 14:16:57 EST
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 04:59:23 EST
Seems to me, that when "<target dev='vnet5'/>" is missing, it is determined 
correctly, when I start the system. Am I right?

Comment 3 Daniel Berrange 2007-12-04 10:36:05 EST
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 Berrange 2007-12-04 11:57:46 EST
Created attachment 277161 [details]
Strip autogenerated  vnet target devs

Previous patch was flawed
Comment 5 Daniel Berrange 2008-04-04 12:05:03 EDT
This is fixed in current F8 updates.

Note You need to log in before you can comment on or make changes to this bug.