Re: Suggestion for merging xl save/restore/migrate/migrate-receive

[George Dunlap <george.dunlap@eu.citrix.com>]

On 16/09/13 16:51, Zhigang Wang wrote:
> On 09/16/2013 06:04 AM, George Dunlap wrote:
>> On Fri, Sep 13, 2013 at 5:04 PM, Zhigang Wang <zhigang.x.wang@oracle.com> wrote:
>>> Hi,
>>>
>>> As we talked in
>>> http://lists.xen.org/archives/html/xen-devel/2013-09/msg00211.html , I have a
>>> suggestion: what about merging xl save/restore/migrate/migrate-receive?
>>>
>>> Here is the description: xl-migrate.rst
>> Thanks for bringing this up, but this thing with attaching files that
>> actually contain your proposal isn't really going to work.  Can you
>> please resend this with your proposals in-line, so that 1) the entire
>> discussion can happen in the mail reader, rather than having to switch
>> back and forth between an editor and a reader, 2) people can comment
>> in-line on the proposals?
>>
>> Thanks,
>>   -George
>>
> Thanks George for the comment. Here it is:

Thanks.

> * Merge `xl migrate/migrate-receive` to `xl save/restore`:
>
>    - To save a VM::
>
>        # xl save [-c] <domain> -f vm.chk
>
>      Or::
>
>        # xl save [-c] <domain> >vm.chk
>
>    - To restore a VM::
>
>        # xl restore -f vm.chk
>
>      Or::
>
>        # cat vm.chk | xl restore
>
>    - To migrate a VM using ssh/sshd::
>
>        # xl save -c <domain> | ssh root@<remote-host> xl restore

I don't necessarily mind *adding* an interface like this, if it can be 
made to work, but I definitely don't think that we should be replacing 
"xl migrate" with this interface; this is too techy, and not really at 
all like the rest of the xl interface.

But what I think would be better is to implement the two other 
transports you mention -- ssl and no encryption.

>
>      We can implement a wrapper to make `xl migrate <domain> <remote-host>` to
>      call the above command.
>
>    - To migrate a VM using dedicated migrate receive daemon::
>
>        # xl save -c <domain> | socat - TCP:<remote-host>:8004"
>
>      Or with SSL::
>
>        # xl save -c <domain> | socat - OPENSSL:<remote-host>:8005,verify=0
>
>    - Localhost migration::
>
>        # xl save <domain> | xl restrore
>
>    - Localhost live migration::
>
>        # xl save -c <domain> | xl restrore
>
>    Patch: I don't have the capability and time to implement it yet.
>
>
> ---- xl-migrate-socat.rst ----
>
> ==========
> XL Migrate
> ==========
>
> :Date: 2013-09-16
>
> Current Status
> ==============
>
> * xl migrate leverages ssh/sshd::
>
>        xl migrate <domain> <host>
>
> * In order to migrate a VM without user interactive, we have to configure ssh
>    keys for all Servers in a pool. Key management with dynamic Server Pools is
>    error prone.
> * In certain cases, customers need non-ssl migrate, which greatly improves the
>    migration speed. There's no way to do it with ssh.

Just to make sure I understand correctly then: you're throwing 
authentication out the window, assuming that the host network is 
entirely trusted -- even when using ssl?

  -George