"Derek J. Balling" <[email protected]> writes: > On Jun 19, 2009, at 4:43 PM, [email protected] wrote: > > my big problem with live migration (especially as a disaster > > recovery 'solution') is that if the running machine dies it's too > > late to do a live migration. If the application is important enough > > to need failover and disaster recovery I need it to be able to > > survive a system just disappearing, and so I need it to be able to > > recover on the new machine without having the old machine available > > to migrate from, and if I have that anyway, why not use that instead > > of live migration? > > That's also a feature in the new version of ESX, what they call > "constant availability", where the state of the VM is maintained on > two different ESX hosts simultaneously. If the "live" one fails, the > "standby" unit takes over. If the standby unit fails, a different unit > in the resource pool takes over as "standby" and assumes the > responsibility of being "available".
Xen can do something similar with Project Kemari, which isn't mainline right now. Obviously, I have no idea how vmware does it, but I bet the concept is similar. Project Kemari works by essentially 'live migrating' the guest in question once every second or so, and never actually starting it up on the second host unless the primary goes down. the problem is that it's expensive in terms of resources. You are essentially running the same VM on two hosts, so you are using twice as much hardware as you would otherwise. The bandwidth required is also significant, and it still requires shared storage (if your shared storage goes down, you are still screwed.) Also, from what I understand, to get this feature of VMware, you have to pay licencing fees that cost more, usually, than just doubling your hardware. _______________________________________________ Discuss mailing list [email protected] http://lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
