RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 803602 - [RFE]libvirt should support to launch multiple consoles to a VNC guest with qemu-kvm-0.12.1.2-2.240.el6
Summary: [RFE]libvirt should support to launch multiple consoles to a VNC guest with q...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.3
Hardware: x86_64
OS: Linux
urgent
urgent
Target Milestone: rc
: ---
Assignee: Gunannan Ren
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 979268
TreeView+ depends on / blocked
 
Reported: 2012-03-15 08:33 UTC by Geyang Kong
Modified: 2018-12-02 19:04 UTC (History)
16 users (show)

Fixed In Version: libvirt-0.10.2-20.el6
Doc Type: Enhancement
Doc Text:
Feature: Add support for specifying share policy for domain's VNC console. Reason: QEMU changed behavior from shared to exclusive VNC, which broke deployments that relied on shared VNC with no option to request the older behavior. Result (if any): Users may now change the policy using sharePolicy attribute added into VNC graphics element.
Clone Of:
: 979268 (view as bug list)
Environment:
Last Closed: 2013-11-21 08:28:00 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:1581 0 normal SHIPPED_LIVE libvirt bug fix and enhancement update 2013-11-21 01:11:35 UTC

Description Geyang Kong 2012-03-15 08:33:34 UTC
Description of problem:
  libvirt should support to launch multiple consoles to a VNC guest with qemu-kvm-0.12.1.2-2.240.el6

Version-Release number of selected component (if applicable):

qemu-kvm-0.12.1.2-2.240.el6

How reproducible:
100%

Steps to Reproduce:

1. Make sure you have qemu-kvm-0.12.1.2-2.240.el6 installed.

2. Create a VNC guest and start it,you don't really need to install it, my guest's name is T1.

3. Execute #/usr/libexec/qemu-kvm -M rhel6.3.0 -cpu Nehalem -enable-kvm -m 2G -smp 2,sockets=1,cores=2,threads=1 -name rhel6.3 -uuid a0a317fd-0e41-4c4d-b133-546178ed96eb -rtc base=localtime,driftfix=slew -drive file=/var/lib/libvirt/images/T1.img,if=none,id=drive-virtio-disk0,format=raw,cache=none,werror=stop,rerror=stop,aio=native -device ide-drive,bus=ide.0,unit=1,drive=drive-virtio-disk0,id=virtio-disk0  -netdev tap,id=hostnet0,script=no -device e1000,netdev=hostnet0,id=net0,mac=00:1a:2a:42:10:66,bus=pci.0,addr=0x3 -boot c -monitor stdio -vnc :10,share=ignore

4. Make sure you can launch mulpitle consoles for T1 by vncviewer command.

5. Run #virt-viewer T1

6. Repeat step 5.

Actual results:

1. Every time a new console was launched, the previous one will be closed.

Expected results:

1. All consoles could work normally.

Additional info:

1. Since there is a new option "share=[allow-exclusive|force-shared|ignore]" in qemu-kvm-0.12.1.2-2.240.el6., libvirt should have something to support this option.

Comment 9 Gunannan Ren 2012-09-10 14:56:29 UTC
According to qemu doc
"Set display sharing policy. 'allow-exclusive' allows clients to ask for exclusive access. As suggested by the rfb spec this is implemented by dropping other connections. Connecting multiple clients in parallel requires all clients asking for a shared session (vncviewer: -shared switch). This is the default. 'force-shared' disables exclusive client access. Useful for shared desktop sessions, where you don't want someone forgetting specify -shared disconnect everybody else. 'ignore' completely ignores the shared flag and allows everybody connect unconditionally. Doesn't conform to the rfb spec but is traditional QEMU behavior."

If using vncviewer with option '-Shared', it supports guest desktop sharing.

Comment 12 Gunannan Ren 2012-12-19 14:34:22 UTC
I tried it on RHEL6.1 by using qemu-kvm command directly, it is allowed to launch multiple vncviewer consoles.

1, start qemu instance with vnc server on port :9
/usr/libexec/qemu-kvm -m 1G -drive file=/var/lib/libvirt/images/rhel6u3qcow2.img -boot c -vnc :9

2 it permites to run mutiple vncviewer for multiple consoles as follows:
vncviewer :9

For RHEL6.4(release candidate), it is not allowed to do so, but with -shared option to vncviwer like "vncviewer -shared :9", it can show multiple consoles.

I roughly think the qemu-kvm change the behavior of vnc server from mode 'ignore' or 'force-shared' to mode 'allow-exclusive' as I mentioned in comment 9

Comment 13 Dave Allan 2012-12-19 16:01:58 UTC
So, to make sure I understand, qemu behavior changed from allowing shared sessions which is not compliant with the spec, to being spec compliant and the customer was depending on the old, non-compliant behavior.  Is that right?

Comment 14 Gunannan Ren 2012-12-20 03:26:09 UTC
Yes
There is a qemu bug related to this change.
https://bugzilla.redhat.com/show_bug.cgi?id=653779

Comment 15 Dave Allan 2012-12-20 13:37:06 UTC
So how does the customer get the old behavior?

Comment 16 Gunannan Ren 2012-12-21 02:20:15 UTC
If the customer has been using vncviewer, then adding "-shared" option for every vncviewer command as the example given in comment 12.
For virt-viewer, there is no such option like "-shared", we can't do anything unless filing a RFE request bug for virt-viewer as far as I know.

