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