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/
Home Products Support Community News


[Xen-devel] Migration of block devices

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Migration of block devices
From: Rob Bradford <rob.bradford@xxxxxxxxxxxxxxx>
Date: Thu, 03 Aug 2006 15:08:31 +0200
Delivery-date: Thu, 03 Aug 2006 06:07:59 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

I've been looking at various techniques to allow the the migration of
the contents of the block device that a virtual machine is using from
one host to another. Our aim is to allow the complete migration of a
running virtual machine to its target including all the local persistent
storage it is using (i.e. operating system image, user data, etc).

One approach to achieve this I have heard mentioned is to proxy the
local interactions with the backing block device through a degraded
RAID1 array (using software RAID). The destination server then exports
its local destination block device (e.g. loopback file or LVM) via NBD
(network block device). This block device is hot added to the degraded
array and the data is synced from the original block device to the
destination. When the domain is migrated (using xm migrate) it can then
use the local block device from that point on. In order to allow future
migration from this point on the virtual machine must still access the
block device here via a proxying degraded RAID1 array.

Has anyone successfully done this? My initial attempts seem to show that
it should work in practise but I experienced some problems with
corrupted metadata in the filesystem.

A second approach that we have devised involves adding a small hook to
the vbd backend driver. This callback is fired in dispatch_rw_block_io
of the blkback driver. I then have a small driver that hooks a function
pointer into this callback and then records the struct phys_req in a
linked list. This is then access from userspace via a simple character
device. A userspace daemon then uses this information to read the blocks
that have changed from the physical device attached to the vbd. These
blocks are then sent to the destination server and then written to the
block device there. Since we are using file backed vbds we can make the
initial transfer using some existing mechanism (scp, netcat). My main
worry is that when I read from the loopback device for the file that it
might not reflect the update that has caused me to read the block in the
first place. Will a read from the /dev/loop? always return the most
recent version that the vbd backend has written?

Any further comments on this idea would be much appreciated.


Rob Bradford <rob.bradford@xxxxxxxxxxxxxxx>

Xen-devel mailing list

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