[libvirt PATCH 0/3] Enable copy/paste for vnc displays

[Jonathon Jongsma]

On 3/23/22 4:17 AM, Daniel P. Berrangé wrote:
> On Wed, Mar 23, 2022 at 12:01:19PM +0400, Marc-André Lureau wrote:
>> Hi
>>
>> On Wed, Mar 23, 2022 at 12:47 AM Jonathon Jongsma <jjongsma at redhat.com> wrote:
>>>
>>> This patch series enables support for the qemu-vdagent character device which
>>> enables copy/paste support between guest and client when using vnc graphics.
>>>
>>> The guest must be configured with something like the following:
>>>
>>>      <channel type='qemu-vdagent'>
>>>        <source clipboard='on' mouse='on'/>
>>>        <target type='virtio' name='com.redhat.spice.0'/>
>>>      </channel>
>>>
>>> Copy/paste sync requires a vnc client that has support for copy/paste commands.
>>> Currently virt-viewer does not work, but the version of tigervnc provided by
>>> fedora (executable name 'vncviewer') does work.
>>>
>>> More details about this device on Gerd's blog:
>>> https://www.kraxel.org/blog/2021/05/qemu-cut-paste/
>>>
>>> OPEN QUESTIONS:
>>>
>>> - I'm not fully convinced that the `<source>` element is the right place for
>>>    the new `clipboard` / `mouse` configuration options, but I'm not sure that
>>>    adding a new xml element to the `<channel>` is the right approach either.
>>>    Suggestions welcome.
>>
>> I am not convinced <channel> is appropriate either for -chardev
>> qemu-vdagent. That's why in my dbus display series it's an
>> implementation detail
>> (https://patchew.org/Libvirt/20211222194345.766352-1-marcandre.lureau@redhat.com/20211222194345.766352-13-marcandre.lureau@redhat.com/),
>> and it's not exposed to the domain XML directly. However I realize
>> that my approach is probably broken, as it looks like I totally missed
>> the associated virtserialport! :)
>>
>> As you say "source" is strange to put those extra channel options too.
>>
>> And the only really valid associated device is a virtserialport of
>> name "com.redhat.spice.0", so what's the point in exposing that detail
>> to the user?

You could say the same thing about the normal spice vdagent, right? And 
we allow the user to specify a different virtio name for the spicevmc 
channel. spice-vdagent does offer a --virtio-serial-port-path option 
that can be used to connect to a different name within the guest, after all.

> 
> At the QEMU level we have one serial port with chardv
> 
>    -chardev qemu-vdagent,id=ch1,name=vdagent,clipboard=on
>    -device virtio-serial-pci \
>    -device virtserialport,chardev=ch1,id=ch1,name=com.redhat.spice.0
> 
> 
> but IIUC, we can have multiple frontends - ie both VNC and DBus
> display, and in that case the clipboard=on property on the
> chardev will apply to both VNC & DBus displays. We can't
> control clipboard independantly for the displays, so it is
> right to put the control in the XML for the <channel> for
> both VNC and DBus.
> 

In addition to <channel>, there are several other xml elements that 
essentially map to a qemu character device: <serial>, <console>, etc. 
Would it make more sense to introduce a new element like this for the 
qemu-vdagent? This might make it easier to introduce new configuration 
options that wouldn't really fit in the general <channel>. For example, 
something like:

<qemuvdagent>
   <clipboard copypaste="yes"/>
   <target type='virtio' name='com.redhat.spice.0'/>
</qemuvdagent>

Jonathon