Now that I have started using resource templates for my VMs (Thanks for this suggestion Lars!) I have added one simple colocation rule to my cluster
My VMs all use the @CBNXen resource template and I have: order virtual-machines-after-storage inf: storage-clone CBNXen colocation virtual-machines-with-storage inf: CBNXen storage-clone This should take care of all the ordering and colocation needs for my VMs Tom On 09/14/2013 07:14 AM, Lars Marowsky-Bree wrote: > On 2013-09-13T17:48:40, Tom Parker <[email protected]> wrote: > >> Hi Feri >> >> I agree that it should be necessary but for some reason it works well >> the way it is and everything starts in the correct order. Maybe >> someone on the dev list can explain a little bit better why this is >> working. It may have something to do with the fact that it's a clone >> instead of a primitive. > And luck. Your behaviour is "undefined", and will work for most of the > common cases. > > ":" versus "inf:" on the order means that, during a healthy start-up, > A will be scheduled to start before B. It does not mean that B will need > to be stopped before A. Or that B shouldn't start if A can't. Typically, > both are required. > > Since you've got ordering, *normally*, B will start on a node where A is > running. However, if A can't run on a node for any given reason, B will > still try to start there without collocation. Typically, you'd want to > avoid that. > > The issues with the start sequence tend to be mostly harmless - you'll > just get additional errors for failure cases that might distract you > from the real cause. > > The "stop" issue can be more difficult, because it might imply that A > fails to stop because B is still active, and you'll get stop escalation > (fencing). However, it might also mean that "A" enters an escalated stop > procedure itself (like Filesystem, which will kill -9 processes that are > still active), and thus implicitly stop "B" by force. That'll probably > work, you'll see everything stopping, but it might require additional > time from "B" on next start-up to recover from the aborted state. > > e.g., you can be lucky, but you also might turn out not to be. In my > experience, this means it'll all work just fine during controlled > testing, and then fail spectacularly under a production load. > > Hence the recommendation to fix the constraints ;-) > > > (And, yes, this *does* suggest that we made a mistake in making this so > easy to misconfigure. "But, hey, ordering and colocation are independent > concepts! The design and abstraction is pure!" And I admit that I guess > I'm to blame for that to a large degree ... If the most common case is > "A, then B + B where A", why isn't there a recommended constraint that > just does both with no way of misconfiguring that? It's pretty high on > my list of things to have fixed.) > > > Regards, > Lars > _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
