[Xen-users] drbd 8 primary/primary and xen migration on RHEL 5

[Antibozo <xen-users@xxxxxxxxxxxx>]

Greetings.

I've reviewed the list archives, particularly the posts from Zakk, on 
this subject, and found results similar to his. drbd provides a 
block-drbd script, but with full virtualization, at least on RHEL 5, 
this does not work; by the time the block script is run, the qemu-dm has 
already been started.
Instead I've been simply musing the possibility of keeping the drbd 
devices in primary/primary state at all times. I'm concerned about a 
race condition, however, and want to ask if others have examined this 
alternative.
I am thinking of a scenario where the vm is running on node A, and has a 
process that is writing to disk at full speed, and consequently the drbd 
device on the node B is lagging. If I perform a live migration from node 
A to B under this condition, the local device on node B might not be in 
sync at the time the vm is started on that node. Maybe.
If I use drbd protocol C, theoretically at least, a sync on the device 
on node A shouldn't return until node B is fully in sync. So I guess my 
main question is: during migration, does xend force a device sync on 
node A before the vm is started on node B?
A secondary question I have (and this may be a question for the drbd 
folks as well) is: why is the block-drbd script necessary? I.e. why not 
simply leave the drbd primary/primary at all times--what benefit is 
there to marking the device secondary on the standby node?
Or am I just very confused? Does anyone else have thoughts or experience 
on this matter? All responses are appreciated.
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users