-
Notifications
You must be signed in to change notification settings - Fork 0
Guest access
User will access the guest by VNC, spice and console. All of them should be HTML5 client with encryption (wss://) support.
now user can access the guest easily by noVNC.
But still need some improvement:
- set the client size automatically
- show the guest name correctly, when guest name is unicode string.
- a kimchi special back ground.
libvirt Spice
We will not make Spice into release 1.0. It's exciting that we will be able to support it soon.
- There is already a html5 spice client available.
- And the client support is as easy as novnc.
- We can use the same websockify code for both types of connection.
This HTML5 spice lacks support for many features, such as audio, video.
looks like it's early code so far. But it would get better.
If we start using the client a lot, maybe there will be motivation to improve it.
And it is best to motivate qemu developer support native spice websocket server in qemu.
lbivirt console
User should have another choice console except spice and vnc. It is more convenience to manager the guest by VNC and spice.
Console is a lightweight way to access guest. Text-based console consumes less bandwidth and generic ssh client can connect it.
There are several patches about console in Ovirt.
- Add text-based console support
- Add simple text-based console in vdsClient
- remote serial console via HTTP streaming handler
but all these patches are not based html5.
It is better that a native support for console websockets in qemu chardev backend.
we can also implement the websocket console by proxy(websockify) as noNVC.
With a websocket proxy, we can add HTTP authentication integrating ldap or other auth methods to protect the serial port.
But With websocket implemented in qemu, the efficiency is most optimized. This is because the console access is interactive, the proxy can not accumulate data and send them in big trunk. The proxy forwards every few bytes as soon as they arrives, so each context switch and system call just carry a few bytes as payload. We can observe high CPU usage of the proxy when the serial port traffic is very active. If we add a small delay that can not be recognized by human user to the proxy, and adjust the kernel scheduling granularity, then we can see the CPU usage drops greatly.
qemu has already integrated websocket into its VNC server. Fot console, the websocket handshaking, encoding, decoding code lives in the same thread of VNC server, it just adds some extra function calls overhead. If we implement websocket backend for qemu chardev, this code can be re-used. It needs some refactor to be re-used though, because the websocket code is tightly coupled with VNC server code now.
Summarize
There are some HTML5 websocket console clients ready to use.
implement a websocket proxy to access qemu's chardev pty backend, and existing "websockify" proxy can be used to access qemu's chardev tcp backend.
Features such as authentication can be added to proxy but the CPU usage may be high when the traffic is busy. It is not a big problem, we know some methods can drop the CPU usage.
Implementing a websocket backend for qemu chardev is supposed to be most optimal and the code from websocket VNC can be re-used after some refactor.
Recommend the solution based on "websockify" modified by OpenStack or oVirt for kimchi is to support HTML5 console without qemu native wss support.
We should employ the following strategy for HTML5 VNC and console:
Check if qemu supports wss:// natively. If it does, use the native support. If not, wrap the standard TCP port with a websocket. We already wrap the vnc port today in kimchi. We could do the same with a console if it were exposed over tcp as well.
http://libvirt.org/formatdomain.html#elementsCharTCP
...
<devices>
<serial type="tcp">
<source mode="bind" host="127.0.0.1" service="2445"/>
<protocol type="raw"/>
<target port="1"/>
</serial>
</devices>
...
Then we wrap port 2445 with our new_ws_proxy() function. Someone should give it a try and post patches.