From xen-devel-bounces@lists.xen.org Mon Sep 16 18:44:10 2013 Received: (at maildrop) by bugs.xenproject.org; 16 Sep 2013 17:44:10 +0000 Received: from lists.xen.org ([50.57.142.19]) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1VLcqI-0006oM-9w for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Mon, 16 Sep 2013 18:44:10 +0100 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VLcnX-0000bm-6M; Mon, 16 Sep 2013 17:41:19 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VLcnV-0000bh-GV for xen-devel@lists.xen.org; Mon, 16 Sep 2013 17:41:17 +0000 Received: from [85.158.137.68:48994] by server-2.bemta-3.messagelabs.com id 45/51-14467-CB247325; Mon, 16 Sep 2013 17:41:16 +0000 X-Env-Sender: zhigang.x.wang@oracle.com X-Msg-Ref: server-14.tower-31.messagelabs.com!1379353274!2796850!1 X-Originating-IP: [141.146.126.69] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n X-StarScan-Received: X-StarScan-Version: 6.9.12; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11072 invoked from network); 16 Sep 2013 17:41:15 -0000 Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com) (141.146.126.69) by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Sep 2013 17:41:15 -0000 Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r8GHf97K027921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Sep 2013 17:41:11 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8GHf8uL015612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Sep 2013 17:41:09 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r8GHf8KT011897; Mon, 16 Sep 2013 17:41:08 GMT Received: from zhigang.us.oracle.com (/10.149.236.110) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 16 Sep 2013 10:41:08 -0700 Message-ID: <523742B3.5040204@oracle.com> Date: Mon, 16 Sep 2013 13:41:07 -0400 From: Zhigang Wang User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ian Jackson References: <523337AA.5080103@oracle.com> <5237291C.9090100@oracle.com> <21047.12251.625579.745154@mariner.uk.xensource.com> In-Reply-To: <21047.12251.625579.745154@mariner.uk.xensource.com> X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: George Dunlap , 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel