From: Eric Blake <eblake@redhat.com>
To: Hu Tao <hutao@cn.fujitsu.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Gleb Natapov <gleb@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Jan Kiszka <jan.kiszka@siemens.com>,
qemu-devel <qemu-devel@nongnu.org>,
Markus Armbruster <armbru@redhat.com>,
Blue Swirl <blauwirbel@gmail.com>,
Orit Wasserman <owasserm@redhat.com>,
kvm list <kvm@vger.kernel.org>,
Juan Quintela <quintela@redhat.com>,
Alexander Graf <agraf@suse.de>, Andrew Jones <drjones@redhat.com>,
Alex Williamson <alex.williamson@redhat.com>,
Sasha Levin <levinsasha928@gmail.com>,
Stefan Hajnoczi <stefanha@redhat.com>,
Luiz Capitulino <lcapitulino@redhat.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Kevin Wolf <kwolf@redhat.com>,
Anthony Liguori <aliguori@us.ibm.com>,
Marcelo Tosatti <mtosatti@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH v13 1/8] save/load cpu runstate
Date: Fri, 01 Mar 2013 09:29:20 -0700 [thread overview]
Message-ID: <5130D760.70908@redhat.com> (raw)
In-Reply-To: <20130301073648.GD16362@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1936 bytes --]
On 03/01/2013 12:36 AM, Hu Tao wrote:
> On Thu, Feb 28, 2013 at 02:12:37PM -0700, Eric Blake wrote:
>> On 02/28/2013 05:13 AM, Hu Tao wrote:
>>> This patch enables preservation of cpu runstate during save/load vm.
>>> So when a vm is restored from snapshot, the cpu runstate is restored,
>>> too.
>>
>> What happens if a management app wants to override the runstate when
>> restoring the domain? I can think of several useful scenarios:
>>
>> 1. management app pauses the guest, then saves domain state and other
>> things (management state, or disk clones), then resumes the guest.
>> Later, the management wants to revert to the saved state, but have the
>> guest running right away. I guess here, knowing that the guest was
>> saved in a paused state doesn't hurt, since the management app can
>> resume it right away.
>>
>> 2. management app saves domain state of a live guest, then copies that
>> state elsewhere. In its new location, the management app wants to
>> investigate the state for forensic analysis - so even though the guest
>> remembers that it was running, management wants to start it paused.
>> Here, it is important that there must not be a window of time where the
>> guest can run, otherwise, the results are not reproducible.
>
> -S takes precedence in the case. But for in-migration, runstate is
> loaded from src.
Given your answer, I think we're okay from the libvirt perspective. My
biggest worry about a window where the guest runs unchecked is not a
problem, given that libvirt always uses -S on incoming migration. In
turn, libvirt has its own mechanisms for tracking whether the outgoing
migration was started from a running state, along with API overrides to
let a user override whether libvirt will resume the guest on the
incoming migration side.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 621 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Eric Blake <eblake@redhat.com>
To: Hu Tao <hutao@cn.fujitsu.com>
Cc: kvm list <kvm@vger.kernel.org>,
qemu-devel <qemu-devel@nongnu.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Daniel P. Berrange" <berrange@redhat.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Jan Kiszka <jan.kiszka@siemens.com>,
Gleb Natapov <gleb@redhat.com>, Blue Swirl <blauwirbel@gmail.com>,
Andrew Jones <drjones@redhat.com>,
Marcelo Tosatti <mtosatti@redhat.com>,
Sasha Levin <levinsasha928@gmail.com>,
Luiz Capitulino <lcapitulino@redhat.com>,
Anthony Liguori <aliguori@us.ibm.com>,
Markus Armbruster <armbru@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>,
Juan Quintela <quintela@redhat.com>,
Orit Wasserman <owasserm@redhat.com>,
Kevin Wolf <kwolf@redhat.com>,
Wen Congyang <wency@cn.fujitsu.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Alexander Graf <agraf@suse.de>,
Alex Williamson <alex.williamson@redhat.com>,
Peter Maydell <peter.maydell@linaro.org>
Subject: Re: [PATCH v13 1/8] save/load cpu runstate
Date: Fri, 01 Mar 2013 09:29:20 -0700 [thread overview]
Message-ID: <5130D760.70908@redhat.com> (raw)
In-Reply-To: <20130301073648.GD16362@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1936 bytes --]
On 03/01/2013 12:36 AM, Hu Tao wrote:
> On Thu, Feb 28, 2013 at 02:12:37PM -0700, Eric Blake wrote:
>> On 02/28/2013 05:13 AM, Hu Tao wrote:
>>> This patch enables preservation of cpu runstate during save/load vm.
>>> So when a vm is restored from snapshot, the cpu runstate is restored,
>>> too.
>>
>> What happens if a management app wants to override the runstate when
>> restoring the domain? I can think of several useful scenarios:
>>
>> 1. management app pauses the guest, then saves domain state and other
>> things (management state, or disk clones), then resumes the guest.
>> Later, the management wants to revert to the saved state, but have the
>> guest running right away. I guess here, knowing that the guest was
>> saved in a paused state doesn't hurt, since the management app can
>> resume it right away.
>>
>> 2. management app saves domain state of a live guest, then copies that
>> state elsewhere. In its new location, the management app wants to
>> investigate the state for forensic analysis - so even though the guest
>> remembers that it was running, management wants to start it paused.
>> Here, it is important that there must not be a window of time where the
>> guest can run, otherwise, the results are not reproducible.
>
> -S takes precedence in the case. But for in-migration, runstate is
> loaded from src.
Given your answer, I think we're okay from the libvirt perspective. My
biggest worry about a window where the guest runs unchecked is not a
problem, given that libvirt always uses -S on incoming migration. In
turn, libvirt has its own mechanisms for tracking whether the outgoing
migration was started from a running state, along with API overrides to
let a user override whether libvirt will resume the guest on the
incoming migration side.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 621 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Eric Blake <eblake@redhat.com>
To: Hu Tao <hutao@cn.fujitsu.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Gleb Natapov <gleb@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Jan Kiszka <jan.kiszka@siemens.com>,
qemu-devel <qemu-devel@nongnu.org>,
Markus Armbruster <armbru@redhat.com>,
Blue Swirl <blauwirbel@gmail.com>,
Orit Wasserman <owasserm@redhat.com>,
kvm list <kvm@vger.kernel.org>,
Juan Quintela <quintela@redhat.com>,
Alexander Graf <agraf@suse.de>, Andrew Jones <drjones@redhat.com>,
Alex Williamson <alex.williamson@redhat.com>,
Sasha Levin <levinsasha928@gmail.com>,
Stefan Hajnoczi <stefanha@redhat.com>,
Luiz Capitulino <lcapitulino@redhat.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Kevin Wolf <kwolf@redhat.com>,
Anthony Liguori <aliguori@us.ibm.com>,
Marcelo Tosatti <mtosatti@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v13 1/8] save/load cpu runstate
Date: Fri, 01 Mar 2013 09:29:20 -0700 [thread overview]
Message-ID: <5130D760.70908@redhat.com> (raw)
In-Reply-To: <20130301073648.GD16362@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1936 bytes --]
On 03/01/2013 12:36 AM, Hu Tao wrote:
> On Thu, Feb 28, 2013 at 02:12:37PM -0700, Eric Blake wrote:
>> On 02/28/2013 05:13 AM, Hu Tao wrote:
>>> This patch enables preservation of cpu runstate during save/load vm.
>>> So when a vm is restored from snapshot, the cpu runstate is restored,
>>> too.
>>
>> What happens if a management app wants to override the runstate when
>> restoring the domain? I can think of several useful scenarios:
>>
>> 1. management app pauses the guest, then saves domain state and other
>> things (management state, or disk clones), then resumes the guest.
>> Later, the management wants to revert to the saved state, but have the
>> guest running right away. I guess here, knowing that the guest was
>> saved in a paused state doesn't hurt, since the management app can
>> resume it right away.
>>
>> 2. management app saves domain state of a live guest, then copies that
>> state elsewhere. In its new location, the management app wants to
>> investigate the state for forensic analysis - so even though the guest
>> remembers that it was running, management wants to start it paused.
>> Here, it is important that there must not be a window of time where the
>> guest can run, otherwise, the results are not reproducible.
>
> -S takes precedence in the case. But for in-migration, runstate is
> loaded from src.
Given your answer, I think we're okay from the libvirt perspective. My
biggest worry about a window where the guest runs unchecked is not a
problem, given that libvirt always uses -S on incoming migration. In
turn, libvirt has its own mechanisms for tracking whether the outgoing
migration was started from a running state, along with API overrides to
let a user override whether libvirt will resume the guest on the
incoming migration side.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 621 bytes --]
next prev parent reply other threads:[~2013-03-01 16:29 UTC|newest]
Thread overview: 136+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-28 12:13 [PATCH v13 0/8] pv event interface between host and guest Hu Tao
2013-02-28 12:13 ` Hu Tao
2013-02-28 12:13 ` [PATCH v13] kvm: notify host when the guest is panicked Hu Tao
2013-02-28 12:13 ` Hu Tao
2013-02-28 12:13 ` [PATCH v13 1/8] save/load cpu runstate Hu Tao
2013-02-28 12:13 ` Hu Tao
2013-02-28 21:12 ` Eric Blake
2013-02-28 21:12 ` Eric Blake
2013-03-01 7:36 ` Hu Tao
2013-03-01 7:36 ` [Qemu-devel] " Hu Tao
2013-03-01 7:36 ` Hu Tao
2013-03-01 16:29 ` Eric Blake [this message]
2013-03-01 16:29 ` [Qemu-devel] " Eric Blake
2013-03-01 16:29 ` Eric Blake
2013-03-04 9:30 ` Paolo Bonzini
2013-03-04 9:30 ` [Qemu-devel] " Paolo Bonzini
2013-03-04 9:30 ` Paolo Bonzini
2013-03-05 2:33 ` Hu Tao
2013-03-05 2:33 ` [Qemu-devel] " Hu Tao
2013-03-05 2:33 ` Hu Tao
2013-03-05 8:24 ` Paolo Bonzini
2013-03-05 8:24 ` [Qemu-devel] " Paolo Bonzini
2013-03-05 8:24 ` Paolo Bonzini
2013-02-28 12:13 ` [PATCH v13 2/8] start vm after resetting it Hu Tao
2013-02-28 12:13 ` Hu Tao
2013-02-28 13:23 ` Jan Kiszka
2013-02-28 13:23 ` Jan Kiszka
2013-03-05 3:05 ` Hu Tao
2013-03-05 3:05 ` [Qemu-devel] " Hu Tao
2013-03-05 3:05 ` Hu Tao
2013-03-04 9:32 ` Paolo Bonzini
2013-03-04 9:32 ` [Qemu-devel] " Paolo Bonzini
2013-03-04 9:32 ` Paolo Bonzini
2013-03-05 3:06 ` Hu Tao
2013-03-05 3:06 ` [Qemu-devel] " Hu Tao
2013-03-05 3:06 ` Hu Tao
2013-02-28 12:13 ` [PATCH v13 3/8] update kernel headers Hu Tao
2013-02-28 12:13 ` Hu Tao
2013-02-28 12:13 ` [PATCH v13 4/8] add a new runstate: RUN_STATE_GUEST_PANICKED Hu Tao
2013-02-28 12:13 ` Hu Tao
2013-03-04 9:40 ` Paolo Bonzini
2013-03-04 9:40 ` [Qemu-devel] " Paolo Bonzini
2013-03-04 9:40 ` Paolo Bonzini
2013-03-05 3:17 ` Hu Tao
2013-03-05 3:17 ` [Qemu-devel] " Hu Tao
2013-03-05 3:17 ` Hu Tao
2013-03-05 8:26 ` Paolo Bonzini
2013-03-05 8:26 ` [Qemu-devel] " Paolo Bonzini
2013-03-05 8:26 ` Paolo Bonzini
2013-03-06 9:03 ` Hu Tao
2013-03-06 9:03 ` [Qemu-devel] " Hu Tao
2013-03-06 9:03 ` Hu Tao
2013-02-28 12:13 ` [PATCH v13 5/8] add a new qevent: QEVENT_GUEST_PANICKED Hu Tao
2013-02-28 12:13 ` Hu Tao
2013-03-01 16:31 ` Eric Blake
2013-03-01 16:31 ` [Qemu-devel] " Eric Blake
2013-03-01 16:31 ` Eric Blake
2013-03-05 3:17 ` Hu Tao
2013-03-05 3:17 ` [Qemu-devel] " Hu Tao
2013-03-05 3:17 ` Hu Tao
2013-03-04 9:40 ` Paolo Bonzini
2013-03-04 9:40 ` [Qemu-devel] " Paolo Bonzini
2013-03-04 9:40 ` Paolo Bonzini
2013-02-28 12:13 ` [PATCH v13 6/8] introduce a new qom device to deal with panicked event Hu Tao
2013-02-28 12:13 ` Hu Tao
2013-03-04 9:42 ` Paolo Bonzini
2013-03-04 9:42 ` [Qemu-devel] " Paolo Bonzini
2013-03-04 9:42 ` Paolo Bonzini
2013-03-04 10:10 ` Christian Borntraeger
2013-03-04 10:10 ` [Qemu-devel] " Christian Borntraeger
2013-03-04 10:21 ` Paolo Bonzini
2013-03-04 10:21 ` [Qemu-devel] " Paolo Bonzini
2013-02-28 12:13 ` [PATCH v13 7/8] allower the user to disable pv event support Hu Tao
2013-02-28 12:13 ` Hu Tao
2013-03-04 9:47 ` Paolo Bonzini
2013-03-04 9:47 ` [Qemu-devel] " Paolo Bonzini
2013-03-04 9:47 ` Paolo Bonzini
2013-02-28 12:13 ` [PATCH v13 8/8] pv event: add document to describe the usage Hu Tao
2013-02-28 12:13 ` Hu Tao
2013-03-03 9:17 ` [PATCH v13 0/8] pv event interface between host and guest Gleb Natapov
2013-03-03 9:17 ` [Qemu-devel] " Gleb Natapov
2013-03-03 9:17 ` Gleb Natapov
2013-03-04 10:05 ` Paolo Bonzini
2013-03-04 10:05 ` [Qemu-devel] " Paolo Bonzini
2013-03-04 10:05 ` Paolo Bonzini
2013-03-04 10:21 ` Gleb Natapov
2013-03-04 10:21 ` [Qemu-devel] " Gleb Natapov
2013-03-04 10:21 ` Gleb Natapov
2013-03-04 10:28 ` Paolo Bonzini
2013-03-04 10:28 ` [Qemu-devel] " Paolo Bonzini
2013-03-04 10:43 ` Gleb Natapov
2013-03-04 10:43 ` [Qemu-devel] " Gleb Natapov
2013-03-04 10:43 ` Gleb Natapov
2013-03-04 10:49 ` Paolo Bonzini
2013-03-04 10:49 ` [Qemu-devel] " Paolo Bonzini
2013-03-04 10:49 ` Paolo Bonzini
2013-03-04 10:59 ` Gleb Natapov
2013-03-04 10:59 ` [Qemu-devel] " Gleb Natapov
2013-03-04 10:59 ` Gleb Natapov
2013-03-04 11:10 ` Paolo Bonzini
2013-03-04 11:10 ` [Qemu-devel] " Paolo Bonzini
2013-03-04 11:10 ` Paolo Bonzini
2013-03-04 11:20 ` Gleb Natapov
2013-03-04 11:20 ` [Qemu-devel] " Gleb Natapov
2013-03-04 11:20 ` Gleb Natapov
2013-03-04 11:35 ` Paolo Bonzini
2013-03-04 11:35 ` [Qemu-devel] " Paolo Bonzini
2013-03-04 11:35 ` Paolo Bonzini
2013-03-04 11:52 ` Gleb Natapov
2013-03-04 11:52 ` [Qemu-devel] " Gleb Natapov
2013-03-04 11:52 ` Gleb Natapov
2013-03-04 12:21 ` Paolo Bonzini
2013-03-04 12:21 ` [Qemu-devel] " Paolo Bonzini
2013-03-04 12:21 ` Paolo Bonzini
2013-03-06 8:56 ` Hu Tao
2013-03-06 8:56 ` [Qemu-devel] " Hu Tao
2013-03-06 8:56 ` Hu Tao
2013-03-06 9:07 ` Paolo Bonzini
2013-03-06 9:07 ` [Qemu-devel] " Paolo Bonzini
2013-03-06 9:28 ` li guang
2013-03-06 9:28 ` li guang
2013-03-06 9:38 ` Gleb Natapov
2013-03-06 9:38 ` [Qemu-devel] " Gleb Natapov
2013-03-06 9:38 ` Gleb Natapov
2013-03-06 9:48 ` Paolo Bonzini
2013-03-06 9:48 ` [Qemu-devel] " Paolo Bonzini
2013-03-06 9:48 ` Paolo Bonzini
2013-03-06 9:59 ` Gleb Natapov
2013-03-06 9:59 ` [Qemu-devel] " Gleb Natapov
2013-03-06 9:59 ` Gleb Natapov
2013-03-06 8:46 ` Hu Tao
2013-03-06 8:46 ` [Qemu-devel] " Hu Tao
2013-03-06 8:46 ` Hu Tao
2013-03-06 9:37 ` Gleb Natapov
2013-03-06 9:37 ` [Qemu-devel] " Gleb Natapov
2013-03-06 9:37 ` Gleb Natapov
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=5130D760.70908@redhat.com \
--to=eblake@redhat.com \
--cc=agraf@suse.de \
--cc=alex.williamson@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=armbru@redhat.com \
--cc=blauwirbel@gmail.com \
--cc=drjones@redhat.com \
--cc=gleb@redhat.com \
--cc=hutao@cn.fujitsu.com \
--cc=jan.kiszka@siemens.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kvm@vger.kernel.org \
--cc=kwolf@redhat.com \
--cc=lcapitulino@redhat.com \
--cc=levinsasha928@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=mtosatti@redhat.com \
--cc=owasserm@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=stefanha@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.