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

[Antibozo <xen-users@xxxxxxxxxxxx>]

On 2008-07-31 21:58, nathan@xxxxxxxxxxxx wrote:
> I am running DRBD primary/primary on Centos 5.2 with CLVM and GFS with 
> no problems. The only issue I have with live migration is that the arp 
> takes 10 - 15 sec to get refreshed so you lose connectivity during that 
> time. I have the problem with 3.0ish xen on Centos 5.2 as well as xen 
> 3.2.1.
One can run a job on the vm to generate a packet every second or two to 
resolve this; ping in a loop should do it.
My scenario doesn't involve any clustered filesystem. I'm using phy: 
drbd devices as the backing for the vm, not files. As far as I 
understand things, a clustered filesystem shouldn't be necessary, as 
long as the drbd devices are in sync at the moment migration occurs.
But the question remains whether that condition is guaranteed, and I 
hope to hear from someone who knows the answer to that question...
> Anyway, other then the ARP issue, I have this working in production with 
> about two dozen DomUs.
> Note: If you want to use LVM for xen rather then files on GFS/LVM/DRBD 
> you need to run the latest DRBD that supports max-bio-bvecs.
I'm actually running drbd on top of LVM. But I'll look into the 
max-bio-bvecs thing anyway out of curiosity.
Thanks for the reply.

> On Thu, 31 Jul 2008, Antibozo wrote:
> > 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