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

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

On 09/16/2013 12:20 PM, Ian Jackson wrote:
> Zhigang Wang writes ("Re: [Xen-devel] Suggestion for merging xl save/restore/migrate/migrate-receive"):
>> ---- xl-migrate.rst ----
> ...
>> * Current xl migrate command is not intuitive, especially the `-s` option::
>>
>>       # xl migrate
>>       Usage: xl [-v] migrate [options] <Domain> <host>
>>       
>>       Save a domain state to restore later.
>>       
>>       Options:
>>       
>>       -h              Print this help.
>>       -C <config>     Send <config> instead of config file from creation.
>>       -s <sshcommand> Use <sshcommand> instead of ssh.  String will be passed
>>                       to sh. If empty, run <host> instead of ssh <host> xl
>>                       migrate-receive [-d -e]
>>       -e              Do not wait in the background (on <host>) for the death
>>                       of the domain.
>>
>>   It's a little hard to adapt other tools as transport.
> 
> Perhaps the documentation needs to be improved.  But you can just say
>    xl migrate -s '' 42 'nc remotehost 1234'
> and in the receiving host's inetd.conf:
>    1234 stream tcp nowait root /usr/bin/xl xl migrate-receive
> (NB I haven't tested this).  If you want better logging then use a
> better superserver than inetd.
> 
>> * We have differnt implementation for `xl save/restore` and 
>>   `xl migrate/migrate-receive`. Can we merge them?
> 
> I'm afraid not.  The migration protocol includes a confirmation that
> the receiver is ready, to try to reduce the chance that a failed
> migration ends up killing the domain.
> 
>> Proposal
>> ========
>>
>> * Implement dedicated daemons for ssl and non-ssl migration receive 
>>   (`socat <http://www.dest-unreach.org/socat/>`_ can be used).
>>
>>   Example patch for dedicated migrate receive daemon:
>>   xen-xl-migrate-socat.patch
> 
> I think a one-line change to inetd.conf is probably better.  Your
> script is very complicated (and still throws away the error messages
> from xl migrate-receive rather than logging them).
> 
> As for the encrypted version: ssl has pretty awful security
> properties, at least by default, which you need to work around.  For
> example, the default usually involves the X.509 root certificate
> oligopoly, and doesn't provide forward secrecy.  If you need
> encryption, ssh has a much better security model.
> 
> If you don't need encryption and authentication then default mode of
> use for xl is rather heavyweight and you might want to use a simple
> unencrypted unauthenticated TCP session as I describe above.
> 
>> * 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.

Thanks,

Zhigang