Re: [PATCH v13 1/8] save/load cpu runstate

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 --]