Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Thinking on this more, I'm no longer certain that host-level stonith is an appropriate first or second level of response. There is no such thing in this scenario as a DRBD resource which isn't solely devoted to a single KVM VM. So any logic that assures that only the appropriate VMs are started on each host, given the current circumstances, should be entirely adequate to the requirements - in all situation except one where one system as been unplugged from both LAN and crossover, and is suddenly plugged back in without a reboot. But the right logic there could be "If you loose sight of both LAN and crossover, reboot yourself; and if on reboot you still can't see either one, do not start any VMs." That is, "Shoot Yourself in the Head, not the Other Node, and if you get back up from that, get up slowly." If libvirt contained a way to make starting a VM conditional on it's not concurrently running elsewhere on a defined cluster that would be an ideal aid for this - but it doesn't currently. (I've requested it.) I suppose I could run multiple UCARP sessions over the crossover, one per VM (but running on the host), where each session gets a set of 3 IPs, on permanent to each side, and one to indicate which should have the VM currently running (the shared IP UCARP sets). Then by having the up and down scripts add some additional pings across LAN and crossover to make sure it's not that the crossover's down, and adding a small script for the Shoot Yourself in the Head action, this might just about cover it. Well, that and a regular schedule of backing up the VMs.... I _do_ expect someone to tell me how wrong this is. And I thank you in advance. Whit