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): How reproducible: Steps to Reproduce: 1. install Red Hat Linux 5.4 2. install virt-manager 3. call virt-manager Actual results: no window visible for longer than a second Expected results: a window visible for longer than a second Additional info:
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 root@RHEL5's password: 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? Cheers, Karl
Okay, I think this upstream commit fixes the issue: http://git.fedorahosted.org/git/?p=virt-manager.git;a=commit;h=8f90cea9ee97c66850fce4a4fb0b84819c5c2e3c
Fixed in virt-manager-0.6.1-15.el5
How I reproduced: Machines: 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. verify with: virt-manager-0.6.1-15.el5 python-virtinst-0.400.3-13.el5 kernel-2.6.18-274.el5 step: 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. verification passed.
verify on virt-manager-0.6.1-16.el5 Verify with: kernel-2.6.18-303.el5 virt-manager-0.6.1-16.el5 python-virtinst-0.400.3-13.el5 step same with comment 20 verification passed.
Hello all, 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. Thanks!
Tested: - python-virtinst-0.400.3-13.el5 - virt-manager-0.6.1-16.el5 Results: - 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. http://rhn.redhat.com/errata/RHBA-2012-0216.html