> On 29 Jan 2021, at 15:32, Daniel P. Berrangé <berra...@redhat.com> wrote: > > On Fri, Jan 29, 2021 at 03:19:45PM +0100, Christophe de Dinechin wrote: >> >> >>> On 29 Jan 2021, at 12:08, Daniel P. Berrangé <berra...@redhat.com> wrote: >>> >>> On Fri, Jan 29, 2021 at 11:50:10AM +0100, Christophe de Dinechin wrote: >>>> >>>> >>>>> On 29 Jan 2021, at 09:03, Gerd Hoffmann <kra...@redhat.com> wrote: >>>>> >>>>> Hi, >>>>> >>>>>>> (1) Have some guest agent (spice does it that way). >>>>>>> Advantage: more flexible, allows more features. >>>>>>> Disadvantage: requires agent in the guest. >>>>>> >>>>>> What about running the option to relay data to a VNC server in the >>>>>> guest if there is one running? In other words, using an existing >>>>>> VNC server as an agent, with the option of having a stripped-down, >>>>>> clipboard only VNC server as a later optimization. >>>>> >>>>> Well, if you run Xvnc in the guest anyway why use the qemu vnc server >>>>> in the first place? >>>> >>>> I assume that if you use the qemu VNC, it's because you you don't want to >>>> run Xvnc on some external network, or care about accessing the guest >>>> before Xvnc can be launched. There can be many reasons. >>>> >>>> Again, I want to make it clear that my suggestion is _not_ simply to access >>>> the existing Xvnc as is, but rather to stick with some VNC server code to >>>> handle >>>> the clipboard if / when possible. >>>> >>>> Let me try to imagine a scenario, where I'll use a macOS guest >>>> intentionally >>>> to clarify what I was thinking about. >>>> >>>> - During early boot, there is no in-guest VNC server, so to address that, >>>> you connect to the qemu VNC. At this stage, all screen refresh is handled >>>> by the qemu VNC, and the best you can do if you want to support any >>>> kind of copy-paste is to convert it to virtual keystrokes. The same would >>>> be true for Linux on a text console. >>>> >>>> - Then comes up you macOS guest, and it still has no VNC port open, >>>> so you are stuck with qemu-vnc doing all the work. But now you can >>>> enable screen sharing, and that launches the Apple-maintained macOS >>>> VNC server. >>>> >>>> - Let's assume for illustration that this listens on some private network >>>> that qemu can access, but that is not visible externally. In this case, >>>> you could not VNC to the guest, but you can still VNC to qemu. >>>> >>>> - What I'm suggesting is that qemu-vnc could then switch to simply >>>> relaying VNC traffic to that in-guest server. You'd get the smart update >>>> algorithm that Apple has put in place to deal with transparency and the >>>> like, as well as a level of guest OS integration that would otherwise be >>>> much harder to replicate. >>> >>> IMHO that's an awful lot of complexity to add to the system >>> that isn't especially useful and this opens up new attack >>> vectors for the guest to exploit the host. >>> >>> If people have VNC/RDP/whatever configured inside their guest >>> OS, then there's really little to no reason for them to want >>> to connect to the QEMU VNC server, as viewing initial bootup >>> phase is not required in normal case. The only time such >>> people will need to use the QEMU VNC server is if the guest >>> OS has broken in some way before it fully booted and thus failed >>> to start the guest VNC server. There is no guest VNC server >>> to hand off to in this scenario. >> >> It's a matter of what you want to do with that qemu vnc. >> >> If it's only a backup when there's nothing in the guest to help, >> then maybe trying to support copy-paste is not a good idea. >> >> If it's a standard go-to access point for connecting to your >> guest, then making it smart is hard, but useful. >> >>> >>> The value of the QEMU host side VNC server is that it works >>> for all possible guest OS, no matter whether they are running >>> normally or broken, regardless of what the guest admin has >>> configured in terms of guest level remote desktop. >> >> Understood. >> >> The downside is that there are things it can't do. It cannot correctly >> determine the keyboard map, because that's controlled in software >> in the guest. > > There is no need for the remote desktop server to care about the > keymap. The remote client takes scancodes and passes them to the > server, which then passes them to the guest.
Aren't we talking about pasting clipboard data here? I assume that clipboard data is not encoded as scancodes. > > The person connected to the remote server simply has to configure > their guest OS keymap to match the physical keyboard they currently > have plugged in. > > The only reason a remote server would need to know the keymap is > if it was trying to translate from keycodes back into scancodes. > This is what VNC protocol had to do originally, but VNC was since > extended to pass raw scancodes instead of keycodes, precisely to > avoid needing to care about keymaps. > >>> IOW, if you have a guest remote desktop solution you'll just >>> use that 99% of the time. If you don't have that, then you'll >>> use QEMU VNC/SPICE server, and there won't be anything in the >>> guest for that to proxy to/from. >> >> If really the assumption is there is nothing in the guest to help >> us, then I'd say "paste" should come up with a warning "do you want >> me to try and translate that into keystrokes", and I don't see how to >> implement copy from a graphical display without OCR… > > I'm not saying we can't use stuff in the guest, just that we should be > pragmatic about what we interact with in the guest and degrade nicely. > I don't think that proxying from a host VNC server to a guest VNC server > is sensible, but making use of a guest agent of some kind is not > unreasonable, especially if we can use one that already exists. > > > Regards, > Daniel > -- > |: https://berrange.com <https://berrange.com/> -o- > https://www.flickr.com/photos/dberrange > <https://www.flickr.com/photos/dberrange> :| > |: https://libvirt.org <https://libvirt.org/> -o- > https://fstop138.berrange.com <https://fstop138.berrange.com/> :| > |: https://entangle-photo.org <https://entangle-photo.org/> -o- > https://www.instagram.com/dberrange <https://www.instagram.com/dberrange> :|
