TOPIC:

Following the next steps on the same document, I was able to repair the broken SR by following the steps presented by gheppy here (www.halizard.com/forum/software-support/...-unplugged-on-reboot)

In xencenter it shows as connected, however, if I do iscsi-cfg I cannot confirm it that works as it should as both indicates the DRBD connection as a Standalone state:

---

| iSCSI-HA Version IHA_2.1.4_29881 |
| Tue Jul 18 09:43:16 SAST 2017 |

---

---

| iSCSI-HA Status: Running 29595 |
| Last Updated: Tue Jul 18 09:43:10 SAST 2017 |
| HOST ROLE: SLAVE |
| VIRTUAL IP: 10.4.0.3 is not local |
| ISCSI TARGET: Stopped [expected stopped] |
| DRBD ROLE: iscsi1=Secondary |
| DRBD CONNECTION: iscsi1 in StandAlone state |

---

Control + C to exit

---

| DRBD Status |

---

---

| version: 8.4.5 (api:1/proto:86-101) |
| srcversion: 2A6B2FA4F0703B49CA9C727 |
| 1: cs:StandAlone ro:Secondary/Unknown ds:UpToDate/DUnknown r

---

|
| ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:904 |

---

At this stage the best I have been able to complete is that if the VM is on a slave server and the slave server restarts it automatically starts on the master.

If master however restarts then master does not reconnect to the storage repo and the individual VM's cannot start.

We can fix the issue with the steps above but that does not quite give high availability as it requires us to manually intervention.

I'm concluding my testing until I can hopefully get feedback.

You assertions in your initial post on the expected behavior are correct. Here are a few things to check.

- in a 2 node pool, you should not enable the xenserver high availability as that will disable ha-lizard's high availability and give you inconsistent results in your testing.

- in a simulated crash of the master, the slave will promote itself to the new master in about 30 seconds. Your inability to connect to the pool is due to xencenter trying to connect to the former master which is no longer available. To connect moreimmediately to the pool, try connecting to the ip of the new master from xencenter

- regarding broken iscsi, we have seen some issues when using bonded replication link. If you are running a bond, try disconnecting one of the bond interfaces to see if it clears up.

Thank you for your feedback! I've managed to get a working system now by following those finals steps in ((www.halizard.com/forum/software-support/...-unplugged-on-reboot)) - By disabling the autostart of ha-lizard and postponing the start with wait for about 2 minutes I have been able to test HA lizard fully.

I have also disabled HA in xencenter which was I believe the final missing piece in the puzzle.

I have realised that I need to grasp a better understanding of the individual components to better mitigate potential downtimes.

If you don't mind I'll keep posting any findings - I intend on moving some of our production VM's over the weekend so will conclude my testing today. Thank you in advance and for the great product!

I've noted in your documentation you indicate that:

Since this design does not allow primary/primary support
for DRBD, there is a low likelihood of data corruption should the pool become split.

In what scenario could this take place and to what extent would there be potential data corruption?