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