Description of problem: After a Long Period of inactivity (overnight ~15hrs) the Virt-Viewer Will No Longer Display the VM. Keys are still sent the VM, but a black screen is displayed. I tried sending Ctrl Alt F1 to go to text mode, after closing the session, and bringing up another session, the VM is displayed and is in text mode. Version-Release number of selected component (if applicable): Client Windows 7: mingw-virt-viewer-0.5.6-6.el6_4 Host: RHEL6.5Snap1(RHEL6.5-20130925.2) spice-server-0.12.4-3.el6.x86_64 qemu-kvm-0.12.1.2-2.406.el6.x86_64 libvirt-0.10.2-27.el6.x86_64 Guest: RHEL6.5Snap1(RHEL6.5-20130925.2) How reproducible: 100% (reproduced it 2 days in a row) Steps to Reproduce: 1. connect to a VM using mingw-virt-viewer 2. leave it inactive for a long period 3. after the inactivity period, attempt to use the virt-viewer. Actual results: Client is just displays a black screen. Expected results: Client should respond as before you left unfocused. Additional info:
could you get the SPICE_DEBUG=1 and spice server log? Can you take a screenshot of the "black screen" state or is it really just black? is the vm suspended when the screen is black? can you reproduce with rhel client?
I tried to reproduce this issue with a RHEL client, and this issue does not occur on a RHEL client, it is a mingw-virt-viewer issue only. When the screen is black, the vm is in a suspend/hibernate state to start, but after sending keys or clicking on it, the display should be shown; however, the screen stays black and the keys are sent to the machine, as can be seen by remote-viewer logs with --spice-debug: (remote-viewer.exe:3880): GSpice-DEBUG: ../../gtk/spice-channel-cache.h:108 cache_add: image f64364dc ( 21) (remote-viewer.exe:3880): GSpice-DEBUG: ../../gtk/decode-glz.c:372 decode_header: 256x1, id 16, ref 0 (remote-viewer.exe:3880): GSpice-DEBUG: ../../gtk/decode-glz.c:94 glz_decoder_window_resize: array resi ze 16 -> 32 (remote-viewer.exe:3880): GSpice-DEBUG: ../../gtk/spice-channel-cache.h:92 cache_find: image 851618f1 [ not found] (remote-viewer.exe:3880): GSpice-DEBUG: ../../gtk/spice-channel-cache.h:108 cache_add: image 851618f1 ( 22) (remote-viewer.exe:3880): GSpice-DEBUG: ../../gtk/decode-glz.c:372 decode_header: 1024x768, id 17, ref 0 (remote-viewer.exe:3880): GSpice-DEBUG: ../../gtk/spice-channel-cache.h:92 cache_find: image 7949391d [ not found] (remote-viewer.exe:3880): GSpice-DEBUG: ../../gtk/spice-channel-cache.h:108 cache_add: image 7949391d ( 23) (remote-viewer.exe:3880): GSpice-DEBUG: ../../gtk/win-usb-dev.c:358 number of current devices 3, I know about 3 devices (remote-viewer.exe:3880): GSpice-DEBUG: ../../gtk/channel-cursor.c:354 cursor-4:0: set_cursor: flags 0, size 2304 (remote-viewer.exe:3880): GSpice-DEBUG: ../../gtk/channel-cursor.c:360 cursor-4:0: set_cursor: type 0, 0, 24x24 (remote-viewer.exe:3880): GSpice-DEBUG: ../../gtk/channel-cursor.c:354 cursor-4:0: set_cursor: flags 0, size 2304 (remote-viewer.exe:3880): GSpice-DEBUG: ../../gtk/channel-cursor.c:360 cursor-4:0: set_cursor: type 0, 0, 24x24 (remote-viewer.exe:3880): GSpice-DEBUG: ../../gtk/channel-cursor.c:354 cursor-4:0: set_cursor: flags 0, size 2304 (remote-viewer.exe:3880): GSpice-DEBUG: ../../gtk/channel-cursor.c:360 cursor-4:0: set_cursor: type 0, 0, 24x24 (remote-viewer.exe:3880): GSpice-DEBUG: ../../gtk/spice-util.c:233 spice_make_scancode: scancode 29 (remote-viewer.exe:3880): GSpice-DEBUG: ../../gtk/spice-util.c:233 spice_make_scancode: scancode 56 (remote-viewer.exe:3880): GSpice-DEBUG: ../../gtk/spice-util.c:233 spice_make_scancode: scancode 339 (remote-viewer.exe:3880): GSpice-DEBUG: ../../gtk/spice-util.c:233 spice_make_scancode: release scancod e 339 (remote-viewer.exe:3880): GSpice-DEBUG: ../../gtk/spice-util.c:233 spice_make_scancode: release scancod e 56 (remote-viewer.exe:3880): GSpice-DEBUG: ../../gtk/spice-util.c:233 spice_make_scancode: release scancod e 29 (remote-viewer.exe:3880): GSpice-DEBUG: ../../gtk/channel-cursor.c:354 cursor-4:0: set_cursor: flags 0, size 2304 (remote-viewer.exe:3880): GSpice-DEBUG: ../../gtk/channel-cursor.c:360 cursor-4:0: set_cursor: type 0, 0, 24x24 (remote-viewer.exe:3880): GSpice-DEBUG: ../../gtk/channel-cursor.c:354 cursor-4:0: set_cursor: flags 0, size 2304 (remote-viewer.exe:3880): GSpice-DEBUG: ../../gtk/channel-cursor.c:360 cursor-4:0: set_cursor: type 0, 0, 24x24 (remote-viewer.exe:3880): GSpice-DEBUG: ../../gtk/channel-cursor.c:354 cursor-4:0: set_cursor: flags 0, size 2304 (remote-viewer.exe:3880): GSpice-DEBUG: ../../gtk/channel-cursor.c:360 cursor-4:0: set_cursor: type 0, 0, 24x24 (remote-viewer.exe:3880): GSpice-DEBUG: ../../gtk/channel-cursor.c:354 cursor-4:0: set_cursor: flags 0, size 2304 (remote-viewer.exe:3880): GSpice-DEBUG: ../../gtk/channel-cursor.c:360 cursor-4:0: set_cursor: type 0, 0, 24x24 (remote-viewer.exe:3880): GSpice-DEBUG: ../../gtk/spice-util.c:233 spice_make_scancode: scancode 29 (remote-viewer.exe:3880): GSpice-DEBUG: ../../gtk/spice-util.c:233 spice_make_scancode: scancode 56 (remote-viewer.exe:3880): GSpice-DEBUG: ../../gtk/spice-util.c:233 spice_make_scancode: scancode 59 (remote-viewer.exe:3880): GSpice-DEBUG: ../../gtk/spice-util.c:233 spice_make_scancode: release scancod e 59 (remote-viewer.exe:3880): GSpice-DEBUG: ../../gtk/spice-util.c:233 spice_make_scancode: release scancod e 56 (remote-viewer.exe:3880): GSpice-DEBUG: ../../gtk/spice-util.c:233 spice_make_scancode: release scancod e 29 (remote-viewer.exe:3880): GSpice-DEBUG: ../../gtk/channel-cursor.c:354 cursor-4:0: set_cursor: flags 0, size 2304 (remote-viewer.exe:3880): GSpice-DEBUG: ../../gtk/channel-cursor.c:360 cursor-4:0: set_cursor: type 0, 0, 24x24 (remote-viewer.exe:3880): GSpice-DEBUG: ../../gtk/channel-cursor.c:354 cursor-4:0: set_cursor: flags 0, size 2304 (remote-viewer.exe:3880): GSpice-DEBUG: ../../gtk/channel-cursor.c:360 cursor-4:0: set_cursor: type 0, 0, 24x24 I am attaching the screenshot, and I will send the spice-server log, after I reproduce it one more time (I forgot to set SPICE_DEBUG=1).
Created attachment 811314 [details] screenshot of remote-viewer after inactivity
Created attachment 812131 [details] SPICE_DEBUG=1 server log
After retesting, the period of inactivity only needs to be a little bit over an hour.
The client receives error code 16 on channels, which is HUP. It starts with input channel if you just type, but trying to resize the window will try sending on main channel and get HUP as well, and close the client. Are you testing the client within a VM?
This is quite annoying, I can't reproduce it on my rhel with a LAN, but it happens with your server. Do you have a special switch before it? I will try with a different VM from our QA instances.
Hi Marc-Andre, I brought it up with VirtManager, the only thing, which may be a little different is that I modified the xml for the usb support, but everything else is default spice settings from VirtManager: /usr/libexec/qemu-kvm -name RHEL6.5Snap3 -S -M rhel6.5.0 -enable-kvm -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid cce322f5-a4f5-2b60-0d98-a0433cff19ca -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/RHEL6.5Snap3.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x9.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x9 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x9.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x9.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x7 -drive file=/home/test/IMAGES/RHEL6.5Snap3,if=none,id=drive-virtio-disk0,format=raw,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=23,id=hostnet0,vhost=on,vhostfd=24 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:a1:b8:63,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0 -spice port=5900,addr=0.0.0.0,disable-ticketing,seamless-migration=on -vga qxl -global qxl-vga.ram_size=67108864 -global qxl-vga.vram_size=67108864 -device qxl,id=video1,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x8 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=3 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=4 -chardev spicevmc,id=charredir2,name=usbredir -device usb-redir,chardev=charredir2,id=redir2,bus=usb.0,port=5 -chardev spicevmc,id=charredir3,name=usbredir -device usb-redir,chardev=charredir3,id=redir3,bus=usb.0,port=6 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6
Although I could reproduce on Vimal host, i can't on LAN (or on QA setup) Vimal, could you try running a Win7 VM on the same host, and connecting a client within that VM to the RHEL6 VM? (when I said "switch" in comment #8, I was refering to a network switch. On Vimal host, the server doesn't receive any event, and the client either. So I suspect something else in the network "breaking" the connection.
Hi Marc-Andre, I don't think its a network issue. There is no special switch that the host is connected to, and when I do the test, the host and client are connected to the same switch. I had this setup for a while and we do the inactivity test often, and I haven't seen any issues in the past. I di create a Win7 VM installed virt-manager connected to the same host, and after a long period of inactivity the VM was being displayed properly, so I was unable to reproduce in that environment.
(In reply to Vimal Patel from comment #11) > Hi Marc-Andre, > > I don't think its a network issue. There is no special switch that the host > is connected to, and when I do the test, the host and client are connected > to the same switch. I had this setup for a while and we do the inactivity > test often, and I haven't seen any issues in the past. > > I di create a Win7 VM installed virt-manager connected to the same host, and > after a long period of inactivity the VM was being displayed properly, so I > was unable to reproduce in that environment. thanks, then we have something else on host (or network) breaking the connection. I am running out of ideas. Could you try reproducing with a different host machine? (since you have a working and non-working case, you should be able to eliminate the differences to find the cause)
(adding bug 1027244 as dep, it could eventually help debugging this)
I'd propose moving severity to low, and to 3.4. It is probably not a major issue if after 1h of inactivity the user has to reconnect to a remote VM. And in this case it very much looks like a network stack issue. So, the bug has been difficult to reproduce (bug 1027244 could help). It would be nice if someone from QA in a different office could try to reproduce (with a different host network). If the solution is found quickly enough, it would be nice to have in -z though.
In RHEV 3.3 is24.2, I am seeing this issue on a RHEL client. So, it's probably not a mingw-virt-viewer issue, but a spice-server issue? Not sure if the spice-server log of the VM is needed, it is basically the same as the one attached. Setup: Client: RH 6.5 i386 client Virt Viewer 0.5.6 Guest: RH6.5 x86_64 guest Host: RHEL 6.5 host spice-server-0.12.4-6.el6.x86_64 qemu-kvm-rhev-0.12.1.2-2.414.el6.x86_64
This bug couldn't be reproduced so far. Vimal, do you have a Windows client machine I could connect to via RDP to do some debugging? Access to the host would also be helpful. thanks
closing as missing data to reproduce Most likely, this is a squid issue with read_timeout, see also dup bug #1094766
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days