TOPIC:

And again I have the issue with the second server.
For some reason I can't start anything on the second server.
Detaching a disk and re-attaching it is something I have never done. How can I do this with no/minimal risk?

About the speed issue, I completely missed the reply.
But that's something I want to address later, when xenserver and HA-lizard are up and running again like they should.

christ neeskens wrote: And again I have the issue with the second server.
For some reason I can't start anything on the second server.
Detaching a disk and re-attaching it is something I have never done. How can I do this with no/minimal risk?

About the speed issue, I completely missed the reply.
But that's something I want to address later, when xenserver and HA-lizard are up and running again like they should.

And after a few reboot it is working again.
Really don't understand why this behavior is happening.

There is one issue after the reboots, but that's something I think I need to ask support for elsewhere.
I get a alert the ISCI-IQN for server 2 is missing, even though it's listed in the general tab and in the /etc/iscsi/initiatorname.iscsi config file

Was the host rebooted or was a crash simulated before this happened? We have seen this happen many times in various crash scenarios with XenServer (even without HA-lizard).

We have noticed that a XenServer host booting after a simulated crash may not attach the SR at all on a host. This appears to be related to the order in which services start after a crash. So, we introduced auto-plug-pbd in iscsi-ha to deal with this automatically. If an SR is disconnected we connect it. this is likely not what caused your issue, but worth mentioning.

The second scenario we see is that an SR is attached and "appears" ok, but the logical volume for the SR is not read by LVM. This has appeared for us occasionally after simulated crashes (with and without HA-Lizard). SO, we introduced replug-pbd in the latest version of iscsi-ha. You can run this tool by hand should this happen again. It may solve the problem. This is active in the latest version of iscsi-ha (1.2.16). You may be running a previous version. If so, download the latest tarball, extract files and move into the /iscsi-ha/scripts/ folder. In there you will see a script named "replug_pbd". The script simply checks for a logical volume for each iscsi SR. If the logical volume is not found it will unplug and plug the SR.

Lastly - you may want to check to ensure there are no stale cache files in LVM. This would cause some weird behavior. The latest version of the how-to has instructions for doing so. halizard.com/images/pdf/iscsi-ha_2-node_...to_1.2.14a_final.pdf

I'll have a look at those scripts.

For now I also have another problem...
Because I was busy with the servers I decided to install the latest 3 updates from xenserver which kept nagging in xencenter.

To bad this f* the kernel name (uname -r is now
[root@xenserver2 ~]# uname -r
2.6.32.43-0.4.1.xs1.8.0.839.170780xen
instead of
[root@xenserver1 ~]# uname -r
2.6.32.43-0.4.1.xs1.8.0.835.170778xen
) so drbd is now broken.

Any quick fix for this?
What I tried so far is symlink /lib/modules/2.6.32.43-0.4.1.xs1.8.0.835.170778xen/updates/drbd.ko
to
/lib/modules/2.6.32.43-0.4.1.xs1.8.0.839.170780xen/updates/drbd.ko

But of course this would have been to easy

It looks like Hotfix XS62E004 updates the kernel. New DRBD RPMs will need to be created in order to load DRBD with this kernel. You can make them yourself by following the instructions on the last page of this doc:
halizard.com/images/pdf/iscsi-ha_2-node_...to_1.2.14a_final.pdf

If you can wait a couple of days, we can post an updated version with support for this kernel version.

Building it isn't that difficult.
But I have 1 question regarding building it.
The binpkg.iso contains an older kernel-xen-devel, isn't this going to cause any problems?

Edit...
I'll just wait for the updated module just to be safe.
I tried doing it, but I get several errors when trying to do the yum install, for example Missing Dependency: glibc-headers = 2.5-107 is needed by package glibc-devel-2.5-107.i386 (base)
This could be resolved by installing glibc-devel-2.5-107.el5_9.1.i386.rpm also from the binpkg.iso

Next I was able to build the rdbd rpm's using drbd.spec
But drbd-km.spec doesn't want to build