Bug 214700 - virt-manager unable to create domain due to wrong bridge device
Summary: virt-manager unable to create domain due to wrong bridge device
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: python-virtinst
Version: 6
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-11-08 21:39 UTC by Oldrich Plchot
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version: python-virtinst-0.98.0-1.fc6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-03-21 22:08:59 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Oldrich Plchot 2006-11-08 21:39:14 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20061027 Fedora/1.5.0.7-8.fc6 Firefox/1.5.0.7

Description of problem:
Whe I wanted to install guest fc6 into my fc6 box virt-manager failed to create the domain. I found out, he expected xenbr0. I did cat /var/log/xen/xend-debug.log and it said xenbr0 does not exist! Then I ran ifconfig and found out there was xenbr1 created because I was using eth1 card (eth0 is disabled now). When I disabled eth1 and set up eth0 to activate on startup, I was able to create a domain and start installing the system.

Version-Release number of selected component (if applicable):
libvirt-0.1.7-2, virt-manager-0.2.3-2.fc6

How reproducible:
Always


Steps to Reproduce:
1.have more eth cards
2.disable eth0, enable eth1, dhclient eth1
3.run virt-manager and try to create a guest system 
4. full virtualization or paravirtualization both fails

Actual Results:
Virt manager stopped after an error. 

Expected Results:
virt-manager creates domain, which boots and installs normally

Additional info:
[root@Pentium4 fedora1]# lspci
00:00.0 Host bridge: Intel Corporation 82945G/GZ/P/PL Memory Controller Hub (rev 81)
00:01.0 PCI bridge: Intel Corporation 82945G/GZ/P/PL PCI Express Root Port (rev 81)
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01)
00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 01)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev 01)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev 01)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev 01)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 (rev 01)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1)
00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01)
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 01)
00:1f.2 IDE interface: Intel Corporation 82801GB/GR/GH (ICH7 Family) Serial ATA Storage Controller IDE (rev 01)
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01)
01:00.0 VGA compatible controller: nVidia Corporation G70 [GeForce 7600 GS] (rev a1)
04:00.0 Ethernet controller: D-Link System Inc RTL8139 Ethernet (rev 10)
04:01.0 Ethernet controller: D-Link System Inc RTL8139 Ethernet (rev 10)
04:03.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80)
04:04.0 IDE interface: VIA Technologies, Inc. VT6410 ATA133 RAID controller (rev 06)


[root@Pentium4 fedora1]# cat /proc/cpuinfo 
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 6
model name      : Intel(R) Pentium(R) D CPU 3.20GHz
stepping        : 4
cpu MHz         : 3215.958
cache size      : 2048 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 6
wp              : yes
flags           : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl vmx est cid cx16 xtpr lahf_lm
bogomips        : 8043.49

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 15
model           : 6
model name      : Intel(R) Pentium(R) D CPU 3.20GHz
stepping        : 4
cpu MHz         : 3215.958
cache size      : 2048 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 6
wp              : yes
flags           : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc up pni monitor ds_cpl vmx est cid cx16 xtpr lahf_lm
bogomips        : 8043.49

[root@Pentium4 fedora1]# uname -a
Linux Pentium4 2.6.18-1.2798.fc6xen #1 SMP Mon Oct 16 15:11:19 EDT 2006 i686 i686 i386 GNU/Linux

Comment 1 Daniel Berrangé 2006-12-07 22:42:00 UTC
This is really a bug in python-virtinst. The new versions of that package
automatically detect correct  bridge device to use. Need to push an update  to
latest python-virtinst to FC6 updates repository.


Comment 2 Daniel Berrangé 2007-03-21 15:15:45 UTC
Current python-virtinst-0.98.0-1.fc6 & virt-manager-0.2.6-3.fc6  packages in FC6
updates now auto-detect the bridge device. Please re-test to confirm



Comment 3 Oldrich Plchot 2007-03-21 17:12:22 UTC
Hello again,
  the new updatet packages works well and correctly detects xenbr1. I was able
to install a guest system without any major problems. I have latest fedora updates:

[olda@Pentium4 ~]$ rpm -qa | grep "\(virt\|xen\)"
python-virtinst-0.98.0-1.fc6
kernel-xen-2.6.19-1.2911.6.5.fc6
kmod-ntfs-xen-2.1.27-3.2.6.19_1.2911.6.4.fc6
libvirt-python-0.2.0-2.fc6
virt-manager-0.2.6-3.fc6
kernel-xen-2.6.19-1.2911.6.4.fc6
xen-3.0.3-8.fc6
xen-libs-3.0.3-8.fc6
libvirt-0.2.0-2.fc6
kmod-ntfs-xen-2.1.27-3.2.6.19_1.2911.6.5.fc6
kmod-nvidia-xen-1.0.9755-2.2.6.19_1.2911.6.5.fc6

I had only a little problem because I do not activate eth1 automaticly at the
startup, so when I disabled eth0 xenbr0 vif, enabled eth1 and ran dhclient the
xenbr1 interface was not created. Virt-manager does not create it, I had to
reboot with eth1 enabled and cable plugged in. Then all the interfaces were
created correctly and virt-manager did not complain. Maybe virt-manager could
try to create these interfaces when he does not find them. But this would be a
feature request. The problem I reportet seems to be solved.

Thanks,
        Oldrich Plchot

Comment 4 Daniel Berrangé 2007-03-21 22:08:59 UTC
Virt-manager can't create the interfaces itself because doing so potentially
disrupts networking. In future though there will be an alternative to bridging
which is managed by virt-manager - you'll be able to create virtual networks and
connect them to the LAN with NAT.



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