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

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

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.