Hi On Wed, Mar 23, 2022 at 6:44 PM Jonathon Jongsma <jjongsma@xxxxxxxxxx> wrote: > > 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@xxxxxxxxxx> 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@xxxxxxxxxx/20211222194345.766352-13-marcandre.lureau@xxxxxxxxxx/), > >> 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 Yes, although the spicevmc -chardev can is configurable via its name to transport various content, whereas qemu-vdagent is limited to spice-vdagent. > 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. Oh my, it's probably a good idea to deprecate it. > > > > > 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 >
