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

[Aline Manera]

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

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.