On 29.01.2013, at 17:20, Brian Jackson wrote: > On Tue, 29 Jan 2013 15:16:13 +0200 > Andres Toomsalu <andres@xxxxxxxxxxxxxxxxx> wrote: > >> But is there any other projects in (planned) development with the >> same goal(s)? > > > I haven't heard of any. But then again, a lot of things get developed > in secret and then dumped on the community. Sure. > > >> Im just really puzzled that while QEMU/KVM being kind a >> mature solution already no true fault tolerance/HA solutions exist >> (Im aware about stateless HA solutions with RHCS etc stacks - but >> its hardly the "true" HA) - and if I get it correctly - no real >> plans/development in that direction also near-term? > > > Most people that I know that have tried similar solutions on other > products give up on it because the performance is abysmal. It's > generally faster and better tested to do this stuff at the application > layer. I've been looking into (somewhat) hypervisor agnostic solutions - eg general linux checkpoint-restore solutions - like DMTCP (dmtcp.sf.net) and CRIU (criu.org). There is actually proof-of-concept DMTCP implementation for KVM - described in this paper: http://arxiv.org/pdf/1212.1787v1.pdf CRIU currently supports only linux containers (OpenVZ, LXC) - but probaly it would be possible to add support also for QEMU/KVM by similar approach as DMTCP KVM plugin does it. If I understand correctly DMTCP approach is a kind of non-blocking solution with possibly acceptable perfomance tradeoff. I would see great benefit of having kind of a "generic" checkpoint/restore mechanism with support for multiple hypervisors - which could be basis also for a future fault tolerance/HA solutions. > > >> >> Kind regards, > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
