Hi
On Wed, Mar 23, 2022 at 12:47 AM Jonathon Jongsma <jjongsma(a)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@redh...),
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?
- There may be an expectation that vnc clipboard is enabled using
the
<graphics type='vnc'><clipboard
copypaste='yes'/></graphics> similar to what
spice offers. In fact, it seems that this is the approach Marc-Andre took
when adding copy/paste support in his dbus display patch series. But even for
spice, this <clipboard> configuration element is not enough to enable the
copy/paste feature. It also requires a 'spicevmc' character device to be
added to the domain.
And my dbus solution is not complete, although it should be possible
to add the missing virtserialport.
Jonathon Jongsma (3):
qemu: add capability for qemu-vdagent chardev
conf: add qemu-vdagent channel
qemu: add support for qemu-vdagent channel
docs/formatdomain.rst | 17 ++++++
src/conf/domain_conf.c | 49 ++++++++++++++++-
src/conf/domain_conf.h | 7 +++
src/conf/domain_validate.c | 1 +
src/conf/schemas/domaincommon.rng | 11 ++++
src/qemu/qemu_capabilities.c | 2 +
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 13 +++++
src/qemu/qemu_monitor_json.c | 10 ++++
src/qemu/qemu_process.c | 1 +
src/qemu/qemu_validate.c | 1 +
src/security/security_dac.c | 2 +
.../caps_6.1.0.x86_64.xml | 1 +
.../caps_6.2.0.aarch64.xml | 1 +
.../caps_6.2.0.x86_64.xml | 1 +
.../caps_7.0.0.x86_64.xml | 1 +
.../channel-qemu-vdagent.x86_64-latest.args | 41 ++++++++++++++
.../qemuxml2argvdata/channel-qemu-vdagent.xml | 34 ++++++++++++
tests/qemuxml2argvtest.c | 1 +
.../channel-qemu-vdagent.x86_64-latest.xml | 55 +++++++++++++++++++
tests/qemuxml2xmltest.c | 1 +
tests/testutilsqemu.c | 1 +
22 files changed, 250 insertions(+), 2 deletions(-)
create mode 100644 tests/qemuxml2argvdata/channel-qemu-vdagent.x86_64-latest.args
create mode 100644 tests/qemuxml2argvdata/channel-qemu-vdagent.xml
create mode 100644 tests/qemuxml2xmloutdata/channel-qemu-vdagent.x86_64-latest.xml
--
2.35.1