Re: [Qemu-devel] [RFC] COLO HA Project proposal

2014-07-09 Thread Michael R. Hines
On 07/03/2014 11:42 AM, Hongyang Yang wrote: I wonder if there is anyway to coordinate this between COLO, Michael Hines microcheckpointing and the two separate reverse-execution projects that also need to do some similar things. Are there any standard APIs for the heartbeet thing we can already

Re: [Qemu-devel] [RFC] COLO HA Project proposal

2014-07-08 Thread Hongyang Yang
Hi Michael, Thank you for paying attention on this. On 07/08/2014 02:06 PM, Michael R. Hines wrote: On 07/03/2014 11:42 AM, Hongyang Yang wrote: I wonder if there is anyway to coordinate this between COLO, Michael Hines microcheckpointing and the two separate reverse-execution projects tha

Re: [Qemu-devel] [RFC] COLO HA Project proposal

2014-07-04 Thread Dong, Eddie
> > Thanks Dave: > > Whether the randomness value/branch/code path the PVM and SVM > may > > have, It is only a performance issue. COLO never assumes the PVM and > > SVM has same internal Machine state. From correctness p.o.v, as if > > the PVM and SVM generate Identical response, we can view

Re: [Qemu-devel] [RFC] COLO HA Project proposal

2014-07-04 Thread Dong, Eddie
> > > > Let me clarify on this issue. COLO didn't ignore the TCP sequence > > number, but uses a new implementation to make the sequence number to > > be best effort identical between the primary VM (PVM) and secondary VM > > (SVM). Likely, VMM has to synchronize the emulation of randomization > >

Re: [Qemu-devel] [RFC] COLO HA Project proposal

2014-07-04 Thread Dong, Eddie
> > > > I didn't quite understand a couple of things though, perhaps you can > > explain: > >1) If we ignore the TCP sequence number problem, in an SMP machine > > don't we get other randomnesses - e.g. which core completes something > > first, or who wins a lock contention, so the output strea

Re: [Qemu-devel] [RFC] COLO HA Project proposal

2014-07-04 Thread Dr. David Alan Gilbert
* Dong, Eddie (eddie.d...@intel.com) wrote: > > > > > > Let me clarify on this issue. COLO didn't ignore the TCP sequence > > > number, but uses a new implementation to make the sequence number to > > > be best effort identical between the primary VM (PVM) and secondary VM > > > (SVM). Likely, VMM

Re: [Qemu-devel] [RFC] COLO HA Project proposal

2014-07-04 Thread Andreas Färber
Am 01.07.2014 14:12, schrieb Dr. David Alan Gilbert: > Are there any standard APIs for the heartbeet thing we can already > tie into? Maybe the http://www.linux-ha.org/wiki/Heartbeat daemon? Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guil

Re: [Qemu-devel] [RFC] COLO HA Project proposal

2014-07-04 Thread Dr. David Alan Gilbert
* Dong, Eddie (eddie.d...@intel.com) wrote: > > > > > > I didn't quite understand a couple of things though, perhaps you can > > > explain: > > >1) If we ignore the TCP sequence number problem, in an SMP machine > > > don't we get other randomnesses - e.g. which core completes something > > > f

Re: [Qemu-devel] [RFC] COLO HA Project proposal

2014-07-02 Thread Hongyang Yang
Hi David, On 07/01/2014 08:12 PM, Dr. David Alan Gilbert wrote: * Hongyang Yang (yan...@cn.fujitsu.com) wrote: Hi Yang, Background: COLO HA project is a high availability solution. Both primary VM (PVM) and secondary VM (SVM) run in parallel. They receive the same request from client, and

Re: [Qemu-devel] [RFC] COLO HA Project proposal

2014-07-01 Thread Dr. David Alan Gilbert
* Hongyang Yang (yan...@cn.fujitsu.com) wrote: Hi Yang, > Background: > COLO HA project is a high availability solution. Both primary > VM (PVM) and secondary VM (SVM) run in parallel. They receive the > same request from client, and generate response in parallel too. > If the response packets