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