[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Suggestion for merging xl save/restore/migrate/migrate-receive



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] <Domain> <host>
Save a domain state to restore later. Options: -h Print this help.
       -C <config>     Send <config> instead of config file from creation.
       -s <sshcommand> Use <sshcommand> instead of ssh.  String will be passed
                       to sh. If empty, run <host> instead of ssh <host> xl
                       migrate-receive [-d -e]
       -e              Do not wait in the background (on <host>) 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?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.