On Mon, Feb 01, 2021 at 04:27:43PM +0100, Christophe de Dinechin wrote:
On 29 Jan 2021, at 15:32, Daniel P. Berrangé <berrange@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é <berrange@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 <kraxel@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 suggestion was that clipboard be sent by injecting key pressesto the guest, so that is scancode based.
But the VNC clipboard protocol is not scancode based. So where would the clipboard->scancode conversion happen?
Also, any idea how to copy from the guest in that case?
If you're not doing it using key press injection, then keymapping
and scancodes are irrelevant.
Indeed, but that requires some guest agent, and Gerd seems to not like that idea.
BTW, isolating the clipboard sharing protocol from VNC is an
|