From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: Suggestion for merging xl save/restore/migrate/migrate-receive Date: Tue, 24 Sep 2013 12:46:52 -0400 Message-ID: <20130924164652.GC13979@phenom.dumpdata.com> References: <523337AA.5080103@oracle.com> <5237291C.9090100@oracle.com> <21047.12251.625579.745154@mariner.uk.xensource.com> <523742B3.5040204@oracle.com> <523811E8.6080304@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <523811E8.6080304@eu.citrix.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: George Dunlap Cc: Zhigang Wang , Ian Jackson , xen-devel List-Id: xen-devel@lists.xenproject.org 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] > >>> > >>> 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. > > ...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