Red Hat Bugzilla – Bug 589436
virt-manager window does not appear when SSH to KDE box
Last modified: 2016-04-26 10:09:44 EDT
Description of problem:
When I type virt-manager, a window pops up, and before I can see what it contains, disappears again. This happens in about 90% of the times. It used to be different (100% virt-manager opened correctly) and I have no clue how to track down the problem. And I have no idea what changed so this happens. Please help me.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. install Red Hat Linux 5.4
2. install virt-manager
3. call virt-manager
no window visible for longer than a second
a window visible for longer than a second
Created attachment 418174 [details]
strace when virt-manager did not stay open
Created attachment 418175 [details]
output of df -h
Created attachment 418178 [details]
strace when virt-manager did not stay open
Created attachment 418179 [details]
strace when virt-manager did stay open
the comment should be "did stay open".
Created attachment 418182 [details]
strace -f when virt-manager did not stay open
Seems the socket does not become writable or readable.
I now did some tests on this issue, and here's what I found:
- this issue only seems to occur when the X display of the RHEL 5 system is forwarded to another host via SSH
- this issue only seems to occur when the remote host is running KDE; if the remote host is running Gnome then the virt-manager window opens and stays in the foreground on the remote host
- I've seen this behavior with the vort-manager from RHEL 5.4 and the one from RHEL 5.5; on RHEL 5.3 virt-manager worked correctly
- also newer virt-manager releases from Fedora don't show this behavior
Also hitting this issue on RHEL 5.5 with the X11 session forwarded to a local RHEL 5.3 system using KDE 3.5 (and RHEL6 with KDE4.3). Usually, if you wait long enough, the virt-manager window does eventually show up. In the past, restarting libvirtd resolved this issue temporarily, but on 5.5 it does not seem to help.
Running virt-manager in debug provided this output:
[root@ ~]# virt-manager --debug --no-dbus --no-fork
2010-06-29 10:32:55,849 INFO Application startup
2010-06-29 10:32:56,041 DEBUG About to connect to uris 
2010-06-29 10:39:28,605 DEBUG Bonding masters are: ['bond0', 'bond1', 'bond2', 'bond3']
2010-06-29 10:39:28,606 DEBUG Adding net device bond0 00:17:a4:77:34:a0 /sys/class/net/bond0 (bridge: None)
2010-06-29 10:39:28,606 DEBUG Checking for VLANs on /sys/class/net/bond0
2010-06-29 10:39:28,607 DEBUG Adding net device bond1 00:17:a4:77:34:a2 /sys/class/net/bond1 (bridge: br1)
2010-06-29 10:39:28,607 DEBUG Checking for VLANs on /sys/class/net/bond1
2010-06-29 10:39:28,607 DEBUG Adding net device bond2 00:17:a4:77:34:a4 /sys/class/net/bond2 (bridge: br2)
2010-06-29 10:39:28,607 DEBUG Checking for VLANs on /sys/class/net/bond2
2010-06-29 10:39:28,608 DEBUG Adding net device bond3 00:17:a4:77:34:a6 /sys/class/net/bond3 (bridge: br3)
2010-06-29 10:39:28,608 DEBUG Checking for VLANs on /sys/class/net/bond3
2010-06-29 10:39:28,609 DEBUG Got physical device /org/freedesktop/Hal/devices/net_00_17_a4_77_34_a0
2010-06-29 10:39:28,611 DEBUG Skipping device eth0 in bonding slave
2010-06-29 10:39:28,611 DEBUG Got physical device /org/freedesktop/Hal/devices/net_00_17_a4_77_34_a2
2010-06-29 10:39:28,613 DEBUG Skipping device eth1 in bonding slave
2010-06-29 10:39:28,614 DEBUG Got physical device /org/freedesktop/Hal/devices/net_00_17_a4_77_34_a4
2010-06-29 10:39:28,615 DEBUG Skipping device eth2 in bonding slave
2010-06-29 10:39:28,616 DEBUG Got physical device /org/freedesktop/Hal/devices/net_00_17_a4_77_34_a6
2010-06-29 10:39:28,617 DEBUG Skipping device eth3 in bonding slave
2010-06-29 10:39:28,618 DEBUG Got physical device /org/freedesktop/Hal/devices/net_00_17_a4_77_34_a8
2010-06-29 10:39:28,620 DEBUG Adding net device eth4 00:17:a4:77:34:a8 /sys/class/net/eth4 (bridge: None)
2010-06-29 10:39:28,620 DEBUG Checking for VLANs on /sys/class/net/eth4
2010-06-29 10:39:28,620 DEBUG Got physical device /org/freedesktop/Hal/devices/net_00_17_a4_77_34_aa
2010-06-29 10:39:28,622 DEBUG Adding net device eth5 00:17:a4:77:34:aa /sys/class/net/eth5 (bridge: None)
2010-06-29 10:39:28,623 DEBUG Checking for VLANs on /sys/class/net/eth5
2010-06-29 10:39:28,623 DEBUG Got physical device /org/freedesktop/Hal/devices/net_00_17_a4_77_34_ac
2010-06-29 10:39:28,625 DEBUG Adding net device eth6 00:17:a4:77:34:ac /sys/class/net/eth6 (bridge: None)
2010-06-29 10:39:28,625 DEBUG Checking for VLANs on /sys/class/net/eth6
2010-06-29 10:39:28,626 DEBUG Got physical device /org/freedesktop/Hal/devices/net_00_17_a4_77_34_ae
2010-06-29 10:39:28,628 DEBUG Adding net device eth7 00:17:a4:77:34:ae /sys/class/net/eth7 (bridge: None)
2010-06-29 10:39:28,628 DEBUG Checking for VLANs on /sys/class/net/eth7
2010-06-29 10:39:28,665 DEBUG window counter incremented to 1
2010-06-29 10:39:28,687 DEBUG Scheduling background open thread for qemu:///system
2010-06-29 10:39:28,687 DEBUG Background thread is running
2010-06-29 10:39:28,688 DEBUG Background open thread complete, scheduling notify
2010-06-29 10:39:28,700 DEBUG Notifying open result
Notice from the time it shows attempting to connect to uri to determining the underlying networking was almost 7 minutes. We've seen this time vary from a few minutes to well over 30 on some hosts.
It appears that this is somewhat related to the hal/dbus subsystem. Prior to running virt-manager, if I run lshal and it hangs, it's guaranteed that virt-manager will also hang. If I stop haldaemon, set it's child-timeout to 600, and restart, lshal usually works, and then so does virt-manager. This is on HP BL495c systems with lots of FC luns from EVA and XP arrays, so it's possibly related to https://bugzilla.redhat.com/show_bug.cgi?id=511935
Hmm, Dave, that might be a separate issue, it makes sense that if HAL is taking forever, virt-manager blocks.
Can Frank or Thorsten provide the output of virt-manager --no-fork --debug? Does the process hang or start up and quickly go away? Does the --no-dbus option help at all? That info should confirm if you are seeing Dave's issue or a separate one.
Here's the virt-manager debug output from one of my RHEL 5 systems:
[user@Fedora13 ~]# ssh -X root@RHEL5
Last login: Fri Aug 20 16:44:21 2010 from Fedora13
[root@RHEL5 ~]# virt-manager --no-fork --debug
2010-08-23 10:38:23,619 INFO Application startup
2010-08-23 10:38:23,908 DEBUG About to connect to uris ['qemu:///system']
2010-08-23 10:38:23,915 DEBUG Bonding masters are: 
2010-08-23 10:38:23,916 DEBUG Got physical device /org/freedesktop/Hal/devices/net_00_15_17_bf_00_f6
2010-08-23 10:38:23,920 DEBUG Adding net device eth2 00:15:17:bf:00:f6 /sys/class/net/eth2 (bridge: None)
2010-08-23 10:38:23,920 DEBUG Checking for VLANs on /sys/class/net/eth2
2010-08-23 10:38:23,921 DEBUG Got physical device /org/freedesktop/Hal/devices/net_00_15_17_bf_00_f7
2010-08-23 10:38:23,925 DEBUG Adding net device eth3 00:15:17:bf:00:f7 /sys/class/net/eth3 (bridge: None)
2010-08-23 10:38:23,925 DEBUG Checking for VLANs on /sys/class/net/eth3
2010-08-23 10:38:23,926 DEBUG Got physical device /org/freedesktop/Hal/devices/net_00_19_99_67_82_b0
2010-08-23 10:38:23,930 DEBUG Adding net device eth0 00:19:99:67:82:b0 /sys/class/net/eth0 (bridge: br0)
2010-08-23 10:38:23,930 DEBUG Checking for VLANs on /sys/class/net/eth0
2010-08-23 10:38:23,931 DEBUG Got physical device /org/freedesktop/Hal/devices/net_00_19_99_67_82_b1
2010-08-23 10:38:23,934 DEBUG Adding net device eth1 00:19:99:67:82:b1 /sys/class/net/eth1 (bridge: None)
2010-08-23 10:38:23,935 DEBUG Checking for VLANs on /sys/class/net/eth1
2010-08-23 10:38:23,966 DEBUG window counter incremented to 1
2010-08-23 10:38:24,015 DEBUG Scheduling background open thread for qemu:///system
2010-08-23 10:38:24,016 DEBUG Background thread is running
2010-08-23 10:38:24,017 DEBUG Background open thread complete, scheduling notify
2010-08-23 10:38:24,039 DEBUG Notifying open result
2010-08-23 10:38:24,046 DEBUG About to append vm: VM1
2010-08-23 10:38:24,047 DEBUG About to append vm: VM2
2010-08-23 10:38:24,048 DEBUG VM VM1 started
2010-08-23 10:38:24,048 DEBUG VM VM2 started
Frank, just to confirm, in that case the virt-manager window did not appear?
Dave, sounds like your issue is a different problem. Can you file a new bug report, something like "virt-manager startup blocked by HAL slowness".
Thorsten, are you using KDE or SSH forwarding like Frank mentions in Comment #6?
Cole, yes I am using KDE and SSH forwarding.
Cole, virt-manager works again for me with KDE so I do not test if it works with gnome. I started virt-manager 10 times subsequently and it always worked.
Cole, sorry for the late reply. I overlooked your question to me in comment #11 :-(
When I didd the test I mentinoned in comment #10, the virt-manager window did appear, but was immediately minimized and put in the background. This only happens with the virt-manager from RHEL 5.4 and 5.5, the RHEL 5.3 and RHEL 6 virt-manager doesn't show this behavior.
Setting the flag to RHEL 5.8 as we didn't have a flagged release. What is the possibility of getting this addressed in RHEL 5.8?
Okay, I think this upstream commit fixes the issue:
Fixed in virt-manager-0.6.1-15.el5
How I reproduced:
F14 desktop w/ Gnome
RHEL5.7 server w/ Gnome
- On desktop, booted a Fedora 15 KDE Live CD guest.
- From Live CD guest, ssh -X to rhel5.7 gnome server
- run virt-manager
- About half the runs of virt-manager flash a window and don't show up.
hi cole, thanks your help, by your step,i can reproduce this bug on virt-manager-0.6.1-14.el5.
1: on my desktop(fedora 14),create a Fedora 15 KDE live CD guest
2: login fedora15 guest and ssh -X to rhel5.7 gnome server
3: run #virt-manager
the virt-manager can launch normally,no error occur ,the virt-manager main page will show up ,can start/stop guest.
verify on virt-manager-0.6.1-16.el5
step same with comment 20
can someone please check if bug 769419 is a plausible duplicate?
Additionally, I run IceWM (not KDE or GNOME) on the X Server where I forward the virt-manager windows to, and I also miss the window borders when the windows are initially mapped. If I restart IceWM (it can reexec itself), then the windows are remapped, this time with borders. Comment 19 describes something very similar.
- window borders are back on initial mapping under IceWM (thanks a lot!)
- Icon transparency (alpha channel) is still lost, so bug 769419 is not a dup.
Thanks for fixing this bug; the missing borders (and the dependent WM functionality) was pretty distracting.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.