[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH RFC 0/3] Checkpoint-assisted migration proposal
From: |
Amit Shah |
Subject: |
Re: [Qemu-devel] [PATCH RFC 0/3] Checkpoint-assisted migration proposal |
Date: |
Mon, 5 Oct 2015 14:29:21 +0530 |
On (Mon) 05 Oct 2015 [10:33:01], Thomas Knauth wrote:
> Hi Amit,
>
> On Tue, Sep 15, 2015 at 12:39 PM, Amit Shah <address@hidden> wrote:
> > Could you please include a file in the docs/ directory that documents
> > how this works, so it's easier to comment on the general idea?
>
> sure, we will add this.
Thanks!
> > From 'checkpointing', I was afraid this was going to use some
> > checkpoint-restore framework, but instead it's a new checkpointing
> > method that you're adding to qemu.
> >
> > Can you describe when checkpoints are taken, and what is checkpointed?
> > How is it stored on the disk?
>
> Checkpoints are taken after a migration (at the source). If a
> checkpoint exists at the destination, the VM's state is reconstructed
> from the local checkpoint as well as updated pages from the source.
> This checkpoint-assisted migration can be faster, if network is the
> bottleneck, and saves network bandwidth.
>
> We can, in principle, reuse the existing checkpoint format of QEMU.
> The current implementation writes its own checkpoint because it was
> less effort on our side. We write the VM's main memory into a single
> file.
>
> > I'm sure the patches have all the details, but it's easier to check
> > the soundness of the idea if there's a high-level doc that explains
> > this, and then we can discuss the finer points over patches.
>
> We've recently published a paper about the general idea and expected
> benefits for a number of workloads (
> http://se.inf.tu-dresden.de/pubs/papers/knauth2015vecycle.pdf )
I'll give it a look, thanks. I'm interested in knowing what workloads
benefit.
There was one outstanding question from Dave about collisions:
https://lists.gnu.org/archive/html/qemu-devel/2015-04/msg01614.html
Can you please address that in your next submission?
> > Overall, I think this approach can benefit some workloads, and since
> > it's not affecting a lot of common code, we could look at adding it.
> >
> > Also, apologies for not getting to this earlier.
>
> Kind regards,
> Thomas.
Thanks,
Amit