Comment 17 hmiles 2013-02-07 13:45:17 UTC
It sounds like I should file another RFE to add the "-shared" option in virt-viewer. Is this correct?

-Hannah

Comment 18 Dave Allan 2013-02-07 15:05:45 UTC
(In reply to comment #17)
> It sounds like I should file another RFE to add the "-shared" option in
> virt-viewer. Is this correct?

Yes, please do.

Comment 21 Dave Allan 2013-03-25 12:46:05 UTC
(In reply to comment #12)
> I roughly think the qemu-kvm change the behavior of vnc server from mode
> 'ignore' or 'force-shared' to mode 'allow-exclusive' as I mentioned in
> comment 9

Can you float the idea upstream that libvirt's behavior should not change even if the underlying qemu changes?

Comment 22 Gunannan Ren 2013-05-01 14:45:00 UTC
Sure, but sorry so late
https://www.redhat.com/archives/libvir-list/2013-May/msg00023.html

Comment 23 Gunannan Ren 2013-05-06 13:21:41 UTC
Patch sent to upstream
https://www.redhat.com/archives/libvir-list/2013-May/msg00391.html

Comment 24 Gunannan Ren 2013-05-22 11:29:52 UTC
commit 2a58d076541b82cef4859ac18812876a5dd3b541
Author: Guannan Ren <gren>
Date:   Tue May 21 22:31:48 2013 +0800

    conf: add 'sharePolicy' attribute to graphics element for vnc
    
     -vnc :5900,share=allow-exclusive
    allows clients to ask for exclusive access which is
    implemented by dropping other connections Connecting
    multiple clients in parallel requires all clients asking
    for a shared session (vncviewer: -shared switch)
    
     -vnc :5900,share=force-shared
    disables exclusive client access.  Useful for shared
    desktop sessions, where you don't want someone forgetting
    specify -shared disconnect everybody else.
    
     -vnc :5900,share=ignore
    completely ignores the shared flag and allows everybody
    connect unconditionally

 <devices>
   <graphics type='vnc' port='5900' autoport='no' listen='127.0.0.1' sharePolicy='allow-exclusive'>
     <listen type='address' address='127.0.0.1'/>
   </graphics>
 </devices>

Comment 33 Jiri Denemark 2013-07-15 09:03:27 UTC
Patches sent for internal review: http://post-office.corp.redhat.com/archives/rhvirt-patches/2013-July/msg00066.html

Comment 35 CongDong 2013-07-16 06:18:40 UTC
I can produce this bug:
Version:
# rpm -qa libvirt qemu-kvm
libvirt-0.10.2-18.el6.x86_64
qemu-kvm-0.12.1.2-2.355.el6.x86_64

Steps:
1. Create a vnc guest k1, try to add "sharePolicy='ignore'" to xml.
# virsh dumpxml k1
<graphics type='vnc' port='-1' autoport='yes'/>

2. Start the guest
# virsh start k1
Domain test started

# ps -ef | grep k1
qemu     19586     1 56 14:05 ?        00:00:06 /usr/libexec/qemu-kvm -name k1 -S -M rhel6.4.0 -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -uuid 921a4041-8218-9f19-102a-65180971105a -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/k1.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/root/k1.img,if=none,id=drive-ide0-0-0,format=raw,cache=none -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -netdev tap,fd=26,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:5d:46:9c,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -vnc 127.0.0.1:0 -vga cirrus -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5

3. Launch mulpitle consoles for k1 by vncviewer command
# vncivewer :0 -shared
# vncivewer :0 -shared(run this in another terminal)

4.# virt-viewer k1
5. do step4 again

Result:
step1: can't add "sahrePolicy='ignore'" to xml
step3: two consoles can both work well, if without '-shared', the last console will replace previous one.
step4: The console can work well
step5: The console of step4 is closed, and the console of step5 replace it.



Verify:
Version:# rpm -qa libvirt qemu-kvm
libvirt-0.10.2-20.el6.x86_64
qemu-kvm-0.12.1.2-2.378.el6.x86_64

Steps:
1. Create a vnc guest k1, try to add "sharePolicy='ignore'" to xml.
# virsh dumpxml k1
<graphics type='vnc' port='5912' autoport='no' listen='0.0.0.0' sharePolicy='ignore'>
      <listen type='address' address='0.0.0.0'/>
    </graphics>
2. Start the guest
# virsh start k1
Domain test started

# ps -ef | grep k1
qemu      2633     1 47 02:14 ?        00:00:04 /usr/libexec/qemu-kvm -name k1 -S -M rhel6.4.0 -no-kvm -m 512 -smp 1,sockets=1,cores=1,threads=1 -uuid 2b04214a-334e-f149-250f-30de3b73d3b0 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/k1.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/kvm_img3/k1.img,if=none,id=drive-ide0-0-0,format=raw -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -netdev tap,fd=34,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:32:44:29,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -vnc 0.0.0.0:12,share=ignore -vga cirrus -device AC97,id=sound0,bus=pci.0,addr=0x4 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5

3. Launch mulpitle consoles for k1 by vncviewer command
# vncivewer :12 
# vncivewer :12 (run this in another terminal)

4.# virt-viewer k1
5. do step4 again

Result:
step1: Can add 'sharePolicy' to xml like the result in step1
step3: The two consoles work well
step4: The console works well
step5: Console in step4 didn't close, and both of them work well

As the result, change to VERIFIED.

Comment 38 errata-xmlrpc 2013-11-21 08:28:00 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-2013-1581.html


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