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