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

[Michael Paesold <mpaesold@xxxxxx>]

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]".
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.)
I appreciate your comments and suggestions.

Best Regards,
Michael Paesold

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel