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] [RFD] External device migration for block devices

To: Stefan Berger <stefanb@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] [RFD] External device migration for block devices
From: Michael Paesold <mpaesold@xxxxxx>
Date: Fri, 21 Apr 2006 13:13:15 +0200
Delivery-date: Fri, 21 Apr 2006 04:13:38 -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
User-agent: Mozilla Thunderbird 1.0.7-1.4.1.centos4 (X11/20051007)
Hi everyone, hi Stefan!

I want to use Stefan's work on device migration to implement block-device migration for devices, where the regular model (hotplug add/remove) does not work, i.e. when the device migration script is required.
I would like to get some feedback on my ideas.

1) Currently, the device migration script does not get device details for the device it should migrate, obviously because it's not needed for vtpm. On the other hand, there can be several block devices for each domain, and each might have to be handled differently. So the script needs to get the details for the device it should migrate.

Should I add a arguments to the device migration script, that will not be set for vtpm?

2) I think there should be some way to configure the migration capabilities of block devices using the domain config files. Some block device might be migrated automatically using regular hotplug add/remove (e.g. nbd/enbd). Others might not be migratable at all (e.g., phy:/dev/sdb). For my current use case (DRBD), I use phy:/dev/drbd. These devices are migratable, but Xend does not know this.

I don't think it is good if all this knowledge must be put into the migration scripts itself. So I suggest to add a device config option to explicitly tell Xend what to do on migrate.

I suggest adding optional parameters to the end of the block device definition, which is currently "phy:UNAME,DEV,MODE"; I would extend that to "phy:UNAME,DEV,MODE[,OPTIONS]".

phy:sdb,xvda,w,migrate=reject  # reject migration
nbd:sample,xvda1,r,migrate=ok  # migration is ok, done through hotplug
phy:drbd1,xvda,w,migrate=drbd  # migration script called with -type drbd
phy:sdb,xvda,r                 # ok is default, for backwards compatib.

The "reject" argument can be "reject", "ok", or any other string. In the latter case, it's assumed to be the type given to the migration script. (Which can be used to redirect this to a different shell script.)

I appreciate your comments and suggestions.

Best Regards,
Michael Paesold

Xen-devel mailing list

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