Feature Name
Virt VNC Resource Tunnel
Summary
Provide client access to guest resources such as the serial console, and sound card output, by tunnelling over the VNC connection
Owner
- Name: Daniel Berrange
- email: <berrange@fedoraproject.org>
Current status
- Targeted release: Fedora 12 (Currently this is fairly uncertain, given other virt feature workload for F12)
- Last updated: (DATE)
- Percentage of completion: 20%
Detailed Description
When connecting to a remote virtualization host, there is a secure connection to the libvirtd daemon for management tasks, and a secure connection to the guest's VNC server for desktop interaction. There is, however, no way to access the a serial ports / text consoles associated with a guest, nor the ability to stream the emulated sound card's audio output to the VNC client. A goal of remote access is to need only a single TCP connection to libvirt, and a single TCP connection per guest. Primarily this is to avoid needing to add GSSAPI/SASL/TLS support to yet more network protocols. This implies that to access the serial/text consoles and received audio output, it will be necessary to tunnel these resources over the existing secure VNC connection. With virt-manager running unprivileged, this tunnelling capability is also valuable for local desktop use cases, since virt-manager cannot directly access the serial port PTYs, and the privileged QEMU instance cannot directly talk to pulseaudio in the desktop session.
Providing access to the serial/text consoles should be very easy since these are low bandwidth streams with no significant low latency requirements. While QEMU's VNC server does already contain an extension to send audio back to the VNC client, it remains to be seen whether this is good enough to allow audio playback without drop-outs. Only writing real proof of concept client code in GTK-VNC will show whether this is going to be usable. If it proves incapable of working, the audio part of this feature can be dropped. Merely providing serial/text console access is a big win in its own right.
Benefit to Fedora
Users managing virtual machines through virt-manager or virt-viewer, will gain the ability to interact with the guest serial/text consoles and have audio output via their local desktop audiosubsystem.
Scope
- Define a extension to RFB for accessing serial/text consoles over VNC connection [DONE]
- Implement serial/text console extension in QEMU VNC server [PROOF OF CONCEPT]
- Implement serial/text console extension in GTK-VNC [PROOF OF CONCEPT]
- Implement audio client extension in GTK-VNC [PROOF OF CONCEPT]
- Extend virt-manager to wire up GTK-VNC audio stream to gstreamer/pulseaudio
- Extend virt-manager to access serial/text consoles via GTK-VNC
- Extend virt-viewer to wire up GTK-VNC audio stream to gstreamer/pulseaudio
- Extend virt-viewer to access serial/text consoles via GTK-VNC
v1 posting of QEMU changes: http://lists.gnu.org/archive/html/qemu-devel/2009-07/msg00054.html
How To Test
Testing serial console access
- Deploy a new Fedora 12 guest
- Ensure guest OS is running a getty/mingetty process on ttyS0 or hvc0 as appropriate
- Open graphical guest console in remote virt-manager instance
- Attempt to use the serial console associate with the guest
Testing audio playback
- Deploy a new Fedora 12 guest
- Open graphical guest console in remote virt-manager instance
- Play an audio file inside the guest
- Listen for audio to play on local desktop machine
User Experience
Users will be able to interact with the serial/text consoles of Fedora 12 guests out of the box with no configuration required, simply by opening the virt-manger guest console window. Any audio stream played inside the guest will automatically be output via the local GNOME session audio subsystem
Dependencies
At least impacts on:
- qemu
- gtk-vnc
- virt-manager
- virt-viewer
Contingency Plan
Highest risk is the audio tunnelling feature, since it is unclear whether the existing QEMU VNC audio streaming feature is good enough to provide glitch-free playback. If this proves unworkable, then the audio part of this feature will be dropped. Getting the text / serial console wired up is pretty critical, since there is currently no way to access this remotely, or even locally now virt-manager is unprivileged. Fedora 11 is already a regression from Fedora 12 in the local serial console access, so fixing this in F12 si very important.
Documentation
- TBD
Release Notes
- Something about how you can interact with the guest much better