TOPIC:

No additional partitioning is required when manually entering the storage path during installation. Usually the raw block device (in your case /dev/sda3) is passed in. When you create a new SR, XenServer will layer LVM on top of that. Perhaps double stacking LVM is causing an issue with the LVM filters due to the installer not knowing about the extra LVM layer that needs to be filtered.

Can you try again, only this time do not create a partition on /dev/sda3.

Regarding cases where XenServer skips creating a local SR on install. We have seen that with older HP RAID controllers. Mostly G5 servers I think. If that continues to happen, just pass in /dev/sda3 when prompted.

---

| Enter full path to backing block device to be |
| used for HA storage and press <Enter> (ex. /dev/sdb) |

---

/dev/sda3
Block device - invalid path! Exiting


So i try now to create just a basic linux partition and see if this help.

Also after creating the floating ip in the script the bonded network is not more pingable (sometimes). After restarting tool stack on the master its working again

so it was the same error with linux partition type 0700.

To be sure this is not the issue, i've recreated the logical volume and split it up and use the raw device /dev/sdb.

now when i change the role, i need to reload tgtd on the new master host, otherwise the vm hangs. when reloading the vms starts responding straight away. in the messages log i can see it says tgt started: OK. Which of the ha-cfg setting is related to tgtd? XAPI_COUNT ? For me it seems it get started to early, when reloading the service the vm starts responding straight away.

nope still not working

iscsi-ha acts as a watchdog for TGT and starts/stops it as necessary depending on which host is exposing the storage. There is no setting for it in the config. The start order is hardcoded to precisely start in this order when exposing the storage:
1 - DRBD - promote resource to primary
2 - Start TGT
3 - Make the floating IP live

Can you provide a copy of /var/log/messages from the slave that promotes itself to master. That may shed some light.

We have had occasional reports of the bond failing to respond at times but have not been able to reliable reproduce it. Restarting XAPI as you have done seems to remedy it.

Here you go this is the log from slave that becomes master role.

somehow i cannot attach logs?