TOPIC:

XCP 1.6

nosan_installer_1.4.7 script ran fine on both hosts, with all the green OKs, iSCSI floating IP is accessible...

but:

- local storage has not been removed from the XCP hosts
- iSCSI target has been found, but no LUN has been found

messages looks kinda bad:
user.log:Jul 2 09:44:54 xcp-gogol-1 iscsi-ha: 1892 DRBD Running on this host: version: 8.3.15 (api:88/proto:86-97) GIT-hash: 0ce4d235fc02b5c53c1c52c53433d11a694eab8c build by root@XCP-HA1, 2013-05-20 21:36:35 1: cs:Connected ro:Secondary/Secondary ds:Inconsistent/Inconsistent C r

---

ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:33552328
user.log:Jul 2 09:44:54 xcp-gogol-1 iscsi-ha: 1892 check_drbd_resource_state: DRBD Resource: iscsi1 in Secondary mode, expected in Primary mode
user.log:Jul 2 09:44:54 xcp-gogol-1 iscsi-ha: 1892 email: Duplicate message - not sending. Content = check_drbd_resource_state: DRBD Resource: iscsi1 in Secondary mode, expected in Primary mode
user.log:Jul 2 09:44:54 xcp-gogol-1 iscsi-ha-NOTICE-/etc/iscsi-ha/iscsi-ha.sh: Command 'drbdsetup 1 primary' terminated with exit code 17
user.log:Jul 2 09:44:54 xcp-gogol-1 iscsi-ha: 1892 DRBD Resource: iscsi1 failed transition to Primary
user.log:Jul 2 09:44:54 xcp-gogol-1 iscsi-ha: 1892 email: Duplicate message - not sending. Content = DRBD Resource: iscsi1 failed transition to Primary
user.log:Jul 2 09:44:54 xcp-gogol-1 iscsi-ha: 1892 DRBD Resource: iscsi1 in Connected state
Binary file xensource.log.1.gz matches

more logs available, I cat put them on pastebin, if anyone's interested

I have discovered later, that there's a failure initializing the DRBD:

---

| Initializing DRBD.. This host will wait until its peer connects. |
| Installation will resume after the DRBD peers connect |

---

1+0 beolvasott rekord
1+0 kiírt rekord
1048576 bájt (1,0 MB) másolva, 0,000803218 másodperc, 1,3 GB/mp
You want me to create a v08 style flexible-size internal meta data block.
There appears to be a v08 flexible-size internal meta data block
already in place on /dev/disk/by-id/scsi-SATA_VBOX_HARDDISK_VB99250c16-76e2fb69-part3 at byte offset 34358665216
Do you really want to overwrite the existing v08 meta-data?
[need to type 'yes' to confirm] yes

Writing meta data...
initializing activity log
NOT initialized bitmap
New drbd meta data block successfully created.
Starting DRBD resources: [ d(iscsi1) 1: Failure: (104) Can not open backing device.

[iscsi1] cmd /sbin/drbdsetup 1 disk /dev/disk/by-id/scsi-SATA_VBOX_HARDDISK_VB99250c16-76e2fb69-part3 /dev/disk/by-id/scsi-SATA_VBOX_HARDDISK_VB99250c16-76e2fb69-part3 internal --set-defaults --create-device failed - continuing!

The automated installer has not beed tested with XCP. Xenserver 6.2 and 6.5 are thoroughly tested and known to work well.

Since your local storage is not being removed by the installer, DRBD is unable to open the device. Consider using a later release of Xenserver instead of XCP. You can also try to manually remove the local storage before running the installer and then enter the path to the storage partition when prompted by the installer.

The issue is the same with xenserver. Istalling xenserver/XCP with a single harddrive creates LVM based storage which seems not to be well handled by the nosan-installer (or DRBD).

Installing with two drives (2nd is not selected for storage during install), and specifying that drive for the script helps.

halizzard service is active only on one of the hosts (the slave) when installation finished. Is it normal?

After succesfulkly added the HA storage, I still have issues with XEN HA, but that's another story.

We have not tried passing LVM based storage to DRBD in our environment and avoided it so that we are not stacking LVM twice onto the storage. Regardless, when the local XS storage is removed it hould leave behind a raw disk partition like /dev/sda3. You can try manually removing the local storage and then pass in the disk partition instead of LVM based path.

Also, if you are selecting 2 disks for local storage when installing XenServer, then the installer will fail since it is not written to deal with the 2 leftover block devices after the local SR has been removed. Were you perhaps selecting 2 backing disks for local storage during the XS installation?

Well, let's see this in more detail.

XCP:
- installation fails when there are two disks. Installer puts boot record on second disk.
- installing with single disk is ok, 2nd one can be added later
- installing on a single disk creates this:
/dev/sda1 4127440 1682316 2235460 43% /
none 388876 16 388860 1% /dev/shm
/dev/mapper/XSLocalEXT--d6bce256--d22f--5db2--dff2--ba1ff4c865ef-d6bce256--d22f--5db2--dff2--ba1ff4c865ef
33015664 180288 31158272 1% /var/run/sr-mount/d6bce256-d22f-5db2-dff2-ba1ff4c865ef

Providing the sr's block device to the nosan-installer results:
Writing meta data...
initializing activity log
NOT initialized bitmap
New drbd meta data block successfully created.
Starting DRBD resources: [ d(iscsi1) 1: Failure: (104) Can not open backing device.

[iscsi1] cmd /sbin/drbdsetup 1 disk /dev/disk/by-id/scsi-SATA_VBOX_HARDDISK_VB09009bc1-3714654b-part3 /dev/disk/by-id/scsi-SATA_VBOX_HARDDISK_VB09009bc1-3714654b-part3 internal --set-defaults --create-device failed - continuing!

SR is not removed from system, basically installation fails, although at the end of the installation process I got:
Synchronizing storage with peer/slave host1: State change failed: (-2) Need access to UpToDate data
Command 'drbdsetup 1 primary --overwrite-data-of-peer' terminated with exit code 17
Starting ha-lizard: [ OK ]
Starting ha-lizard-watchdog: [ OK ]

Starting iscsi-ha: [ OK ]
Starting iscsi-ha-watchdog: [ OK ]

Xenserver bahaves basically the same, the only difference, that it can handle both disks diring the installation.

Checking both disks in still makes the nosan-installer to fail.

The only working method I have found is:

- use two disks
- leave 2nd one untouched by the XENServer/XCP installer
- use /dev/sdb with nosal_installer

Works fast and with no issues, sr can be created on the HA iSCSI - but
- ha-lizzard service doesn't start on master when nosan-install finishes
- no working failover at all (maybe I skipped some steps when configuring the 1st created VM)
- XenManager looses the whole cluster if master XEN fails (but this is another issue I guess)