Re: Suggestion for merging xl save/restore/migrate/migrate-receive

[Zhigang Wang <zhigang.x.wang@oracle.com>]

On 10/02/2013 10:19 PM, Matt Wilson wrote:
> On Wed, Sep 25, 2013 at 11:06:29AM +0100, George Dunlap wrote:
>> On Tue, Sep 24, 2013 at 5:46 PM, Konrad Rzeszutek Wilk
>> <konrad.wilk@oracle.com> wrote:
>>>>>>> * In order to migrate a VM without user interactive, we have to configure ssh
>>>>>>>   keys for all Servers in a pool. Key management brings complexity.
>>>>>>
>>>>>> Surely your automated server deployment system can manage this ?
>>>>>
>>>>> Yes, we can.
>>>>>
>>>>> keys are states; we need to make sure they are always sync. Also after this,
>>>>> all Servers in a pool can login to each other. I don't know whether it's
>>>>> a security issue for our product.
>>>>>
>>>>> This is something we try to avoid at this time.
>>>>
>>>> ...so instead of allowing anyone on one of the hosts log in, you're
>>>> going to allow anyone with access to the network to create a VM
>>>> without any kind of authentication?
>>>>
>>>> From a security perspective, that doesn't really sound like an
>>>> improvement...
>>>>
>>>
>>> How did this work with 'xend' and its migration using SSL? Was it as
>>> simple as this ?
>>
>> I have no idea -- Matt, do you know / would you care to take a look
>> and find out (since you have expressed a willingness to maintain
>> xend)?
> 
> It seems that you would just configure a ssl key file and cert file in
> xend-config.sxp
> 
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=0f26d15c
> 
> Zhigang: you wrote this code, correct?

Yes. That's only a very basic implementation.

The SSL relocation server will not do client cert verification and there's
no way to configure the client to use specific cert right now.

I think SSL cert verification could be a way for security. But you need distribute
the certs to all the servers in a pool and reload xend relocation server to
use the new certificate.

Thanks,

Zhigang