Bug 589436 - virt-manager window does not appear when SSH to KDE box
Summary: virt-manager window does not appear when SSH to KDE box
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: virt-manager
Version: 5.5
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Cole Robinson
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-05-06 07:08 UTC by Thorsten Stärk
Modified: 2016-04-26 14:09 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-02-21 05:59:45 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
strace when virt-manager did not stay open (375.73 KB, text/plain)
2010-05-31 06:43 UTC, Thorsten Stärk
no flags Details
output of df -h (262 bytes, text/plain)
2010-05-31 06:44 UTC, Thorsten Stärk
no flags Details
strace when virt-manager did not stay open (376.00 KB, text/plain)
2010-05-31 06:50 UTC, Thorsten Stärk
no flags Details
strace when virt-manager did stay open (376.00 KB, text/plain)
2010-05-31 06:51 UTC, Thorsten Stärk
no flags Details
strace -f when virt-manager did not stay open (990.87 KB, text/plain)
2010-05-31 06:58 UTC, Thorsten Stärk
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2012:0216 0 normal SHIPPED_LIVE virt-manager bug fix update 2012-02-20 15:08:05 UTC

Description Thorsten Stärk 2010-05-06 07:08:42 UTC
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:

Comment 1 Thorsten Stärk 2010-05-31 06:43:57 UTC
Created attachment 418174 [details]
strace when virt-manager did not stay open

Comment 2 Thorsten Stärk 2010-05-31 06:44:46 UTC
Created attachment 418175 [details]
output of df -h

Comment 3 Thorsten Stärk 2010-05-31 06:50:47 UTC
Created attachment 418178 [details]
strace when virt-manager did not stay open

Comment 4 Thorsten Stärk 2010-05-31 06:51:46 UTC
Created attachment 418179 [details]
strace when virt-manager did stay open

the comment should be "did stay open".

Comment 5 Thorsten Stärk 2010-05-31 06:58:21 UTC
Created attachment 418182 [details]
strace -f when virt-manager did not stay open

Seems the socket does not become writable or readable.

Comment 6 Frank Danapfel 2010-06-10 15:19:05 UTC
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

Comment 7 Dave Wong 2010-06-29 17:48:06 UTC
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.

Comment 8 Dave Wong 2010-07-20 18:20:13 UTC
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

Comment 9 Cole Robinson 2010-08-21 17:52:14 UTC
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.

Comment 10 Frank Danapfel 2010-08-23 09:49:47 UTC
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

Comment 11 Cole Robinson 2010-08-23 14:18:19 UTC
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?

Comment 12 Thorsten Stärk 2010-08-24 09:51:30 UTC
Cole, yes I am using KDE and SSH forwarding.

Comment 13 Thorsten Stärk 2010-08-24 09:59:00 UTC
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.

Comment 14 Frank Danapfel 2010-10-01 11:02:07 UTC
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.

Comment 15 Karl Abbott 2011-08-09 17:36:27 UTC
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

Comment 16 Cole Robinson 2011-10-14 20:42:28 UTC
Okay, I think this upstream commit fixes the issue:

http://git.fedorahosted.org/git/?p=virt-manager.git;a=commit;h=8f90cea9ee97c66850fce4a4fb0b84819c5c2e3c

Comment 17 Cole Robinson 2011-10-14 23:46:12 UTC
Fixed in virt-manager-0.6.1-15.el5

Comment 19 Cole Robinson 2011-10-24 14:12:55 UTC
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.

Comment 20 zhe peng 2011-10-25 08:21:06 UTC
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.

Comment 21 zhe peng 2012-01-11 09:02:57 UTC
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.

Comment 22 Laszlo Ersek 2012-01-11 09:55:54 UTC
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!

Comment 23 Laszlo Ersek 2012-01-11 10:02:55 UTC
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.

Comment 24 errata-xmlrpc 2012-02-21 05:59:45 UTC
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


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