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:
signature.asc
Description: OpenPGP digital signature
