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


Re: [Xen-devel] [RFD] External device migration for block devices

To: Michael Paesold <mpaesold@xxxxxx>
Subject: Re: [Xen-devel] [RFD] External device migration for block devices
From: Stefan Berger <stefanb@xxxxxxxxxx>
Date: Fri, 21 Apr 2006 08:06:01 -0400
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 21 Apr 2006 05:06:29 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <4448BE4B.7050806@xxxxxx>
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

xen-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 04/21/2006 07:13:15 AM:

> 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?

I think this is the best way of doing this. Currently the external device migration script only parses the parameters

-step <1,2,3>
-host <destination host>
-typ  <type of device {'vtpm',...}>
-domnam <name of domain to migrate>

which I thought were pretty generic for any kind of migration but not a complete list. If you don't want to extend the list of what is parsed in that script, the best would be to append '$*' to the call into the more specific migration scripts that would then if needed implement command line parameter parsing themselves again. This call currently looks like this:

eval $func $host $domname $step [$*  <- add]

So for vtpm it's first sourcing vtpm-migration.sh and afterwards calls the function vtpm_migration_step in that script.

> 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
> Examples:
> 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.)

If there's a difference between migrating these types of block devices then what you show is probably the best way of doing this. Otherwise if migrateability and which script to call can be recognized by the name of the device (sda1 vs drbd1 vs hda), then we could take that kind of intelligence and put it into XenD's blkif.py and take the configuration task away from the user.

> I appreciate your comments and suggestions.
> Best Regards,
> Michael Paesold
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
Xen-devel mailing list
<Prev in Thread] Current Thread [Next in Thread>