Customer main objective is to be able to use copy/paste and keyboard language input.

Hi Jean-François,

Engineering would like to better understand the customer's use case here. Our expectation is that QEMU's consoles are only to be used in case of emergencies (for example, the VM is not accessible over the network), and that if the VM is running normally and is accessible, users would connect to it using the OS's native remote access solution (like SSH or X forwarding for Linux and RDP for Windows), which provide a much better user experience than QEMU's consoles.

In addition, SPICE is de facto deprecated by virt engineering, and no other products should depend on it.

So as written, this RFE would get closed as WONTFIX, but we'd like to understand *why* it was written.

Cheers!

Hi Artom,

Customer explanation of their use case.
~~~
we say the same to the users / commercial teams (in regards to previous comment about console being for emergencies cases)

most of our users also use really complex passwords so what we hope to have one day is the ability to copy / paste, that's our main problem / request.
We don't see any other way to get it without the SPICE console.

Any other ideas on how to implement this will be appreciated.
~~~

Thanks for looking into this RFE.
JF

So it looks like the request is to facilitate copy/paste of complicated passwords. It won't get done in SPICE (as I said in comment #3, it's de facto deprecated), but it could be implemented in qemu's VNC support.

The VNC client would need support as well, and it looks like noVNC does support it [1]. I would like to mention that this copy/paste support does NOT appear to work in a Linux console situation, presumably because there's no clipboard on the VM side of things, and I'm assuming that's how noVNC implements copy/paste (in other words, it doesn't trigger keypress events when you paste something). So, if that's where you would like copy/paste to work, this would be a CANTFIX RFE. Still, I'll send this to the qemu devs for review, see what they think.

@customer/GSS: please confirm the exact situation where you need copy/paste. If it's at the stage where the VM is booted in text mode, I'd be inclined to say this cannot work at all, because the VM side doesn't have a clipboard in that situation.

@virt folks: Customer is asking for copy/paste support in the VNC console. I've asked to clarify where exactly they expect this functionality to work.

[1] https://github.com/novnc/noVNC/blob/90ead240c7afde328870a4e6767aab70e71c00a2/README.md#features

So, the vnc protocol has support for cut+paste:

https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst#clientcuttext
(supports iso-8851-1 text/plain only).

https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst#extended-clipboard-pseudo-encoding
(supports utf-8 text/plain and other formats).

That covers vnc client => qemu.  Should not be that difficult to implement,
but it is only the first half of the story.  The tricky part is qemu => guest.

Option one is sending the text as keystrokes to the guest.  Sounds straight
forward at first glance, but the devil is in the details:

 * First you need to know the guest keyboard layout, so you send the correct
   key events.  Also it will stop working for chars where you typically use
   ibus to enter them because there is no keyboard key for them (emoji, kanji,
   ...).  For the password use case the latter probably isn't that much of a
   problem though.
 * Second qemu needs some "paste now" hotkey.  The vnc protocol only notifies
   about cut buffer changes, the vnc client can't ask the server (i.e. qemu)
   to paste the text now.

Option two is an guest agent, simliar to spice, which will sync guest and host
clipboard.  Would need to run in user session context so it has access to the
display server (xorg/wayland) which manages the guest clipboard.  Obvious
disadvantage is the guest agent needed.  But it hasn't keyboard map problems
and it can work both ways (i.e. guest => vnc client cut+paste works too).

Option three would be a combination of both, i.e. in case a guest agent is
running talk to that and try send keystrokes otherwise.

Option one could also be implemented in vnc clients.

I tend to think that Option two is the best way forward.  Option one with
the keyboard map problem can cause alot of issues and support requests
because there is no easy way to automate this.  It essentially requires
manual configuration.

> https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst#clientcuttext
> (supports iso-8851-1 text/plain only).

Oh, this works both ways too, we have a server -> client message as well.
https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst#servercuttext

Data point: tigervnc happily sends utf8-encoded text that way.  Probably
because x11 cutbuffers are traditionally just a sequence of bytes without
any metadata attached, and tigervnc stuffs that as-is into the vnc message.
Which means we can't assume the charset actually is iso-8851-1.

https://patchwork.ozlabs.org/project/qemu-devel/list/?series=230163

https://patchwork.ozlabs.org/project/qemu-devel/list/?series=234670

merged upstream (will be part of the qemu 6.1 release).
https://www.kraxel.org/blog/2021/05/wemu-cut-paste/

Bulk update: Move RHEL-AV bugs to RHEL9. If necessary to resolve in RHEL8, then clone to the current RHEL8 release.

Should already be fixed in Qemu 6.1 onwards, available internally with RHEL9.0 GA.

QE, can you validate and update accordingly?

https://gitlab.com/redhat/centos-stream/src/qemu-kvm/-/merge_requests/54

Gating test with qemu-6.1 all pass, and qemu 6.2 has come out, set 'Verified:Tested, Sanityonly', thanks!

The issues found will be tracked by https://bugzilla.redhat.com/show_bug.cgi?id=2042820, close this one as verified.

Hi Gerd,

could you please tell me how this feature is supposed to work?

I have:

host:
qemu-kvm-6.2.0-8.module+el8.6.0+14324+050a5215.x86_64

