Bug 1379206 - Graphic can't be showed out quickly if guest graphic mode is vnc
Summary: Graphic can't be showed out quickly if guest graphic mode is vnc
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.3
Hardware: x86_64
OS: Unspecified
high
high
Target Milestone: rc
: 7.4
Assignee: Gerd Hoffmann
QA Contact: Guo, Zhiyi
URL:
Whiteboard:
Keywords: Regression, ZStream
Depends On:
Blocks: 1401400 1392881 1395265
TreeView+ depends on / blocked
 
Reported: 2016-09-26 03:54 UTC by mxie@redhat.com
Modified: 2017-08-02 03:32 UTC (History)
17 users (show)

(edit)
Previously, using the virt-viewer utility to view a guest virtual machine in virtual network computing (VNC) graphic mode did not properly generate the graphical output if virt-viewer was disconnected and then reconnected in a short span of time. With this update, a server refresh is reliably triggered on reconnecting with virt-viewer in the described scenario, and it shows the expected graphical output.
Clone Of:
: 1392881 (view as bug list)
(edit)
Last Closed: 2017-08-01 23:37:14 UTC


Attachments (Terms of Use)
screenshot (566.83 KB, image/png)
2016-09-26 03:54 UTC, mxie@redhat.com
no flags Details
vnc-debug.log (4.45 KB, text/plain)
2016-09-26 03:55 UTC, mxie@redhat.com
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2017:2392 normal SHIPPED_LIVE Important: qemu-kvm-rhev security, bug fix, and enhancement update 2017-08-01 20:04:36 UTC

Description mxie@redhat.com 2016-09-26 03:54:19 UTC
Created attachment 1204651 [details]
screenshot

Description of problem:
Graphic can't be showed out quickly if guest graphic mode is vnc

Version-Release number of selected component (if applicable):
gtk-vnc-0.5.2-7.el7.x86_64


How reproducible:
100%

Steps to Reproduce:
1.Prepare a guest which has vnc graphic mode, power on the guest and then log in to system
#virsh dumpxml empty_cdrom
   <graphics type='vnc' port='5900' autoport='yes' listen='127.0.0.1'>
      <listen type='address' address='127.0.0.1'/>
    </graphics>


2.Using virt-viewer to connect this guest,close the virt-viewer at first time and then using virt-viewer to connect this guest again, you will find  console is black as screenshot, the graphic could be showed out until mouse cursor moves over the display

Actual results:
As above description

Expected results:
Graphic can be showed out quickly when using virt-viewer to connect a vnc guest 

Additional info:
1.Can't reproduce this problem on a spice guest

Comment 1 mxie@redhat.com 2016-09-26 03:55 UTC
Created attachment 1204652 [details]
vnc-debug.log

Comment 3 Daniel Berrange 2016-09-26 08:09:31 UTC
This is likely a QEMU bug in its VNC server. Can you confirm what qemu version you have - presumably it is the new qemu-kvm-rhev 2.6.0 ?

If so we'll need this fix

commit b69a553b4af9bc87a8b2e0a7b7a7de4cc7f0557e
Author: Daniel P. Berrange <berrange@redhat.com>
Date:   Tue Aug 16 17:30:32 2016 +0100

    ui: fix refresh of VNC server surface
    
    In previous commit
    
      commit c7628bff4138ce906a3620d12e0820c1cf6c140d
      Author: Gerd Hoffmann <kraxel@redhat.com>
      Date:   Fri Oct 30 12:10:09 2015 +0100
    
        vnc: only alloc server surface with clients connected
    
    the VNC server was changed so that the 'vd->server' pixman
    image was only allocated when a client is connected.
    
    Since then if a client disconnects and then reconnects to
    the VNC server all they will see is a black screen until
    they do something that triggers a refresh. On a graphical
    desktop this is not often noticed since there's many things
    going on which cause a refresh. On a plain text console it
    is really obvious since nothing refreshes frequently.
    
    The problem is that the VNC server didn't update the guest
    dirty bitmap, so still believes its server image is in sync
    with the guest contents.
    
    To fix this we must explicitly mark the entire guest desktop
    as dirty after re-creating the server surface. Move this
    logic into vnc_update_server_surface() so it is guaranteed
    to be call in all code paths that re-create the surface
    instead of only in vnc_dpy_switch()
    
    Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
    Reviewed-by: Peter Lieven <pl@kamp.de>
    Tested-by: Peter Lieven <pl@kamp.de>
    Message-id: 1471365032-18096-1-git-send-email-berrange@redhat.com
    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

