I'm running mirror mode on a pair of VMs and haven't noticed any issues with replication.  If you're using VMware ESX/ESXi 3.5, I recommend configuring Linux guests with the kernel boot parameter "clocksource=acpi_pm" and configuring VMware Tools to handle clock management in the guest.  Verify NTP isn't running in the guest.  Also, making sure the Linux kernel periodic interrupt timer runs at 100 Hz instead of 250 or 1000 Hz can reduce timing issues.  VMware provides some documentation on best practices for performance tuning I'd recommend reading.

On Thu, Jun 25, 2009 at 12:16 AM, Mathieu MILLET <ldap@htam.net> wrote:
On Tue, 23 Jun 2009 09:36:23 +0100, Fernando Silva
<fernandolrsilva@gmail.com> wrote:
> Hi all,

Hi

> I'm trying to setup a Mirror Mode configuration using 2 machines running
> OpenLDAP v2.4.11 on both. To make things easy both machines are on the
> same (private) network.
>
> [snip]
> mirrormode on
>
> I'm using Ubuntu 8.10 inside a VMWare image, but both images are running
> on independent machines and the network on both is Bridge Mode.

>From previous experiment, especially with OpenLDAP 2.4.11, I have very hard
time with making OpenLDAP N-way replication working on VM, especially
VMWare-based ones.

The main problem was with the management of the system clock, where VMWare
was making the clock slower and then make a "jump" to compensate the
slowiness. So, I got a lot of line "new modification with older timer
value" (can't remember the precise log line, though).

I had to switch to plain physical server (which was my target by then).

> All
> seems well according to OpenLDAP manual, but maybe I'm missing
> something. I start both servers using "slapd -d sync" in order to filter
> only the sync part.
>
> I created a script to insert 200 employees in my directory, to force the
> servers to sync up. When I start both servers and insert the employees
> in machine 1, I get this too much lines with this sample:
> slap_queue_csn: queing 0xb6851b4a
20090623082909.571025Z#000000#000#000000
> slap_graduate_commit_csn: removing 0xb82165c8
> 20090623082909.571025Z#000000#000#000000
>
> So the CSN is being created (I think), but there's no sync to machine 2,
> which makes me frustated. . .
>
> I'd appreciate any comments you can have, especially if you already have
> this kind of setup running.
>
> Best regards,
> Fernando

Hope it can help.
Sincerely yours, Mathieu MILLET.