Bug 589436
| Summary: | virt-manager window does not appear when SSH to KDE box | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Thorsten Stärk <thorsten.staerk> | ||||||||||||
| Component: | virt-manager | Assignee: | Cole Robinson <crobinso> | ||||||||||||
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> | ||||||||||||
| Severity: | medium | Docs Contact: | |||||||||||||
| Priority: | medium | ||||||||||||||
| Version: | 5.5 | CC: | david_wong, fdanapfe, kabbott, lersek, mzhan, rwu, xen-maint, zpeng | ||||||||||||
| Target Milestone: | rc | ||||||||||||||
| Target Release: | --- | ||||||||||||||
| Hardware: | All | ||||||||||||||
| OS: | Linux | ||||||||||||||
| Whiteboard: | |||||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||
| Clone Of: | Environment: | ||||||||||||||
| Last Closed: | 2012-02-21 05:59:45 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: | |||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
Thorsten Stärk
2010-05-06 07:08:42 UTC
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 |