Hi, > Yes, and there is a simple reason for that: it's much faster than > vzmigrate. The checkpoint and restore can be completed in a matter of > seconds, and the incurred downtime is minimal. In HA configurations, > uptime is something people care about a lot, so it made sense to > implement it that way.
Yes, exactly. > Right. So the only thing you're saying is, rather than doing doing vzctl > stop during stop and vzctl chkpnt during migrate_from, you just always > want it to do vzctl chkpnt during stop, too? Well that's something we > can add to the existing RA -- again, no need to roll your own. > > Let me know if that's what you want, and then we can discuss how to best > implement it. Well, I am not sure it is a very correct way to do this. There are few issues. First, you might want the virtual machine to really stop - what then? You might not want live migration at all... so maybe you need to add some kind of parameter to specify whether user wants live migration for that resource. Another issue is that until the newest OpenVZ kernel (in which this is finally fixed), you might get kernel panic in some cases during restore. Also checkpoint might fail due to some reasons - the agent must know what to do then. There were a lot of issues with this until the last patch. Another, probably most important, thing is actually that this would be ideologically incorrect, since action "stop" is supposed to stop the resource, and actions "migrate_*" is supposed to migrate the resources. Thanks, Dmitry _______________________________________________ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker