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

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Tue, Sep 17, 2013 at 09:25:12AM +0100, George Dunlap wrote:
> On 09/16/2013 06:41 PM, Zhigang Wang wrote:
> >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.
> 
> ...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 ?

Thanks.
>  -George
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel