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:21:13 -0400 Message-ID: <52373E09.1090404@oracle.com> References: <523337AA.5080103@oracle.com> <5237291C.9090100@oracle.com> <21047.12251.625579.745154@mariner.uk.xensource.com> <5237346A.3020106@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5237346A.3020106@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: Ian Jackson , xen-devel List-Id: xen-devel@lists.xenproject.org On 09/16/2013 12:40 PM, George Dunlap wrote: > On 16/09/13 17:20, 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' > > Actually, that's a pretty bizarre interface -- I don't think I would > have gotten that from the help. > > If we had a new "transport" option that could take format strings, we > could even set the default transport in xl.conf, like so: > > migrate.default.transport="myssh %h %r" > > migrate.default.transport="nc %h 1234" > > migrate.default.transport="socat - OPENSSL:%h:8005,verify=0" > > (Where %h would be the remote host, and %r the remote command to execute > -- i.e., xl recieve.) > > Or of course: > > xl migrate -t "nc %h 1234" 42 remotehost > > Zhigang, would that work better for you guys? Yes. I think it's a improvement to the -s option anyways. I was thinking the same thing when I work on the example. With this, the example doesn't need the customized command any more (xl-migrate-command/xl-ssl-migrate-command). (But haven't decided how to do the migration yet; the socat just a example) Thanks, Zhigang