On Tue, Feb 12, 2019 at 10:56:58AM +0800, Stefan Hajnoczi wrote:
> I'll return to this issue on Monday.
I have played around with posix_fadvise(POSIX_FADV_DONTNEED) and
measured 100+ millisecond latencies. This is not a great primitive to
rely on during migration downtime since it can be slow.
O
Hi Neil,
I'll return to this issue on Monday.
Stefan
signature.asc
Description: PGP signature
On Friday, February 8, 2019 4:48:19 AM EST Dr. David Alan Gilbert wrote:
> * Stefan Hajnoczi (stefa...@redhat.com) wrote:
> > On Thu, Feb 07, 2019 at 05:33:25PM -0500, Neil Skrypuch wrote:
> >
> > Thanks for your email!
> >
> > Please post your QEMU command-line.
For the test VM, we're using the
* Stefan Hajnoczi (stefa...@redhat.com) wrote:
> On Thu, Feb 07, 2019 at 05:33:25PM -0500, Neil Skrypuch wrote:
>
> Thanks for your email!
>
> Please post your QEMU command-line.
>
> > The clock jump numbers above are from NTP, but you can see that they are
> > quite
> > close to the amount of
On Thu, Feb 07, 2019 at 05:33:25PM -0500, Neil Skrypuch wrote:
Thanks for your email!
Please post your QEMU command-line.
> The clock jump numbers above are from NTP, but you can see that they are
> quite
> close to the amount of time spent in raw_co_invalidate_cache. So, it looks
> like flus
We (ab)use migration + block mirroring to perform transparent zero downtime VM
backups. Basically:
1) do a block mirror of the source VM's disk
2) migrate the source VM to a destination VM using the disk copy
3) cancel the block mirroring
4) resume the source VM
5) shut down the destination VM gr
