Bug 440998

Summary: virt manager create new machine using bridging device presents empty bridging dropdown
Product: [Fedora] Fedora Reporter: Michael Gregg <mgregg>
Component: virt-managerAssignee: Daniel Berrangé <berrange>
Status: CLOSED WORKSFORME QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 8CC: hbrock
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-05-07 17:47:10 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:

Description Michael Gregg 2008-04-04 21:16:32 UTC
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):
virt-manager-0.5.3-2.fc8

How reproducible:
always

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:
http://bugs.centos.org/view.php?id=2516

--- /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
             try:
                 # 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 21:53:07 UTC
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 Berrangé 2008-04-08 20:34:23 UTC
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:


virt-manager-0.5.3-dbus-interface.patch

* Mon Mar 19 2008 Daniel P. Berrange <berrange> - 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-10 01:22:54 UTC

Yes, I'm sure:

rpm -qa virt-manager
virt-manager-0.5.3-2.fc8

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:
http://download.fedora.redhat.com/pub/fedora/linux/updates/8/SRPMS/virt-manager-0.5.3-2.fc8.src.rpm

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.

Thanks!

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