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

[Zhou Zheng Sheng]

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/html/Virtualization_Administration_Guide/sect-Virtualization-Troubleshooting_-Troubleshooting_with_serial_consoles.html
>>>
>>>
>>> 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-and-libvirt/
>>
>> - 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.

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