I'm not sure how experienced you are with scripting in *nix, nor am
I sure which, if either of the following suggestions would work, but I
thought I'd throw them out there since you haven't gotten any other
suggestions.
Suggestion 1: (Requires more xen knowledge, doesn't involve your
file-backed vbd directly, so easier to recover from). If you can make a
script create (and check for) a lock file on the shared file system during
domU creation and delete it during domU destruction (this is assuming python
scripts and not virt-manager ones, for them, you would need to do it on
startup and shutdown I guess), then you could theoretically abort creation
when said domU (read: lock file) already exists on the other machine (read:
shared file system). I'm not sure whether you could do this by duplicating
and editing the file or tap-aio scripts and/or if there is a way to call
custom scripts at the appropriate time from whichever config type you are
using, but since lock files are just blank files created to indicate usage,
this seems feasible. Additionally, in the event of an inappropriate
shutdown (where you know the domU isn't running on the other machine), you
could easily delete the lockfile manually.
Suggestion 2: (Requires less xen knowledge, but potentially trickier to
recover from). You could edit existing (or create new) service scripts, one
that checks for a lock file on the file-backed vbd before mounting it rw
(and "powers down" if it exists), a second one that creates said lock file
immediately after mounting rw, and a final one that deletes the lock file
just before switching to ro/unmounting on shutdown. This is riskier because
in the case of a crash you will have to get the partition in the file-based
vbd mounted to dom0 in order to delete the lock file (or you could have
runlevel 1 bypass the checking script, but that would be more dangerous
really, as one could boot into runlevel 1 while runlevel x was active on the
other dom0, and this would most likely lead to corruption). Additionally,
there would be potential for both instances of the domU to manage to check
for the lock file and continue forward before either had created it (really
unlucky timing starting the domU on both machines), and this would
undoubtedly lead to corruption.
I haven't tried either of these, but they might be worth looking into and or
trying (I do something similar to suggestion 2 for a Belkin UPS I am using
that doesn't support automatic resume from powered-off on power restoration,
as it was the workaround for those UPSes in NUTS [or whatever the UPS
program I am using is called, not at that machine right now]).
Good luck,
Dustin
-----Original Message-----
From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Wayde Nie
Sent: Friday, August 08, 2008 18:00
To: Xen Users
Subject: [Xen-users] lock domU file backed vbd's?
Hi Everyone,
Does anyone have suggestions on the best way to implement some sort of
interlock so that a VM with a file-backed vbd can only be started on one
node at any given time? I haven't had much luck with Google or the
archive searches so far...
Some background:
I've got a 2 node setup based on Debian Etch and the stock Debian Xen
3.0.3. Each node has local storage connected together in an
active-active drbd8 cluster with osfs2 and I'm using file backed vdb's
on the shared storage for my domU's.
I can start a domU on either node and live migration is working great.
Unfortunately, there doesn't appear to be any locking done on the file
backed vbd's which makes it a bit to easy to start a VM on both nodes at
the same time (trashing the disk file in the process...)
Any pointers would be appreciated!
Thanks,
Wayde.
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home