From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Paesold Subject: Re: [RFD] External device migration for block devices Date: Fri, 21 Apr 2006 14:47:03 +0200 Message-ID: <4448D447.9080706@gmx.at> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Stefan Berger Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Stefan Berger wrote: > xen-devel-bounces@lists.xensource.com 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 > -typ > -domnam > > 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] 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 > > 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. 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.