On Wed, Oct 05, 2016 at 10:12:57AM +0200, Kevin Wolf wrote:
> Am 04.10.2016 um 18:02 hat Stefan Hajnoczi geschrieben:
> > On Tue, Oct 04, 2016 at 01:55:30PM +0200, Kevin Wolf wrote:
> > > Am 04.10.2016 um 12:41 hat Denis V. Lunev geschrieben:
> > > > On 10/04/2016 12:34 PM, Kevin Wolf wrote:
> > > > > Am 04.10.2016 um 11:23 hat Stefan Hajnoczi geschrieben:
> > > > >> On Mon, Oct 03, 2016 at 02:07:34PM -0400, John Snow wrote:
> > > > >>> Eh, regardless: If we're not using a STOP policy, it seems like the right
> > > > >>> thing to do is definitely to just fail the backup instead of failing the
> > > > >>> write.
> > > > >> Even with a -drive werror=stop policy the user probably doesn't want
> > > > >> guest downtime if writing to the backup target fails.
> > > > > That's a policy decision that ultimately only the user can make. For one
> > > > > user, it might be preferable to cancel the backup and keep the VM
> > > > > running, but for another user it may be more important to keep a
> > > > > consistent snapshot of the point in time when the backup job was started
> > > > > than keeping the VM running.
> > > > >
> > > > > Kevin
> > > > In this case policy for guest error and policy for backup
> > > > error should be different policies or I have missed something.
> > > 
> > > I guess so.
> > 
> > There are separate error policies for -device and the blockjob.  Perhaps
> > the blockjob error policy can be used in the write notifier code path if
> > the failure occurs while writing to the backup target.
> 
> Isn't the block job policy used for the background copy? Or do you think
> it's okay to use the same for both cases? That would mean that we stop
> the VM even if it's just a background copy that fails.

You're right, strictly speaking the guest notifier code path is a
separate case and should have a dedicated parameter.  At least if we
want to allow users to select from all possible policy combinations...

Stefan