Bug 440998 - virt manager create new machine using bridging device presents empty bridging dropdown
virt manager create new machine using bridging device presents empty bridging...
Product: Fedora
Classification: Fedora
Component: virt-manager (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Berrange
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-04-04 17:16 EDT by Michael Gregg
Modified: 2014-08-05 07:18 EDT (History)
1 user (show)

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

Attachments (Terms of Use)

  None (edit)
Description Michael Gregg 2008-04-04 17:16:32 EDT
Description of problem:
virt-manager on a system with kvm and qemu. When I create a new vm, the dropdown
listing bridging devices is empty.

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

How reproducible:

Steps to Reproduce:
1.install virt-manager, kvm, quem
2. set up a bridging device for eth0 of peth0
3. create a new machine in virt-manager
Actual results:
The bridging interface is empty when trying to create a new VM.

Expected results:
eth0(peth0) to come up as a available bridging interface

Additional info:
I've got a patch that corrects this problem!
It's a change to: /usr/share/virt-manager/virtManager/connection.py
The diff is actually a bit of a tweak from:

--- /root/connection.py 2008-04-04 11:11:58.000000000 -0700
+++ /usr/share/virt-manager/virtManager/connection.py   2008-04-04
12:07:45.000000000 -0700
@@ -160,19 +160,20 @@
             self.hal_iface = None
     def _device_added(self, path):
         obj = self.bus.get_object("org.freedesktop.Hal", path)
-        if obj.QueryCapability("net"):
-            name = obj.GetPropertyString("net.interface")
-            mac = obj.GetPropertyString("net.address")
+        obj_if = dbus.Interface(obj, 'org.freedesktop.Hal.Device')
+        if obj_if.QueryCapability("net"):
+            name = obj_if.GetPropertyString("net.interface")
+            mac = obj_if.GetPropertyString("net.address")
             # Now magic to determine if the device is part of a bridge
             shared = False
             bridge = None
                 # XXX Linux specific - needs porting for other OS - patches
                 # welcomed...
-                sysfspath = obj.GetPropertyString("linux.sysfs_path")
+                sysfspath = obj_if.GetPropertyString("linux.sysfs_path")
                 # If running a device in bridged mode, there's a reasonable
                 # chance that the actual ethernet device has been renamed to
                 # something else. ethN -> pethN
Comment 1 Michael Gregg 2008-04-04 17:53:07 EDT
For reference I was getting this problem with dbus-1.1.2-9.fc8 installed.

So this doesn't seem to be a duplicate of: 435506
Comment 2 Daniel Berrange 2008-04-08 16:34:23 EDT
Urm, are you sure you have  virt-manager-0.5.3-2.fc8  installed ?

The patch you reference is already included in 0.5.3-2.fc8 in the file:


* Mon Mar 19 2008 Daniel P. Berrange <berrange@redhat.com> - 0.5.3-2.fc8
- Fix cdrom media connect
- Fix default Xen hypervisor URI
- Fix DBus calls to use an explicit interface (rhbz #435506)
- Fix adding blktap disk to PV guest via addhardware wizard
- Fix adding shared network devices via addhardware wizard
Comment 3 Michael Gregg 2008-04-09 21:22:54 EDT

Yes, I'm sure:

rpm -qa virt-manager

I had done a yum upgrade from a older version(virt-manager-0.5.3-1.fc8). Would
the patch not get applied?

I just checked:

It appears to have this patch. 

I just installed a new machine, it's got the patch.
I'm not sure my system had a problem with that upgrade. 

I'm satisfied that this bug is closed now.

Comment 4 Cole Robinson 2008-05-07 13:47:10 EDT
Closing WORKSFORME per reporters request.

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