All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Denis Plotnikov <dplotnikov@virtuozzo.com>
Cc: quintela@redhat.com, armbru@redhat.com, qemu-devel@nongnu.org,
	pbonzini@redhat.com, den@openvz.org, dgilbert@redhat.com
Subject: Re: [PATCH v0 0/4] background snapshot
Date: Wed, 22 Jul 2020 10:50:34 -0400	[thread overview]
Message-ID: <20200722145034.GZ535743@xz-x1> (raw)
In-Reply-To: <20200722081133.29926-1-dplotnikov@virtuozzo.com>

Hi, Denis,

On Wed, Jul 22, 2020 at 11:11:29AM +0300, Denis Plotnikov wrote:
> Currently where is no way to make a vm snapshot without pausing a vm
> for the whole time until the snapshot is done. So, the problem is
> the vm downtime on snapshoting. The downtime value depends on the vmstate
> size, the major part of which is RAM and the disk performance which is
> used for the snapshot saving.
> 
> The series propose a way to reduce the vm snapshot downtime. This is done
> by saving RAM, the major part of vmstate, in the background when the vm
> is running.
> 
> The background snapshot uses linux UFFD write-protected mode for memory
> page access intercepting. UFFD write-protected mode was added to the linux v5.7.
> If UFFD write-protected mode isn't available the background snapshot rejects to
> run.
> 
> How to use:
> 1. enable background snapshot capability
>    virsh qemu-monitor-command vm --hmp migrate_set_capability background-snapshot on
> 
> 2. stop the vm
>    virsh qemu-monitor-command vm --hmp stop
> 
> 3. Start the external migration to a file
>    virsh qemu-monitor-command cent78-bs --hmp migrate exec:'cat > ./vm_state'
> 
> 4. Wait for the migration finish and check that the migration has completed state.

Thanks for continued working on this project! I have two high level questions
before dig into the patches.

Firstly, is step 2 required?  Can we use a single QMP command to take snapshots
(which can still be a "migrate" command)?

Meanwhile, we might also want to check around the type of backend RAM.  E.g.,
shmem and hugetlbfs are still not supported for uffd-wp (which I'm still
working on).  I didn't check explicitly whether we'll simply fail the migration
for those cases since the uffd ioctls will fail for those kinds of RAM.  It
would be okay if we handle all the ioctl failures gracefully, or it would be
even better if we directly fail when we want to enable live snapshot capability
for a guest who contains other types of ram besides private anonymous memories.

Thanks,

-- 
Peter Xu



  parent reply	other threads:[~2020-07-22 14:51 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-22  8:11 [PATCH v0 0/4] background snapshot Denis Plotnikov
2020-07-22  8:11 ` [PATCH v0 1/4] bitops: add some atomic versions of bitmap operations Denis Plotnikov
2020-07-22  8:11 ` [PATCH v0 2/4] migration: add background snapshot capability Denis Plotnikov
2020-07-23 22:21   ` Peter Xu
2020-07-22  8:11 ` [PATCH v0 3/4] migration: add background snapshot Denis Plotnikov
2020-07-23 22:15   ` Peter Xu
2020-07-29 12:27     ` Denis Plotnikov
2020-07-24  0:08   ` Peter Xu
2020-07-29 12:54     ` Denis Plotnikov
2020-07-29 16:58       ` Peter Xu
2020-07-27 16:48   ` Dr. David Alan Gilbert
2020-07-28  9:34     ` Denis Plotnikov
2020-07-29 13:27       ` Dr. David Alan Gilbert
2020-07-29 13:57         ` Denis Plotnikov
2020-07-22  8:11 ` [PATCH v0 4/4] background snapshot: add trace events for page fault processing Denis Plotnikov
2020-07-22 14:50 ` Peter Xu [this message]
2020-07-22 15:42   ` [PATCH v0 0/4] background snapshot Denis Plotnikov
2020-07-22 15:47     ` Denis Plotnikov
2020-07-22 16:30       ` Peter Xu
2020-07-23  8:03         ` Denis Plotnikov
2020-07-23 17:39           ` Peter Xu
2020-07-24  8:06             ` Denis Plotnikov
2020-07-24 16:31               ` Peter Xu
2020-07-27 16:59 ` Dr. David Alan Gilbert
2020-08-04 13:11   ` Zhanghailiang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200722145034.GZ535743@xz-x1 \
    --to=peterx@redhat.com \
    --cc=armbru@redhat.com \
    --cc=den@openvz.org \
    --cc=dgilbert@redhat.com \
    --cc=dplotnikov@virtuozzo.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.