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