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

[Zhou Zheng Sheng]

on 2014/10/22 01:54, Aline Manera wrote:
> 
>>> 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?
> 

In this case, yes. It'll be a problem.

>> 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.
> 

I feel the same.

So the conclusion is that if we want to use websockify, we have to
invent some nasty workarounds. For example, use socat or some helper to
forward the pty/unix socket to 127.0.0.1:some_port, then have websockify
forward this port.