qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH v3 00/11] qemu-ga: fsfreeze on Windows using


From: Tomoki Sekiyama
Subject: Re: [Qemu-devel] [RFC PATCH v3 00/11] qemu-ga: fsfreeze on Windows using VSS
Date: Thu, 23 May 2013 17:11:50 +0000

Hi Laszlo,

Thank you for reviewing.

On 5/23/13 7:05 , "Laszlo Ersek" <address@hidden> wrote:

>Sekiyama-san,
>
>On 05/21/13 17:33, Tomoki Sekiyama wrote:
>
>> * About errors in Windows 7 with patch v2
>>   VSS requires to write to snapshot volumes just before making them
>>read-only
>>   at final commit phase. This feature is called `auto-recovery'
>>   (See 
>>http://msdn.microsoft.com/en-us/library/windows/desktop/aa384651(v=vs.85)
>>.aspx#base.vssgloss_auto_recoved_shadow_copy for details).
>> 
>>   Since qemu and libvirt don't have feature to handle writable
>>snapshots,
>>   this patchset just disables auto-recovery by specifying
>>   VSS_VOLSNAP_ATTR_NO_AUTORECOVERY flag to SetContext.
>>   Unfortunately, this flag seems unsupported in Windows 7 or earlier.
>>   It tries to look up the snapshot volumes to write and fails in
>>   VSS_E_OBJECT_NOT_FOUND.
>> 
>>   For fundamental resolution we need a framework for guests to query
>>snapshots
>>   and to mount them as writable snapshots, but we just ignore the error
>>in
>>   this patchset.
>
>I've been trying to understand VSS as documented in
>
><http://technet.microsoft.com/en-us/library/ee923636%28v=ws.10%29.aspx>
>
>I'll be referring to the steps detailed there as "VSS steps".
>
>Currently I'm under the impression that the "guest-fsfreeze-freeze" and
>"guest-fsfreeze-thaw" commands do not match VSS from a "who has control
>when" perspective.
>
>VSS steps 1 to 5 correspond to "guest-fsfreeze-freeze". In the POSIX
>flavor of qemu-ga, including fsfreeze hook scripts, at this point
>qemu-ga gets back and returns control to the management stack, and
>backup can be done.
>
>VSS step 6 corresponds to the management stack preparing the snapshot(s)
>or other means of backup.
>
>VSS steps 7 to 8 correspond to "guest-fsfreeze-thaw". The POSIX flavor
>of qemu-ga thaws filesystems and reactivates applications / enables them
>to dirty their own data stores. This action is initiated by the
>management stack which has full control over its timing and conditions
>etc.
>
>I believe to discover the following (orthogonal) mismatches between VSS
>and our current freeze/thaw APIs:
>
>(i) Once VSS starts running at step 1, it doesn't relinquish control
>after step 5, and it doesn't allow an external controller to relaunch it
>from step 7. In other words, VSS step 6 is a callout / callback
>initiated by Windows logic that doesn't match our current control
>ownership.
>
>In theory VSS step 6 should issue a QMP event (?) that allows libvirt to
>make the snapshot, and until libvirt is done with that, VSS step 6
>should block.

The patchset gives two components to qemu-ga; VSS requester and VSS
provider.
Actually, the purpose of qemu-ga provider is to issue the QMP event you
say.

- When qemu-ga receives guest-fsfreeze-freeze, the requester initiate the
  VSS process (step 1).
 -- It designate qemu-ga provider (which just send an event to qemu-ga
    requester) so that qemu-ga gets the control again at the step 6.
- At step 6, qemu-ga responds to libvirt to notify guest-fsfreeze-freeze
  is finished.
- libvirt make the snapshot.
- After it is done, libvirt sends guest-fsfreeze-thaw to qemu-ga
- Qemu-ga VSS provider tells VSS that snapshotting is finished, to resume
  the remaining steps.


>(ii) Somewhat similar is the control over backup storage:
>
>An fsfreeze hook script causes the corresponding application to clean up
>its live data store. The application doesn't encounter the notion of a
>separate / detached copy, and no additional storage is visible (needs to
>be visible) in the guest. The management stack exploits this guarantee
>when it (basically blindly) snapshots the disk image.
>
>Under VSS, in-guest components (VSS providers, basically drivers) are
>responsible for incremental backup (copy-on-write etc.) features. I'm
>not sure how this can be combined with qcow2 features managed by
>libvirt.

I agree there is some mismatch of ownership design of snapshots.
Currently qcow2 feature is not directly exposed to guests. Instead,
the provider is used just to kick the snapshot in the libvirt.
When VSS query the snapshot volume, the provider always say "not found",
so the VSS-oriented restore is not possible. (That is, we need to resume
the disk on libvirt side).
This makes it difficult to execute step 10 (auto-recovery; modification
phase of the snapshot volume before make it read-only), because the

volume is invisible to the guest. A possible way of achieve step 10 may
be create another external qcow2 image based on the snapshot taken at
step 6, mount it (as a writable disk) to the guest.

>The VSS provider could target a separate disk, update it
>incrementally to mirror the current live data, and libvirt could keep
>snapshots of this backup disk.

>(iii) VSS step 10 exists because in fact I cheated in (i) and VSS steps
>1 to 5 do not correspond to guest-fsfreeze-freeze; the VSS design has
>aspects that are completely absent from guest-fsfreeze-freeze.
>
>guest-fsfreeze-freeze, including the hook scripts, gives as much time to
>applications to quiesce as they need. When the main hook script returns
>control to qemu-qa, and when qemu-ga returns control to libvirt, the
>layer taking back control is assured that the lower layer has completed
>all of its freezing responsibilities.
>
>This is not so with VSS steps 1-5, and the root cause is performance /
>avoidance of live service interruption. VSS puts a 60 second limit on
>application data store quiescing, and a 10 second limit on actual
>snapshotting / backup (VSS step 6). Live service should resume in no
>more than 70 seconds apparently.
>
>VSS realizes that many applications won't be able to satisfy this
>Requirement. Therefore the application level quiescing is split in a
>synchronous handler and an asynchronous "bottom half" (which is VSS step
>10).
>- Up to and including VSS step 5, an application prepares but a separate
>dirty context (in 60 seconds).
>- In VSS step 6, this context ("shadow copy") is detached (move to other
>storage, probably).
>- In VSS steps 7 and 8, the application resumes live service. Also,
>- VSS step 10, the "bottom half" of the application (a subprocess or a
>dedicated thread, maybe), cleans up the now detached dirty context, *in
>parallel* to the live service of the application.
>
>If we disable VSS step 10 (VSS_VOLSNAP_ATTR_NO_AUTORECOVERY), I'm still
>confused / unsure about:
>
>- the control ownership problem in (i) and the storage problem in (ii)
>-- I believe your series must already solve this; can you please
>describe it in a few words?

I hope the explanation above is answering (i) and (ii),

>- the time limits for VSS steps 5 and 6 probably remain in place, but
>without a bottom half (VSS step 10) applications may not be able to
>satisfy them. Does VSS_VOLSNAP_ATTR_NO_AUTORECOVERY make applications
>exempt from the time limits?

In my patch, VSS_VOLSNAP_ATTR_NO_AUTORECOVERY is mainly used to avoid

the writes to snapshots(taken at step 6), because it is already invisible
from guests.

I think time limits issues is an orthogonal with this problemm;
Exceeding time limits could happen even because the guest is in heavy I/O,
regardless auto-recovery is enabled or not.
What we can do then might be retrying after some minutes...

>Interestingly, like at least
><http://wiki.iaso.com/index.php/Manual:MSSQL_VSS_Auto_Recovery> suggests
>for MSSQL, VSS step 10 seems to depend on both the VSS requestor and the
>application:
>
>  !VSS_VOLSNAP_ATTR_NO_AUTORECOVERY && MSSQL.AllowVssAutoRecover
>
>If this condition is not satisfied, then (I believe from the linked
>article) MSSQL will not choose
>
>  "breach time limits but create pristine backup",
>
>instead it will opt for
>
>  "prepare dirty backup and delay recovery until restore time".
>
>This is probably not optimal and VSS step 10 could be a requirement if
>quick restore is important.
>
>
>Please point out any mistakes in the above reasoning (although I'm sure
>it's easier to point out the few places where I'm *not* mistaken) -- I
>need to understand clearly the VSS procedure and its mapping (steps 1 to
>9) to our APIs for any half-useful review (I know nothing about
>Windows). Apologies if this has been discussed before, can you please
>provide pointers in that case?
>
>Thank you,
>Laszlo

Thanks,
Tomoki Sekiyama




reply via email to

[Prev in Thread] Current Thread [Next in Thread]