From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: Suggestion for merging xl save/restore/migrate/migrate-receive Date: Mon, 16 Sep 2013 17:05:20 +0100 Message-ID: <52372C40.1090704@eu.citrix.com> References: <523337AA.5080103@oracle.com> <5237291C.9090100@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5237291C.9090100@oracle.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: Zhigang Wang Cc: Ian Jackson , xen-devel List-Id: xen-devel@lists.xenproject.org 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 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] -f vm.chk > > Or:: > > # xl save [-c] >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 | ssh root@ 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 ` to > call the above command. > > - To migrate a VM using dedicated migrate receive daemon:: > > # xl save -c | socat - TCP::8004" > > Or with SSL:: > > # xl save -c | socat - OPENSSL::8005,verify=0 > > - Localhost migration:: > > # xl save | xl restrore > > - Localhost live migration:: > > # xl save -c | 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 > > * 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