From mboxrd@z Thu Jan  1 00:00:00 1970
From: Mike McClurg <mike.mcclurg-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>
Subject: Re: [Xen-devel]  CrossPoolMigration
Date: Wed, 21 Dec 2011 08:39:45 +0000
Message-ID: <4EF19B51.50401@citrix.com>
References: <D14C52F5-9E35-43F1-9D0E-10336DB51BBD@UFL.EDU>
	<20111219082207.GE12984@reaktio.net>	<4EF0E48E.6010900@citrix.com>
	<CAG1y0seAdN1RiNBmFw-cNrKwAzdi83HaaSGtfCei8JXy31xE2w@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-api-bounces-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org>
In-Reply-To: <CAG1y0seAdN1RiNBmFw-cNrKwAzdi83HaaSGtfCei8JXy31xE2w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
List-Unsubscribe: <http://lists.xensource.com/mailman/options/xen-api>,
	<mailto:xen-api-request-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org?subject=unsubscribe>
List-Post: <mailto:xen-api-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org>
List-Help: <mailto:xen-api-request-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-api>,
	<mailto:xen-api-request-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org?subject=subscribe>
Sender: xen-api-bounces-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org
Errors-To: xen-api-bounces-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org
To: "Fajar A. Nugraha" <list-gqapnpqMBQ1eoWH0uzbU5w@public.gmane.org>
Cc: "xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org" <xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org>, ruijin zhou <zhourj-hnhdhkBXzx8@public.gmane.org>, "xen-api-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org" <xen-api-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org>
List-Id: xen-devel@lists.xenproject.org

On 21/12/11 03:10, Fajar A. Nugraha wrote:
> On Wed, Dec 21, 2011 at 2:39 AM, Mike McClurg <mike.mcclurg-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org> wrote:
>> Storage motion is something that we are prototyping for XCP/XenServer.
>> It will not be a part of the Xen hypervisor. We'll probably start more
>> work on the prototype in January, and we'll post details of our
>> implementation plan to this list.
> 
> Is still based on drbd and tap, as in the wiki page? If yes, it'd be
> ... interesting (to say the least) to see how these issues will be
> handled:
> - space for drbd metadata:
> http://www.drbd.org/users-guide/ch-internals.html#s-metadata
> - performance penalty and choice of replication modes:
> http://www.drbd.org/users-guide-emb/s-replication-protocols.html
> - general tap issues (qdisk vs module, vanilla vs patched 2.6.32, etc.)
> 

Thanks for those links. No, the current plan is not to use DRBD, though
I can't remember the reasons that Dave decided against it.