[Kimchi-devel] RFC: Add serial as a valid graphics type

[Aline Manera]

>> I'm interested on this. Had a little investigation, ws4py provides
>> Cherrypy plugin and tool to add websocket support. It'll be very nice if
>> we can provide websocket in current Cherrypy server. It solves to
>> authentication, authorization and security problem. On Cherrypy offical
>> site, it also says websocket is supported by using ws4py.
>>
>> A problem is that ws4py is not packaged in Fedora and RHEL, maybe we'll
>> have to ship the library in our source code. That raise another problem.
>> The license of ws4py is an ad-hoc one. We may have to verify if it is
>> compatible with LGPL3.
>>
> Had read the license of ws4py, it does not restrict redistributions and
> modification, as long as we keep the license message for that piece of
> code. Looks a good choice, because it can be integrated into cherrypy
> easily, so we don't have the authentication problem as websockify. If we
> can use this library, we can easily use virDomain.openConsole() API to
> get the console stream and forward to websocket.
>
>>>>> If we are to use websocket, the nature solution would be as follow
>>>>>     host pty -> websockify ---(websocket)--> wspty
>>>>>
>>>>> There is a potential security risk. If we use websockify to transfer
>>>>> serial port data, we are exposing the serial port to public without any
>>>>> authentication. We have the same problem in VNC/Spice, that's why we add
>>>>> ticket. The VNC ticket is using the password mechanism built in the VNC
>>>>> protocol. However when using serial port, there is no such protocol, it
>>>>> just transfers raw data. A solution is that we use the websocket
>>>>> facility supported by cherrypy and forward the serial port data
>>>>> ourselves, so that we can do authentication as usual.
> I did a little more investigation. websockify does not support
> forwarding a file like object (such as /dev/pts/4). Though it support
> forwarding a Unix socket, the socket path is defined in the command line
> once, and it does not support loading the socket part in target config
> file dynamically. So a workaround maybe we firstly use socat to forward
> the file/socket to/from 127.0.0.1:some_port, then add a token in target
> config file to ask websockify forward this some_port.
>
> Qemu and libvirt support defining a network backed chardev, so we can
> use the following XML for the VMs we create to define a serial port.
>
>      <serial type='tcp'>
>        <source mode='bind' host='127.0.0.1' service='0'/>
>        <protocol type='raw'/>
>        <target port='0'/>
>      </serial>

Does it mean the text console on Kimchi will not work well with guests 
created outside Kimchi?

> Then use the following qmp command to retrieve the allocated local port.
>
>    virsh qemu-monitor-command domain_name --cmd \
>      '{"execute": "query-chardev"}'
>
> At last we can add a new token in websockify config dir according to the
> returned port information.
>
> Another method is that we can do a monkey patch of the
> "websockify.websocketproxy", and replace the new_websocket_client()
> method to make it load pty and Unix socket dynamically. In the proxy()
> method, it uses select.select() to forward between target and client
> socket, and unfortunately it seems virStream Python binding object does
> not provide a FD for use to select(). So we can not use
> "virDomain.openConsole()" but to parse the guest XML in Kimchi, and find
> the back-end of the first serial device ourselves.

We do not import the websockets code anymore. Instead of that we depends 
on its package.
So I don't think depending on change its code is a good idea.