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

On 10/15/2014 03:15 AM, Zhou Zheng Sheng wrote: > on 2014/10/15 12:10, Zhou Zheng Sheng wrote: >> on 2014/10/14 21:45, Aline Manera wrote: >>> On 10/14/2014 07:04 AM, Yu Xin Huo wrote: >>>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/... >>>> >>>> >>>> >>>> Per my understanding: >>>> >>>> 1. To enable the serial console, it needs configuration on guest OS. >>>> >>>> / You must configure the virtualized operating system to output >>>> information to the virtual serial port.// >>>> // The serial port is called //|ttyS0|//on Linux or >>>> //|COM1|//on Windows./ >>>> >>>> It need to modify the |/boot/grub/grub.conf| file on guest OS and >>>> reboot guest. >>>> >>>> So VM must have OS already installed, seems like it needs the >>>> guest to be running. >>> Prior to do that guest OS configuration, the guest must have the serial >>> console set on its XML. >>> >>> <serial type='pty'> >>> <target port='0'/> >>> </serial> >>> <console type='pty'> >>> <target type='serial' port='0'/> >>> </console> >>> >> I found that Fedora can scan and use ttyS0 as terminal >> automatically, so save the user from manually editing grub config. This >> is not often used, but it's handy when troubleshooting, or when the >> network is too slow to support an VNC/Spice session. >> >>> So the idea is providing a way to user to choose between spice, vnc or >>> serial and Kimchi will setup the guest XML accordingly. >>> >> However I don't think spice/vnc and serial are exclusive options. Spice >> and VNC are alternative to each other but serial should be a complement, >> mainly for troubleshooting. If a newly created guest doesn't have >> spice/vnc, and only contains serial port, it may not be able to install >> OS successfully, because not all Linux installation programme support >> serial console mode. Since the user has to modify kernel argument before >> using a serial port, if without vnc/spice, how can user edit the kernel >> argument. >> >> It's true the real servers does not have display and keyboard, but the >> admin can use KVM (Keyboard Video Mouse facilities) to connect to the >> server video display, or use something like IMM on IBM X servers. >> >> I notice that by default, guest created by virt-manager contains a >> serial port. I think we can follow the same idea. We could always >> provide vnc/spice and serial port. vnc/spice is for main use, serial >> port is for troubleshooting. >> >>> For reference: >>> - >>> http://rwmj.wordpress.com/2011/07/08/setting-up-a-serial-console-in-qemu-... >>> >>> >>> - http://libvirt.org/formatdomain.html#elementsConsole >>> >>>> 2. The serial console can be accessed with 'virsh console' or 'use >>>> |virt-manager| to display the virtual text console'. >>>> >>>> So the target of this work item is to add a 'web command line >>>> console' in kimchi UI to access the 'serial console'? >>>> >>>> |||| >>> We could try to find an AJAX text console to enable serial console view >>> direct on Kimchi (the same virt-manager does) >>> So if the guest is configured with serial console and user clicks on >>> "Connect" we open the text console in a new tab. >>> But unless we find this AJAX text console done in an open source >>> project, I don't expect to have it for 1.4 release. >>> >> I found that in websockify source code, there is a wspty. It is a >> terminal implemented in HTML and js. I was once in oVirt community, at >> that time I was able to build a serial console solution using this >> wspty. However I found that there some bugs, some keys are not >> interpreted correctly. Maybe we can have a look at this wspty? If it's >> good we can submit bug fixes to websockify. >> >> The console solution once I implemented was like this. >> guest serial port -> qemu char devices -> host pty >> >> Then I made a proxy to open this pty and forward the data to an HTTP >> long connecion. >> host pty -> proxy ---(HTTP)--> wspty >> >> wspty is using websocket, I changed it a little bit to use raw HTTP >> instead. >> >> For this part, I have a prototype repository on github, maybe you can >> have a look. There are instructions on how to setup a guest and using a >> proxy and wspty to access it's serial port. >> >> https://github.com/edwardbadboy/ptyforward/blob/master/README > Ha ha, I just found in this repository, I also wrote an websocket proxy > to forward pty to websocket. The websocket and web server was based on > ws4py + WSGI + gevent, in just 113 lines of Python. This repository is > too old I almost forget it. Glad to know it! Do you want to test this integration into Kimchi? And check how it will work? If we don't find a lot of bugs we could do it for 1.4

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