[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Suggestion for merging xl save/restore/migrate/migrate-receive
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 ? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |