Re: [Qemu-devel] [RFC] postcopy livemigration proposal

[Avi Kivity]

On 08/08/2011 06:29 PM, Anthony Liguori wrote:
> > > > - Efficient, reduce needed traffic no need to re-send pages.
> > >
> > > It's not quite that simple. Post-copy needs to introduce a protocol
> > > capable of requesting pages.
> >
> > Just another subsection.. (kidding), still it shouldn't be too
> > complicated, just an offset+pagesize and return page_content/error
>
> What I meant by this is that there is potentially a lot of round trip 
> overhead.  Pre-copy migration works well with reasonable high latency 
> network connections because the downtime is capped only by the maximum 
> latency sending from one point to another.
>
> But with something like this, the total downtime is 
> 2*max_latency*nb_pagefaults.  That's potentially pretty high.

Let's be generous and assume that the latency is dominated by page copy 
time.  So the total downtime is equal to the first live migration pass, 
~20 sec for 2GB on 1GbE.  It's distributed over potentially even more 
time, though.  If the guest does a lot of I/O, it may not be noticeable 
(esp. if we don't copy over pages read from disk).  If the guest is 
cpu/memory bound, it'll probably suck badly.

> So it may be desirable to try to reduce nb_pagefaults by prefaulting 
> in pages, etc.  Suffice to say, this ends up getting complicated and 
> may end up burning network traffic too.

Yeah, and prefaulting in the background adds latency to synchronous 
requests.

This really needs excellent networking resources to work well.

--
error compiling committee.c: too many arguments to function