From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55514) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1brhK8-0006PN-84 for qemu-devel@nongnu.org; Wed, 05 Oct 2016 04:13:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1brhK7-0001yq-5t for qemu-devel@nongnu.org; Wed, 05 Oct 2016 04:13:08 -0400 Date: Wed, 5 Oct 2016 10:12:57 +0200 From: Kevin Wolf Message-ID: <20161005081257.GA4901@noname.str.redhat.com> References: <57EE9CA4.6010801@virtuozzo.com> <57EEB604.1090908@virtuozzo.com> <20161003131151.GB31993@stefanha-x1.localdomain> <20161004092349.GD4587@stefanha-x1.localdomain> <20161004093418.GC5316@noname.str.redhat.com> <790008a1-96a4-b68c-2463-fa817dcdb607@openvz.org> <20161004115530.GE5316@noname.str.redhat.com> <20161004160230.GE28028@stefanha-x1.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5mCyUwZo2JvN/JJP" Content-Disposition: inline In-Reply-To: <20161004160230.GE28028@stefanha-x1.localdomain> Subject: Re: [Qemu-devel] backup notifier fail policy List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: "Denis V. Lunev" , John Snow , Vladimir Sementsov-Ogievskiy , Fam Zheng , qemu block , Jeff Cody , qemu-devel --5mCyUwZo2JvN/JJP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 t= he right > > > >>> thing to do is definitely to just fail the backup instead of fail= ing the > > > >>> write. > > > >> Even with a -drive werror=3Dstop 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. Fo= r 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 st= arted > > > > 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. > >=20 > > I guess so. >=20 > 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 --5mCyUwZo2JvN/JJP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJX9LYJAAoJEH8JsnLIjy/WmsMP/28YhQ8qtE7PlTIC0NYkixts QGYAvMi/oVaeo4naHiiYFq2Ooa+xS6Hzlz4TOYYPYJ8Sb9VffMwG9T0H5fBfbk+M 6qZr/iDQqsRYQP/FyZlCZPe3EuM0+wMoX+EyLE4kFp8XiDos5pioUrG0DW6hKcYW nUs5x05DuolSANlmWNq9XWqx8YmUwfb7GC6xh9MaWHP+a+o+ydMddu5HvoEfqAxk HdbTBXo1BvOJAA1Y0JFHa0tROIg1OOh0q1ArktI/QylYDJWRgL70QdXtdN/YUzF4 rzyBI1CAiofqoOQhNmjoW/2Z+XEz/DJMJ4tdvlTZuhIdF3kz7ZKMIX6jQaBNs74V KoU9IhEUBlYjHGn0hEa0TVv5qychKNm+xQ2n1Vga5k0dD9fw0rFZFzf7UWjx9R9s 7eKhc6Co0lximHsfYpWBNDrcoNoTJZpqjLAYssMWpp6drJnbRbzj+dvjx8/9kAWF eqMhfhZzAV3KRGEbQg7J2p4BektD7TnlxGdUVFa7DNh1G4PZ14nNCYj1KiDiuSWK lQzdnuE794haan/ZB0ANaxcCdAYXUwrBcM26ilUUoC9eh9uZ/9Q0ig+BxdRgJ1YY x+ZOowYpuKvz8WcQVLS6oRhiprXfQ8YhNN8jlXyO5h72kY0xQ5twHVjtUTOUpd6+ da6xm4Z8+pBop5/QE0HJ =1WvT -----END PGP SIGNATURE----- --5mCyUwZo2JvN/JJP--