From xen-devel-bounces@lists.xen.org Tue Sep 17 09:28:19 2013 Received: (at maildrop) by bugs.xenproject.org; 17 Sep 2013 08:28:20 +0000 Received: from lists.xen.org ([50.57.142.19]) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1VLqdv-0007SX-UL for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Tue, 17 Sep 2013 09:28:19 +0100 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VLqb7-0001Oi-7p; Tue, 17 Sep 2013 08:25:25 +0000 Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VLqb5-0001Oc-IT for xen-devel@lists.xen.org; Tue, 17 Sep 2013 08:25:23 +0000 Received: from [85.158.143.35:5272] by server-3.bemta-4.messagelabs.com id BC/19-08835-2F118325; Tue, 17 Sep 2013 08:25:22 +0000 X-Env-Sender: George.Dunlap@eu.citrix.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1379406321!4662536!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n X-StarScan-Received: X-StarScan-Version: 6.9.12; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29123 invoked from network); 17 Sep 2013 08:25:22 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-14.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 17 Sep 2013 08:25:22 -0000 X-IronPort-AV: E=Sophos;i="4.90,921,1371081600"; d="scan'208";a="54575322" Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net) ([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP; 17 Sep 2013 08:25:20 +0000 Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id 14.2.342.4; Tue, 17 Sep 2013 04:25:20 -0400 Received: from gateway-cbg.eng.citrite.net ([10.80.16.17] helo=[0.0.0.0]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1VLqb1-0003WU-Lr; Tue, 17 Sep 2013 09:25:20 +0100 Message-ID: <523811E8.6080304@eu.citrix.com> Date: Tue, 17 Sep 2013 09:25:12 +0100 From: George Dunlap User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Zhigang Wang References: <523337AA.5080103@oracle.com> <5237291C.9090100@oracle.com> <21047.12251.625579.745154@mariner.uk.xensource.com> <523742B3.5040204@oracle.com> In-Reply-To: <523742B3.5040204@oracle.com> X-DLP: MIA2 Cc: Ian Jackson , xen-devel Subject: Re: [Xen-devel] Suggestion for merging xl save/restore/migrate/migrate-receive X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org 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... -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel