>> There did not have to be a negative location constraint up to now, >> because the cluster took care of that. > > Only because it didn't work correctly.
Okay. >> Actually, this is a wanted setup. It happened that VMs configs were >> changed in ways that lead to a VM not being startable any more. For that >> case, they wanted to be able to start the old config on the other node. Please, notice _they_ vs. _me_ here :) > Wow! So, they can have different configurations at different > nodes. Agreed, wow! > The only issue you may have with this cluster is if the > administrator erronously removes a config on some node, right? > And that then some time afterwards the cluster does a probe on > that node. And then again the cluster wants to fail over this VM > to that node. And that at this point in time no other node can > run this VM and that it is going to repeatedly try to start and > fail. And that "failed start is fatal" isn't configured. No doubt > that this could happen, but what's the probability? And, finally, > that doesn't look like a well maintained cluster. I guess this is something _they_ have to live with then. At first glance, I honestly thought this was a change in the agent that introduced a regression that not only this configuration would hit, but you made me realize that it does not, but that it does improve the agent for sane setups. My vote goes for your patch, ie "stop && no config = return SUCCESS" Thanks Dominik _______________________________________________________ Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
