All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: "Denis V. Lunev" <den@openvz.org>, John Snow <jsnow@redhat.com>,
	Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
	Fam Zheng <famz@redhat.com>, qemu block <qemu-block@nongnu.org>,
	Jeff Cody <jcody@redhat.com>, qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] backup notifier fail policy
Date: Wed, 5 Oct 2016 10:12:57 +0200	[thread overview]
Message-ID: <20161005081257.GA4901@noname.str.redhat.com> (raw)
In-Reply-To: <20161004160230.GE28028@stefanha-x1.localdomain>

[-- Attachment #1: Type: text/plain, Size: 1653 bytes --]

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.

Kevin

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

  parent reply	other threads:[~2016-10-05  8:13 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-30 17:11 [Qemu-devel] backup notifier fail policy Vladimir Sementsov-Ogievskiy
2016-09-30 18:59 ` Vladimir Sementsov-Ogievskiy
2016-10-03 13:11   ` Stefan Hajnoczi
2016-10-03 18:07     ` John Snow
2016-10-04  9:23       ` Stefan Hajnoczi
2016-10-04  9:34         ` Kevin Wolf
2016-10-04 10:41           ` Denis V. Lunev
2016-10-04 11:55             ` Kevin Wolf
2016-10-04 16:02               ` Stefan Hajnoczi
2016-10-04 16:03                 ` John Snow
2016-10-04 16:19                   ` Denis V. Lunev
2016-10-05  8:12                 ` Kevin Wolf [this message]
2016-10-05 12:59                   ` Stefan Hajnoczi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161005081257.GA4901@noname.str.redhat.com \
    --to=kwolf@redhat.com \
    --cc=den@openvz.org \
    --cc=famz@redhat.com \
    --cc=jcody@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=vsementsov@virtuozzo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.