My host OS is Arch GNU/Linux on x86-64, running qemu/kvm with guest OS windows 8.1 (64 bits OS). Frequently I get (usually at boot, but happens also when running applications): SpiceWorker-Warning **: red_worker.c:163:rendering_incorrect: rendering incorrect from now on: get_drawable SpiceWorker-Warning **: red_worker.c:163:rendering_incorrect: rendering incorrect from now on: failed to get_drawable Once I get this, on virt-viewer there's nothing else but a blank screen. Stopping and starting virt-viewer dos not help. The only solution is to reboot the VM through the qemu monitor with "system_reset". Really bad, cause rebooting windows on a VM is not a fast process at all. Besides the risk of corrupting anything with "system_reset". At times I have to do that like 5 times in a row, :-( I guessed this would be the spice server, but I have no clue. It can be located some other place where fitting better...
Forgot to mention that I'm using: spice 0.12.6 spice-guest-tools-windows 0.100 virtio-win 0.1.112.1 win8.1-x86-64 qxlod driver 22.33.46.473 All this was working fine some time ago. Might be a windows update or something... Although I usually keep up to date the virtio drivers, the qxlod hadn't changed for quite a while...
Hi, Thanks for taking time to report this bug. A few questions/requests in order to understand the problem: - Could you provide the qemu command line that you are using? - The client logs could be useful as well (remote-viewer --spice-debug ...) - Which qxlod driver is this one that you are using? We don't have any supported video drivers for windows 8+ - You could also test with VNC and/or with video as VGA to check if you can reproduce this.
Weird, I didn't see your post on my gmail inbox, :-( Sorry about that. Before attending you request, I moved to win10, to see if there was a difference, but it's exactly the same. It's become more uncomfortable given i have to hard do "system_reset" on teh qemu monitor regularly. That was true on win 8.1, and now on win 10. The command line I'm using for qemu (good given I use command line): qemu-system-x86_64 -enable-kvm -name win-10-coe -machine type=pc,accel=kvm -cpu host -smp cores=1,threads=2,sockets=1 -m 2.7G -balloon virtio -drive file=/home/vasqueja/.qemu/imgs/win10-coe.qcow2,index=0,media=disk,if=virtio -drive file=/usr/share/virtio/virtio-win.iso,index=1,media=cdrom -drive file=/usr/share/spice-guest-tools/spice-guest-tools.iso,index=2,media=cdrom -net nic,model=virtio -net tap,ifname=tap0,script=no,downscript=no,vhost=on -usbdevice tablet -usb -display none -vga qxl -device virtio-serial-pci -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 -chardev spicevmc,id=spicechannel0,name=vdagent -soundhw ac97 -rtc base=localtime -usbdevice host:0b0e:0032 -usbdevice host:0b0e:0348 -monitor stdio -k es -spice port=5930,disable-ticketing,addr=::1 The man qemu shows a "virtio" vga, but I haven't seen it compiled for windows yet, neither I know if it would integrate with spice... Might have better performance though, but can't test on win client yet. That said, the qxlod driver I'm using is provided by the virtio-win ISO from RH, and other than this spice issue, it seems to work quite well on sdl mode... BTW, I'm using right now the virtio-win ISO from RH: virtio-win 0.1.113.1 That added support to win10 some time back. The clients I've attempted, and both failed: virtviewer 3.0 -> virt-viewer spice-gtk3 0.30 -> spice-gtk3 According to the qxl[od] driver properties in win: Version: 22.33.46.473 Date: 28/7/2015 Provider: Red Hat. Inc. I'll look if wehther virt-viewer or spicy offers debug capabilities...
Created attachment 122527 [details] log for verbose and debug output of remote-viewer
OK, I'm using remote-viewer from the same virt-viewer package. The command line for the already attached log: % remote-viewer -v --debug spice://localhost:5930 |& tee remote-viewer.log The relevant part of the log: ++++ (remote-viewer:10838): GSpice-WARNING **: Warning no automount-inhibiting implementation available (remote-viewer:10838): virt-viewer-DEBUG: Allocated 1600x900 (remote-viewer:10838): virt-viewer-DEBUG: Child allocate 1600x900 (remote-viewer:10838): virt-viewer-DEBUG: notebook show status 0x1fc6200 (remote-viewer:10838): virt-viewer-DEBUG: notebook show display 0x1fc6200 (remote-viewer:10838): virt-viewer-DEBUG: Allocated 1760x990 (remote-viewer:10838): virt-viewer-DEBUG: Child allocate 1760x990 (remote-viewer:10838): virt-viewer-DEBUG: Destroying spice display 0x1f61df0 (remote-viewer:10838): virt-viewer-DEBUG: Not removing main window 0 0x1fc5120 (remote-viewer:10838): virt-viewer-DEBUG: Destroy SPICE channel SpiceInputsChannel 0 (remote-viewer:10838): virt-viewer-DEBUG: Destroy SPICE channel SpiceDisplayChannel 0 (remote-viewer:10838): virt-viewer-DEBUG: zap display channel (#0) (remote-viewer:10838): virt-viewer-DEBUG: Destroy SPICE channel SpiceCursorChannel 0 (remote-viewer:10838): virt-viewer-DEBUG: Destroy SPICE channel SpiceRecordChannel 0 (remote-viewer:10838): virt-viewer-DEBUG: Destroy SPICE channel SpicePlaybackChannel 0 (remote-viewer:10838): virt-viewer-DEBUG: Destroy SPICE channel SpiceMainChannel 0 (remote-viewer:10838): virt-viewer-DEBUG: zap main channel (remote-viewer:10838): virt-viewer-DEBUG: notebook show status 0x1fc6200 ++++ The very end of the log is not that relevant, I just closed the session: ++++ (remote-viewer:10838): virt-viewer-DEBUG: Guest win-10-coe display has disconnected, shutting down Guest win-10-coe display has disconnected, shutting down (remote-viewer:10838): virt-viewer-DEBUG: Disposing window 0x1fc5120 ++++ So, somehow the spice channel is getting "destroyed", but there's no information about why...
BTW, as mentioned, but just to confirm, only a "system_reset" from the qemu monitor helps, since the screen is totally frozen. A spice client close and re-open doesn't help at all...
Some patches when upstream in 0.12.8 which seems related to these issues. Can you try with spice server 0.12.8 ?
.
0.12.8 doesn't help. By using it, it takes more time to get to the frozen rendering, but it still gets frozen. Now there's no black screen though. But still, the only way to get out of the frozen state is to "system_reset".
SpiceWorker-Warning **: red_worker.c:163:rendering_incorrect: rendering incorrect from now on: get_drawable main_channel_link: add main channel client main_channel_handle_parsed: agent start main_channel_handle_parsed: net test: invalid values, latency 16743 roundtrip 16740. assuming high bandwidth inputs_connect: inputs channel client create red_dispatcher_set_cursor_peer:
I am having the same problem on my fedora 24. It has been happening for some months now. The VM freezes and I need to reset it. I included a piece of the log, below: 2016-11-23 00:46:40.155+0000: starting up libvirt version: 1.3.3.2, package: 1.fc24 (Fedora Project, 2016-07-19-00:36:57, buildvm-25.phx2.fedoraproject.org), qemu version: 2.6.2 (qemu-2.6.2-5.fc24), hostname: myhost LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=spice /usr/bin/qemu-kvm -name MYVM,debug-threads=on -S -machine pc-i440fx-2.1,accel=kvm,usb=off -cpu Haswell-noTSX,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 8192 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid 5888fbcb-5c33-4127-bc8f-1edc5feeebd8 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-6-MYVM/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot menu=off,strict=on -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive if=none,id=drive-ide0-0-1,readonly=on -device ide-cd,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 -drive if=none,id=drive-ide0-1-0,readonly=on -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive file=/opt/kvm/images2/MYVM.img,format=qcow2,if=none,id=drive-virtio-disk0 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=28 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:84:78:74,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=127.0.0.1,disable-ticketing,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,bus=pci.0,addr=0x2 -device ich9-intel-hda,id=sound0,bus=pci.0,addr=0x7 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1 -device vfio-pci,host=00:1a.0,id=hostdev0,bus=pci.0,addr=0x9 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -msg timestamp=on char device redirected to /dev/pts/0 (label charserial0) main_channel_link: add main channel client red_dispatcher_set_cursor_peer: inputs_connect: inputs channel client create ((null):12160): SpiceWorker-Warning **: red_worker.c:163:rendering_incorrect: rendering incorrect from now on: get_drawable main_channel_handle_parsed: agent start ehci warning: guest updated active QH red_channel_client_disconnect: rcc=0x5556f2b6e000 (channel=0x5556ef7bc000 type=3 id=0) red_peer_receive: Connection reset by peer red_channel_client_disconnect: rcc=0x5556f271c000 (channel=0x5556ef6fec00 type=2 id=0) red_channel_client_disconnect: rcc=0x5556f2b73000 (channel=0x5556ef6dcea0 type=9 id=0) red_channel_client_disconnect_dummy: rcc=0x5556f15b3000 (channel=0x5556f24c1440 type=5 id=0) snd_channel_put: SndChannel=0x5556f0e06000 freed red_channel_client_disconnect_dummy: rcc=0x5556f15ae000 (channel=0x5556f24c15a0 type=6 id=0) snd_channel_put: SndChannel=0x5556f1f86000 freed red_peer_receive: Connection reset by peer red_channel_client_disconnect: rcc=0x5556f2b89000 (channel=0x5556ef6dd040 type=9 id=1) red_channel_client_disconnect: rcc=0x5556f0e2a000 (channel=0x5556f0c74000 type=4 id=0) red_channel_client_disconnect: rcc=0x5556f2b84000 (channel=0x5556ef7b4000 type=1 id=0) main_channel_client_on_disconnect: rcc=0x5556f2b84000 red_client_destroy: destroy client 0x5556ef6d6e80 with #channels=6
(In reply to Javier from comment #3) > The man qemu shows a "virtio" vga, but I haven't seen it compiled for > windows yet, neither I know if it would integrate with spice... Might have > better performance though, but can't test on win client yet. > > That said, the qxlod driver I'm using is provided by the virtio-win ISO from > RH, and other than this spice issue, it seems to work quite well on sdl > mode... > > BTW, I'm using right now the virtio-win ISO from RH: > > virtio-win 0.1.113.1 > > That added support to win10 some time back. Not for qxl-wddm-dod, no. The first release was early this month: https://lists.freedesktop.org/archives/spice-devel/2016-November/033450.html
Well, might be spice doesn't work with the virtio-win drivers provided by fedora? See: https://fedoraproject.org/wiki/Windows_Virtio_Drivers#ISO_contents There you can find: qxldod/: QXL graphics driver for Windows 8 and later. (build virtio-win-0.1.103-2 and later) And if you take a look at: https://fedoraproject.org/wiki/Windows_Virtio_Drivers#Links Then you'll find they're using: https://github.com/vrozenfe/qxl-dod Which description indicates: +++ QXL WDDM DOD driver Heavily based on Microsoft KMDOD example and XDDM QXL driver +++ It works quite well (as well as the other virtio drivers provided by virtio-win), except for spice. Perhaps some coordination with the virtio-win guys can be done, so they include the spice , since the virtio drivers provided by spice-guest-tools-windows are usually way out of date... But 1st, so is it confirmed one needs to get rid of the qxl-dod driver one is already using from virtio-win, in favor or the spice version of it?
(In reply to Javier from comment #17) > It works quite well (as well as the other virtio drivers provided by > virtio-win), except for spice. Perhaps some coordination with the > virtio-win guys can be done, I've sent an email asking if they can provide the latest driver from https://www.spice-space.org/download/windows/qxl-wddm-dod/qxl-wddm-dod-0.13/ > since the virtio drivers provided by spice-guest-tools-windows > are usually way out of date... Help welcome in maintaining them up to date :) > But 1st, so is it confirmed one needs to get rid of the qxl-dod driver one > is already using from virtio-win, in favor or the spice version of it? I'd strongly recommend using https://www.spice-space.org/download/windows/qxl-wddm-dod/qxl-wddm-dod-0.13 which is based on the qxl-dod driver from the virtio-win ISO but has seen some fixes and improvements, and is the code base which is going to be maintained.
Found the issue, :-) And yes, it seems related to the win driver, :-) I never checked on the power settings, and apparently the qxl-wddm-dod driver is not able to handle the screen turning off. I configures the time for screen inactivity turn off to never, and it seems I'm not getting the blank screen any longer... The work around works with the driver provided by Fedora virtio-win ISO (currently using v. 0.1.133.1). Not sure if this is something known, and the config should always be set to never. BTW, I also configured the sleep to never happen... Weird that the driver really affects on the SPICE viewer. The exact same driver on SDL or GTK display doesn't have that problem, only the SPICE viewer... As having a work around the issue, if this is not wished to be explored further by devs, can be closed, :-)
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/spice/spice-server/issues/18.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.