WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

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

To: Antibozo <xen-users@xxxxxxxxxxxx>
Subject: Re: [Xen-users] drbd 8 primary/primary and xen migration on RHEL 5
From: nathan@xxxxxxxxxxxx
Date: Thu, 31 Jul 2008 16:58:56 -0500 (CDT)
Cc: xen-users@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 31 Jul 2008 14:59:48 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <48922EEE.8050707@xxxxxxxxxxxx>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <48922EEE.8050707@xxxxxxxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Alpine 1.10 (LFD 962 2008-03-14)

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.

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.

<>
Nathan Stratton                                CTO, BlinkMind, Inc.
nathan at robotics.net                         nathan at blinkmind.com
http://www.robotics.net                        http://www.blinkmind.com

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


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users