TOPIC:

2Host iSCSI-HA configuration IQN works LUN doesn't.

The statuses look good on both machines. I just not sure what needs to be done to get this to work.

Followed the instructions to the letter twice....

BR
Simon

Screeny Attached

This section....

- Edit /etc/lvm/lvm.conf and update filter to look something like this to reject reading LVM headers locally.
vi /etc/lvm/lvm.conf

- Update filter to (restrict local backing device and drbd device – adjust to your environment)
** Important – LVM Headers for iSCSI-HA storage must only be ready from /dev/iscsi **
“filter = [ "r|/dev/xvd.|", "r|/dev/VG_Xen.*/*|", "r|/dev/cciss/c0d1|", "r|/dev/drbd.*|"]”

- Set -> “write_cache_state=0”
- When done – erase the LVM cache to ensure cached data is not read by LVM.
rm –f /etc/lvm/cache/.cache && vgscan


Only the change I made was to be /dev/sdb

“filter = [ "r|/dev/xvd.|", "r|/dev/VG_Xen.*/*|", "r|/dev/sdb|", "r|/dev/drbd.*|"]”

Is that going to be ok?


UPDATE - MARCH 24, 2014
Just to fill you in, I rebuilt one of the node's from scratch this morning and I've managed to add a new SR with the virtual scsi IP and connected to the LUN successfully.

Thanks for all your help with this, very much appreciated.

Is this an HA-Lizard 2-node pool with local storage (as described here: halizard.com/images/pdf/iscsi-ha_2-node_...owto_1.3.7_final.pdf )?
If so, chances are the LVM filter settings are not correctly set.

Yes – this section is important for the iscsi target to be properly exposed to xenserver

If your backing device is /dev/sdb/ then your filter looks correct.

Next thing to look at – make sure DRBD is running and correctly configured.. You will need to make some changes to the drbd.conf example to match your environment – namely – hostnames, IP addresses, drbd device name and backing device – if these are not set correctly, DRBD will not expose the storage to TGT.

Hello,

we have the same problems. We followed your howto (1.3.7) step by step.

The error is: "drbdadm role iscsi1 exited with error code 20"

We are note shure in setting this parameters correctly:

in /etc/tgt/targets.conf
<target iqn.2013-05.com.yourdomain:yourhost>
is yourhost the name of the local host?

in /etc/drbd.conf
disk /dev/cciss/c0d1;
this means /dev/volumegroup/logicalvolume?

We think that drbd ist the problem.
We have installed SP1, XS62E014 and XS62ESP1002.

Thanks in advance

Guido

In the how-to - we build the cluster based on the parameters on page 9 of the howto. These will vary depending on your hardware and should be adapted to match your network and host HW configuration.

In answer to your question:

1) the hostname in targets.conf should not matter. The default should work or you can modify it to match your environment/domain. For more on that topic try searching iSCSI Qualified Name (IQN). This is not causing your problem however.

2) You should not be using "/dev/cciss/c0d1" in DRBD or other configuration areas such as LVM filters. "disk /dev/cciss/c0d1" is the path to the backing disk used in our how-to. You should adapt this to your hardware. Typically this would be something like "/dev/sdb" (assuming /dev/sda is used by the XenServer installation).

If you are unsure of the path to your backing device, try "fdisk -l"
Below is an example from a live host built using the same how-to **please-note**in this case /dev/sda is the disk for the XenServer install (dom0 and local storage) and /dev/sdb is used as iscsi/drbd storage. You can disregard any errors in the output..

*** Begin snippet ***

WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! The util fdisk doesn 't support GPT. Use GNU Parted.


Disk /dev/sda: 73.3 GB, 73372631040 bytes
256 heads, 63 sectors/track, 8885 cylinders
Units = cylinders of 16128 * 512 = 8257536 bytes

Device Boot Start End Blocks Id System
/dev/sda1 * 1 8886 71652959+ ee EFI GPT

Disk /dev/sdb: 900.1 GB, 900151926784 bytes
255 heads, 63 sectors/track, 109437 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/sdb doesn't contain a valid partition table

*** end snippet ***

Let us know if you continue to have trouble.

FYI - we are working on an automated installer that will perform the entire installation described in the how-to. This is currently pre-alpha. A release candidate should be available in a month or so.