From: Paolo Bonzini <pbonzini@redhat.com>
To: Chijianchun <chijianchun@huawei.com>
Cc: "aliguori@us.ibm.com" <aliguori@us.ibm.com>,
"paul@codesourcery.com" <paul@codesourcery.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"avi@redhat.com" <avi@redhat.com>,
"mtosatti@redhat.com" <mtosatti@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: Are there plans to achieve ram live Snapshot feature?
Date: Fri, 09 Aug 2013 17:38:12 +0200 [thread overview]
Message-ID: <52050CE4.6000306@redhat.com> (raw)
In-Reply-To: <33FB050264B7AD4DBD6583581F2E03104B764728@nkgeml511-mbx.china.huawei.com>
Il 09/08/2013 12:20, Chijianchun ha scritto:
> Now in KVM, when RAM snapshot, vcpus needs stopped, it is Unfriendly
> restrictions to users.
>
> Are there plans to achieve ram live Snapshot feature?
>
> in my mind, Snapshots can not occupy additional too much memory, So when
> the memory needs to be changed, the old memory page is needed to flush
> to the file first. But flushing to file is too slower than memory, and
> when flushing, the vcpu or VM is need to be paused until finished
> flushing, so pause...resume...pause...resume............., more and
> more slower.
>
> Is this idea feasible? Are there any other thoughts?
>
This looks very similar to postcopy migration (you can Google it). The
infrastructure for postcopy migration could be used for this as well.
Paolo
WARNING: multiple messages have this Message-ID (diff)
From: Paolo Bonzini <pbonzini@redhat.com>
To: Chijianchun <chijianchun@huawei.com>
Cc: "aliguori@us.ibm.com" <aliguori@us.ibm.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"mtosatti@redhat.com" <mtosatti@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"paul@codesourcery.com" <paul@codesourcery.com>,
"avi@redhat.com" <avi@redhat.com>
Subject: Re: [Qemu-devel] Are there plans to achieve ram live Snapshot feature?
Date: Fri, 09 Aug 2013 17:38:12 +0200 [thread overview]
Message-ID: <52050CE4.6000306@redhat.com> (raw)
In-Reply-To: <33FB050264B7AD4DBD6583581F2E03104B764728@nkgeml511-mbx.china.huawei.com>
Il 09/08/2013 12:20, Chijianchun ha scritto:
> Now in KVM, when RAM snapshot, vcpus needs stopped, it is Unfriendly
> restrictions to users.
>
> Are there plans to achieve ram live Snapshot feature?
>
> in my mind, Snapshots can not occupy additional too much memory, So when
> the memory needs to be changed, the old memory page is needed to flush
> to the file first. But flushing to file is too slower than memory, and
> when flushing, the vcpu or VM is need to be paused until finished
> flushing, so pause...resume...pause...resume............., more and
> more slower.
>
> Is this idea feasible? Are there any other thoughts?
>
This looks very similar to postcopy migration (you can Google it). The
infrastructure for postcopy migration could be used for this as well.
Paolo
next prev parent reply other threads:[~2013-08-09 15:38 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-09 10:20 Are there plans to achieve ram live Snapshot feature? Chijianchun
2013-08-09 10:20 ` [Qemu-devel] " Chijianchun
2013-08-09 15:38 ` Paolo Bonzini [this message]
2013-08-09 15:38 ` Paolo Bonzini
2013-08-09 15:45 ` Anthony Liguori
2013-08-09 15:45 ` [Qemu-devel] " Anthony Liguori
2013-08-09 15:51 ` Eric Blake
2013-08-09 15:51 ` Eric Blake
2013-08-12 9:59 ` Stefan Hajnoczi
2013-08-12 9:59 ` Stefan Hajnoczi
2013-08-12 10:26 ` Alex Bligh
2013-08-12 10:26 ` [Qemu-devel] " Alex Bligh
2013-08-12 11:33 ` Stefan Hajnoczi
2013-08-12 11:33 ` Stefan Hajnoczi
2013-08-13 2:53 ` Wenchao Xia
2013-08-13 2:53 ` Wenchao Xia
2013-08-13 8:21 ` Stefan Hajnoczi
2013-08-13 8:21 ` Stefan Hajnoczi
2013-08-14 1:54 ` Wenchao Xia
2013-08-14 1:54 ` Wenchao Xia
2013-08-14 7:53 ` Stefan Hajnoczi
2013-08-14 7:53 ` Stefan Hajnoczi
2013-08-14 8:13 ` Alex Bligh
2013-08-14 8:13 ` Alex Bligh
2013-08-15 2:26 ` Wenchao Xia
2013-08-15 2:26 ` Wenchao Xia
2013-08-15 7:49 ` Stefan Hajnoczi
2013-08-15 7:49 ` Stefan Hajnoczi
2013-08-15 8:03 ` Wenchao Xia
2013-08-15 8:03 ` Wenchao Xia
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=52050CE4.6000306@redhat.com \
--to=pbonzini@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=avi@redhat.com \
--cc=chijianchun@huawei.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=paul@codesourcery.com \
--cc=qemu-devel@nongnu.org \
/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.