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:07:55 +0100 Message-ID: <52372CDB.3000409@eu.citrix.com> References: <523337AA.5080103@oracle.com> <5237291C.9090100@oracle.com> <52372C40.1090704@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <52372C40.1090704@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: Zhigang Wang Cc: Ian Jackson , xen-devel List-Id: xen-devel@lists.xenproject.org On 16/09/13 17:05, George Dunlap wrote: >> ========== >> 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? FWIW, I think XenServer (via xapi) manage to do the host ssh keys for a pool all right. But having an option to do the migration unencrypted, if you trust your network, seems like it might be a worthwhile option. -George