Comment 7 mxie@redhat.com 2016-09-27 02:11:27 UTC
(In reply to Daniel Berrange from comment #3)
> This is likely a QEMU bug in its VNC server. Can you confirm what qemu
> version you have - presumably it is the new qemu-kvm-rhev 2.6.0 ?
> 

Yeah, the version is qemu-kvm-rhev-2.6.0-27.el7.x86_64,thanks

Comment 13 Guo, Zhiyi 2017-03-17 08:24:50 UTC
Reproduce this issue against qemu-kvm-rhev-2.6.0-27.el7.x86_64.

Boot a guest with xml:
<domain type='kvm' id='6'>
  <name>rhel7.4</name>
  <uuid>25decf3e-0bed-45fd-a744-25acf7e4bd29</uuid>
  <memory unit='KiB'>1048576</memory>
  <currentMemory unit='KiB'>1048576</currentMemory>
  <vcpu placement='static'>1</vcpu>
  <resource>
    <partition>/machine</partition>
  </resource>
  <os>
    <type arch='x86_64' machine='pc-i440fx-rhel7.3.0'>hvm</type>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <vmport state='off'/>
  </features>
  <cpu mode='custom' match='exact'>
    <model fallback='forbid'>Haswell-noTSX</model>
  </cpu>
  <clock offset='utc'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='no'/>
  </clock>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <pm>
    <suspend-to-mem enabled='no'/>
    <suspend-to-disk enabled='no'/>
  </pm>
  <devices>
    <emulator>/usr/libexec/qemu-kvm</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/home/image/rhel74.qcow2'/>
      <backingStore/>
      <target dev='vda' bus='virtio'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
    </disk>
    <controller type='usb' index='0' model='ich9-ehci1'>
      <alias name='usb'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x7'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci1'>
      <alias name='usb'/>
      <master startport='0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0' multifunction='on'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci2'>
      <alias name='usb'/>
      <master startport='2'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x1'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci3'>
      <alias name='usb'/>
      <master startport='4'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x2'/>
    </controller>
    <controller type='pci' index='0' model='pci-root'>
      <alias name='pci.0'/>
    </controller>
    <controller type='virtio-serial' index='0'>
      <alias name='virtio-serial0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </controller>
    <interface type='bridge'>
      <mac address='52:54:00:0d:52:70'/>
      <source bridge='br0'/>
      <target dev='vnet0'/>
      <model type='virtio'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
    <serial type='pty'>
      <source path='/dev/pts/1'/>
      <target port='0'/>
      <alias name='serial0'/>
    </serial>
    <console type='pty' tty='/dev/pts/1'>
      <source path='/dev/pts/1'/>
      <target type='serial' port='0'/>
      <alias name='serial0'/>
    </console>
    <channel type='spicevmc'>
      <target type='virtio' name='com.redhat.spice.0' state='disconnected'/>
      <alias name='channel0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    </channel>
    <channel type='unix'>
      <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/domain-6-rhel7.4/org.qemu.guest_agent.0'/>
      <target type='virtio' name='org.qemu.guest_agent.0' state='connected'/>
      <alias name='channel1'/>
      <address type='virtio-serial' controller='0' bus='0' port='2'/>
    </channel>
    <input type='tablet' bus='usb'>
      <alias name='input0'/>
      <address type='usb' bus='0' port='1'/>
    </input>
    <input type='mouse' bus='ps2'>
      <alias name='input1'/>
    </input>
    <input type='keyboard' bus='ps2'>
      <alias name='input2'/>
    </input>
    <graphics type='vnc' port='5900' autoport='yes' listen='0.0.0.0'>
      <listen type='address' address='0.0.0.0'/>
    </graphics>
    <sound model='ich6'>
      <alias name='sound0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </sound>
    <video>
      <model type='vga' vram='16384' heads='1' primary='yes'/>
      <alias name='video0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
    <redirdev bus='usb' type='spicevmc'>
      <alias name='redir0'/>
      <address type='usb' bus='0' port='2'/>
    </redirdev>
    <redirdev bus='usb' type='spicevmc'>
      <alias name='redir1'/>
      <address type='usb' bus='0' port='3'/>
    </redirdev>
    <memballoon model='virtio'>
      <alias name='balloon0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
    </memballoon>
  </devices>
  <seclabel type='dynamic' model='selinux' relabel='yes'>
    <label>system_u:system_r:svirt_t:s0:c802,c894</label>
    <imagelabel>system_u:object_r:svirt_image_t:s0:c802,c894</imagelabel>
  </seclabel>
  <seclabel type='dynamic' model='dac' relabel='yes'>
    <label>+107:+107</label>
    <imagelabel>+107:+107</imagelabel>
  </seclabel>
</domain>

connect guest with virt-viewer,disconnect and reconnect, screen always show blank if not refresh it manually.

Verify against qemu-kvm-rhev-2.8.0-5.el7.x86_64, guest has ui displayed during disconnect/reconnect.

Comment 14 Guo, Zhiyi 2017-03-17 08:25:41 UTC
Verified per comment 13

Comment 16 errata-xmlrpc 2017-08-01 23:37:14 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.

https://access.redhat.com/errata/RHSA-2017:2392

Comment 17 errata-xmlrpc 2017-08-02 01:14:54 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.

https://access.redhat.com/errata/RHSA-2017:2392

Comment 18 errata-xmlrpc 2017-08-02 02:06:52 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.

https://access.redhat.com/errata/RHSA-2017:2392

Comment 19 errata-xmlrpc 2017-08-02 02:47:39 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.

https://access.redhat.com/errata/RHSA-2017:2392

Comment 20 errata-xmlrpc 2017-08-02 03:12:20 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.

https://access.redhat.com/errata/RHSA-2017:2392

Comment 21 errata-xmlrpc 2017-08-02 03:32:30 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.

https://access.redhat.com/errata/RHSA-2017:2392


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