guest:
RHEL-9 beta installed from the official ISO media

Command run on the host for the guest provision:
# virt-install --virt-type kvm --name rhel-9 --ram 1024 --disk /var/tmp/rhel-9.qcow2,format=qcow2 --network network=default --graphics vnc,listen=0.0.0.0 --noautoconsole --os-type=linux --location=/var/tmp/rhel-baseos-9.0-beta-0-x86_64-dvd.iso

I tried both vncviewer (Clipboard send/receive enabled in the menu) and vinagre, but the copy and paste doesn't work. Are there some special configuration steps needed?

(In reply to Jaroslav Škarvada from comment #48)
> Hi Gerd,
> 
> could you please tell me how this feature is supposed to work?
> 
> I have:
> 
> host:
> qemu-kvm-6.2.0-8.module+el8.6.0+14324+050a5215.x86_64
> 
> guest:
> RHEL-9 beta installed from the official ISO media
> 
> Command run on the host for the guest provision:
> # virt-install --virt-type kvm --name rhel-9 --ram 1024 --disk
> /var/tmp/rhel-9.qcow2,format=qcow2 --network network=default --graphics
> vnc,listen=0.0.0.0 --noautoconsole --os-type=linux
> --location=/var/tmp/rhel-baseos-9.0-beta-0-x86_64-dvd.iso
> 
> I tried both vncviewer (Clipboard send/receive enabled in the menu) and
> vinagre, but the copy and paste doesn't work. Are there some special
> configuration steps needed?

I can confirm both my VNC viewers work correctly. I tried them both against tigervnc-server running on different machine and the remote<->local clipboard worked correctly, thus the problem is very probably on the qemu-kvm side.

(In reply to Jaroslav Škarvada from comment #48)
> Hi Gerd,
> 
> could you please tell me how this feature is supposed to work?

libvirt domain config (any libvirt version):

<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
[ ... ]
    <controller type='virtio-serial' index='0'>
    </controller>
[ ... ]
  <qemu:commandline>
    <qemu:arg value='-chardev'/>
    <qemu:arg value='qemu-vdagent,id=vdagent,mouse=on,clipboard=on'/>
    <qemu:arg value='-device'/>
    <qemu:arg value='virtserialport,chardev=vdagent,name=com.redhat.spice.0'/>
  </qemu:commandline>
</domain>

IIRC libvirt got support for that too, so with new enough libvirt this
should be configurable without <qemu:commandline>.  Can't find it in
https://libvirt.org/formatdomain.html though, Daniel?

Also: spice-vdagent must be installed and enabled in the guest.

Libvirt support isn't merged yet - IIRC the latest proposal is https://listman.redhat.com/archives/libvir-list/2022-March/229558.html

(In reply to Gerd Hoffmann from comment #50)

Thanks Gerd,

it was really helpful and I got it running.

> <domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>

The xmlns is really important here, otherwise the qemu:commandline elements are ignored.

I think the steps how to get it working should be documented somewhere in the RHEL guides or better this should work out-of-the box for better user experience, becasue for ordinary user it is not straight-forward how to get i working, just my two cents.

Maybe without the spice-vdagent it could also paste the raw characters, i.e. for the pure console to work. I understand that there will be problems with the keyboard layout but if it is choice about no paste or paste with the default EN layout, I think the b) is much better. It could ease work with the console. IMHO some other third party solutions support such raw paste.

Another thing I noticed:
- paste from the host to guest works OK
- paste from the guest to host works only with the vncviewer, but it doesn't work for me with the vinagre VNC client

On the other hand with the tigervnc-server the paste works correctly in both ways with the vinagre, thus it seems there is some protocol incompatibility. I used vinagre-3.22.0-23.fc34.x86_64 for testing.

(In reply to Jaroslav Škarvada from comment #52)
> (In reply to Gerd Hoffmann from comment #50)
> 
> Thanks Gerd,
> 
> it was really helpful and I got it running.
> 
> > <domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
> 
> The xmlns is really important here, otherwise the qemu:commandline elements
> are ignored.
> 
> I think the steps how to get it working should be documented somewhere in
> the RHEL guides or better this should work out-of-the box for better user
> experience, becasue for ordinary user it is not straight-forward how to get
> i working, just my two cents.

The XMLNS stuff is considered unsupported by libvirt. It is simply a means to experiment with the technology.

Full support is pending the patches I pointed to earlier, and once that's done we'll want mgmt apps to just "do the right thing" with configuring this, so the user doesn't need to know the details.

> Maybe without the spice-vdagent it could also paste the raw characters, i.e.
> for the pure console to work. I understand that there will be problems with
> the keyboard layout but if it is choice about no paste or paste with the
> default EN layout, I think the b) is much better. It could ease work with
> the console. IMHO some other third party solutions support such raw paste.
> 
> Another thing I noticed:
> - paste from the host to guest works OK
> - paste from the guest to host works only with the vncviewer, but it doesn't
> work for me with the vinagre VNC client

It isn't fully implemented in GTK-VNC yet, so vinagre won't work fully either.

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 (new packages: qemu-kvm), 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/RHBA-2022:2307