WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-api

Re: AW: [Xen-API] cross-pool migrate, with any kind of storage (shared o

To: Uli Stärk <Uli.Staerk@xxxxxxxxxxxxxx>
Subject: Re: AW: [Xen-API] cross-pool migrate, with any kind of storage (shared or local)
From: George Shuklin <george.shuklin@xxxxxxxxx>
Date: Wed, 13 Jul 2011 20:03:44 +0400
Cc: Dave Scott <Dave.Scott@xxxxxxxxxxxxx>, "xen-api@xxxxxxxxxxxxxxxxxxx" <xen-api@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 13 Jul 2011 09:04:45 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; bh=+7CcoCUT+9v53RLHtIY/neZZ9oL1uMYopUNmAQo6nfM=; b=WvcQ2wqcnJRcVRVC2VnukMkKVUiCidgBD6pTcfVKoknb8oEITZFeewB0kI8aXfV5M3 l24aBwE0WiGMjjTclUCJXTToSsX3CuHMGDIdkFNR95hmbnga2s7ntTB4khwSnYtk68mo 4nlgOOkJ43ztfzJU/6oQRhE58Wx0mOXaATjfg=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <BD4874944A68BE4C92E66740829DD31619D7B6@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-api-request@lists.xensource.com?subject=help>
List-id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com>
List-post: <mailto:xen-api@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=unsubscribe>
References: <81A73678E76EA642801C8F2E4823AD21BC2D12C569@xxxxxxxxxxxxxxxxxxxxxxxxx> <1310569609.21838.15.camel@mabase> <BD4874944A68BE4C92E66740829DD31619D7B6@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-api-bounces@xxxxxxxxxxxxxxxxxxx
Yes, yes, I'm talking about putting every virtual machine disk to
StandAlone DRBD mode and reconfiguring it for replication to remote
side.

As alternative it can be 'migrable' flag for vdi (vbd?) which parsing
during plugging VBD and creating drbd device before any other operation.

... And one more question: why we can not do this on line? If we have
tapdisk code, it can suspend machine for few milliseconds, close
original device/file, open it 'through' DRBD and resume guest machines.
Because content of VDI is not changed (meta-data stored separately),
this will be completely transparent to guest machine.

... And this allow more interesting feature (we lacking right now) -
live cross-SR migration for virtual machine.

В Срд, 13/07/2011 в 15:25 +0000, Uli Stärk пишет:
> A simple copy-operation should not require a complex DRBD-setup.
> 
> DRBD would be nice for live migration. But you usually dont have a  
> drbd-device for each disk, so would have to re-attach the disk in order to 
> create a DRBD-device resulting in a vm-reboot (correct?). It would be nice to 
> have a default DRBD overlay-device for each disk, so you could start a 
> DRBD-Live-Migration at any time. It shouldn’t have a too big (software 
> interrupts?) performance impact  since the there is no Connection and further 
> no sync-logic until the device gets connected.
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: xen-api-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-api-bounces@xxxxxxxxxxxxxxxxxxx] Im Auftrag von George Shuklin
> Gesendet: Mittwoch, 13. Juli 2011 17:07
> An: Dave Scott
> Cc: xen-api@xxxxxxxxxxxxxxxxxxx
> Betreff: Re: [Xen-API] cross-pool migrate, with any kind of storage (shared 
> or local)
> 
> Wow! Great news!
> 
> And idea: why not use DRBD? It suits perfectly for replication changes 
> between two block devices, it will do all work, includes an dirty map 
> tracking, synchronous writing and replicating with controllable speed.
> 
> It also have different protocols for new writes replication: sync and async - 
> perfect for any kind of replication.
> 
> DRBD allows to keep  metadata  separately from media (disk is untouched by 
> drbd during operating).
> 
> The main disadvantage of DRBD is just and only TWO nodes - but this is 
> perfectly suites for task 'replicate from ONE node to SECOND').
> 
> And DRBD gurantee consistency between nodes, and it even supports 
> primary-primary mode, which allow as to make migration lag (when VM not
> operates) minimal.
> 
> And it supports online reconfiguration of peer!
> 
> I see no more perfect solution for this: it's already in product, in vanilla 
> kernel and it have everything we need.
> 
> 
> 
> В Срд, 13/07/2011 в 15:21 +0100, Dave Scott пишет:
> > Hi,
> > 
> > I've created a page on the wiki describing a new migration protocol for 
> > xapi. The plan is to make migrate work both within a pool and across pools, 
> > and to work with and without storage i.e. transparently migrate storage if 
> > necessary.
> > 
> > The page is here:
> > 
> > http://wiki.xensource.com/xenwiki/CrossPoolMigration
> > 
> > The rough idea is to:
> > 1. use an iSCSI target to export disks from the receiver to the 
> > transmitter 2. use tapdisk's log dirty mode to build a continuous disk 
> > copy program
> > -- perhaps we should go the full way and use the tapdisk block mirror code 
> > to establish a full storage mirror?
> > 3. use the VM metadata export/import to move the VM metadata between 
> > pools
> > 
> > I'd also like to
> > * make the migration code unit-testable (so I can test the failure 
> > paths easily)
> > * make the code more robust to host failures by host heartbeating
> > * make migrate properly cancellable
> > 
> > I've started making a prototype-- so far I've written a simple python 
> > wrapper around the iscsi target daemon:
> > 
> > https://github.com/djs55/iscsi-target-manager
> > 
> > _______________________________________________
> > xen-api mailing list
> > xen-api@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/mailman/listinfo/xen-api
> 
> 
> 
> _______________________________________________
> xen-api mailing list
> xen-api@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/mailman/listinfo/xen-api



_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api

<Prev in Thread] Current Thread [Next in Thread>