From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zhigang Wang Subject: Re: Suggestion for merging xl save/restore/migrate/migrate-receive Date: Mon, 16 Sep 2013 13:41:07 -0400 Message-ID: <523742B3.5040204@oracle.com> References: <523337AA.5080103@oracle.com> <5237291C.9090100@oracle.com> <21047.12251.625579.745154@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <21047.12251.625579.745154@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Jackson Cc: George Dunlap , xen-devel List-Id: xen-devel@lists.xenproject.org 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] >> >> Save a domain state to restore later. >> >> Options: >> >> -h Print this help. >> -C Send instead of config file from creation. >> -s Use instead of ssh. String will be passed >> to sh. If empty, run instead of ssh xl >> migrate-receive [-d -e] >> -e Do not wait in the background (on ) 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 `_ 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