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

[Stefan Berger <stefanb@xxxxxxxxxx>]

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:

func="$typ"_migration_step
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 
> 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.)

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.

   Stefan
> 
> 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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel