On 29.01.2013, at 17:20, Brian Jackson wrote:

> On Tue, 29 Jan 2013 15:16:13 +0200
> Andres Toomsalu <[email protected]> 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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to