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: Stefan Berger <stefanb@xxxxxxxxxx>
Subject: Re: [Xen-devel] [RFD] External device migration for block devices
From: Michael Paesold <mpaesold@xxxxxx>
Date: Fri, 21 Apr 2006 14:47:03 +0200
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 21 Apr 2006 05:47:39 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <OF19474EFA.FB9F34E7-ON85257157.004025C1-85257157.0042771F@xxxxxxxxxx>
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>
References: <OF19474EFA.FB9F34E7-ON85257157.004025C1-85257157.0042771F@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0.7-1.4.1.centos4 (X11/20051007)
Stefan Berger wrote:
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 04/21/2006 07:13:15 AM:
 > 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]

Yeah, that's a good way of doing it. I don't think the parent script should be bloated with all possible options for all device types.

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 think there are so many different types of block devices that it's infeasible for blkif.py to know about all of them. For example, if you use Cluster LVM and a SAN, you can have activated the LVs on all dom0s, so no migration is neccessary at all -- in such a case phy:/dev/vg/lv1 is available on all dom0s. In a different setup, phy:/dev/vg/lv1 might have some other backend that does need a migration procedure.

It might be possible to use the block device type (phy:,file:,nbd:,...) as argument to be passed to the migration script, but that means one also has to create a corresponding block-* script for hotplug (even if that doesn't do anything useful).

So "nbd:sdb,xvda,w" should use nbd-migrate.sh, and "drbd:drbd1,xvda,w" should use drbd-migrate.sh.

Is that a preferable solution?

Best Regards,
Michael Paesold

P.S. perhaps it's even better to pass "-type block -subtype drbd", so that a name of "block-drbd-migrate.sh" would be constructed, which would live next to "block-drbd" for hotplug.

Xen-devel mailing list

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