[Kimchi-devel] [PATCH 0/4] ticket support for guest

[Zhou Zheng Sheng]

on 2014/05/26 16:00, Yu Xin Huo wrote:
> On 5/26/2014 3:09 PM, Zhou Zheng Sheng wrote:
>> 于 2014年05月26日 15:01, Hongliang Wang 写道:
>>> On 05/26/2014 02:38 PM, Hongliang Wang wrote:
>>>> On 05/26/2014 02:27 PM, Zhou Zheng Sheng wrote:
>>>>> on 2014/05/26 13:32, Yu Xin Huo wrote:
>>>>>> I strongly dislike the way to change password frequently.
>>>>>>
>>>>>> Password is designed for user to recognize himself for
>>>>>> authentication.
>>>>>> Frequently changing password make password itself meaningless to
>>>>>> user.
>>>>>>
>>>>>> As it is VNC password, this will almost make vnc unaccessible to
>>>>>> user.
>>>>>> Personally, I dislike to use browser to console the VM at all.
>>>>>>
>>>>>> I suspect whether there is *a justification reasonable enough* to
>>>>>> take
>>>>>> the way that "changing password".
>>>>>>
>>>>>> So please exactly clarify what *threat* this "change password"
>>>>>> strategy
>>>>>> is protecting against?
>>>>>>
>>>>> Some back-end background.
>>>>>
>>>>> The problem is that noVNC and HTML5 Spice traffic is carried on
>>>>> websocket outside of Kimchi server. It operates as following.
>>>>>
>>>>> noVNC --websocket--> websockify --tcp-> VNC server of the hypervisor.
>>>>>
>>>>> Since Kimchi is out of this route, we don't have means to authenticate
>>>>> user. The user can copy the noVNC page URL to another machine without
>>>>> loggin to Kimchi, and he can still access VNC.
>>>> For this part, I'd prefer access VNC through any VNC viewer after I
>>>> created a VM, instead of only access it through Kimchi.
>>> I checked Virt Manager just now and it works the similar as your design
>>> for Kimchi. So is it possible if I want to access Kimchi VM through VNC
>>> clients (e.g., my browser is relatively too old to use noVNC) ? In this
>>> case, I think a possible solution is:
>>> 1. Create a VM with bridged network that I can access it from other
>>> machines
>>> 2. Install VNC server in it
>>> 3. Configuration the VNC server
>>> 4. Access it through VNC clients
>>>
>>> Does it make sense? So it will be a complete solution.
>> Feasible. A small problem is that it uses guest network. If the user
>> wrongly configures the guest network, he/she would lose remote video
>> connection. Before installing guest OS and VNC, there is no remote video.
>>
> Kimchi support 3 types of network, user will base on their real needs to
> configure VM's network. Not wrongly configured.
> For all these 3 types of network, the VM need VNC access.

Though I am not for this solution, it is always feasible to create an
extra bridge guest network for management purpose. Even for the
"isolated" type of network, it's possible to create a "isolated bridged
management network" using VXLAN or something like that. Another thing
you misunderstood me is that I meant wrongly configure the network
settings in the guest OS. So in all, my previous message is to say
though it's feasible to use guest network, it's not reliable for
management purpose.

-- 
Zhou Zheng Sheng / 周征晟
E-mail: zhshzhou at linux.vnet.ibm.com
Telephone: 86-10-82454397