[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 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@xxxxxxxxxxxxx > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |