From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48130) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBshW-0001jc-Dr for qemu-devel@nongnu.org; Wed, 23 Dec 2015 18:20:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aBshV-0000F9-Ab for qemu-devel@nongnu.org; Wed, 23 Dec 2015 18:20:10 -0500 References: <1450802786-20893-1-git-send-email-kwolf@redhat.com> <20151223031412.GC14423@ad.usersys.redhat.com> From: Max Reitz Message-ID: <567B2C1F.5030006@redhat.com> Date: Thu, 24 Dec 2015 00:19:59 +0100 MIME-Version: 1.0 In-Reply-To: <20151223031412.GC14423@ad.usersys.redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="F80G8ClCP5bmxHiGcpdLNWobkl9b7otcw" Subject: Re: [Qemu-devel] [PATCH 00/10] qcow2: Implement image locking List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng , Kevin Wolf Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --F80G8ClCP5bmxHiGcpdLNWobkl9b7otcw Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 23.12.2015 04:14, Fam Zheng wrote: > On Tue, 12/22 17:46, Kevin Wolf wrote: >> Enough innocent images have died because users called 'qemu-img snapsh= ot' while >> the VM was still running. Educating the users doesn't seem to be a wor= king >> strategy, so this series adds locking to qcow2 that refuses to access = the image >> read-write from two processes. >> >> Eric, this will require a libvirt update to deal with qemu crashes whi= ch leave >> locked images behind. The simplest thinkable way would be to unconditi= onally >> override the lock in libvirt whenever the option is present. In that c= ase, >> libvirt VMs would be protected against concurrent non-libvirt accesses= , but not >> the other way round. If you want more than that, libvirt would have to= check >> somehow if it was its own VM that used the image and left the lock beh= ind. I >> imagine that can't be too hard either. >=20 > The motivation is great, but I'm not sure I like the side-effect that a= n > unclean shutdown will require a "forced" open, because it makes using q= cow2 in > development cumbersome, How so? Just extend your "x86_64-softmmu/qemu-system-x86_64 -these-options-will-make-qemu-crash" invocation by "; qemu-img force-unlock foo.qcow2". > and like you said, management/user also needs t= o handle > this explicitly. This is a bit of a personal preference, but it's stron= g enough > that I want to speak up. Well, I personally always had the opposite preference. I see Denis's series works on Windows, too, which is good. However, it won't work with any backend, which a qcow2 flag will. Also, Denis's/Olga's series will by default not lock the file. This is not an issue if one uses libvirt to run a VM; but there are people who invoke qemu directly and then try to run qemu-img concurrently, and I doubt those people will manually set the locking option. This might be addressed by automatically setting the option if a certain format like qcow2 is used, but it may be pretty difficult to get that implemented nicely. So the benefits of a qcow2 flag are only minor ones. However, I personally believe that automatic unlock on crash is a very minor benefit as well. That should never happen in practice anyway, and a crashing qemu is such a great inconvenience that I as a user wouldn't really mind having to unlock the image afterwards. In fact, libvirt could even do that manually, couldn't it? If qemu crashes, it just invokes qemu-img force-unlock on any qcow2 image which was attached R/W to the VM. > As an alternative, can we introduce .bdrv_flock() in protocol drivers, = with > similar semantics to flock(2) or lockf(3)? That way all formats can ben= efit, > and a program crash will automatically drop the lock. Making other formats benefit from addressing this issue is a good point, but it too is a minor point. Formats other than qcow2 and raw are only supported for compatibility anyway, and we don't need this feature for ra= w. I feel like most of the question which approach to take revolves around "But what if qemu crashes?". You (and others) are right in that having to manually unlock the image then is cumbersome, however, I think that: (1) qemu should never crash anyway. (2) If qemu does crash, having to unlock the image is probably the least of your worries. (3) If you are using libvirt, it should actually be possible for libvirt to automatically force-unlock images on qemu crash. This is why I don't think that keeping a locked image behind on qemu crash is actually an issue. Max --F80G8ClCP5bmxHiGcpdLNWobkl9b7otcw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWeywfAAoJEDuxQgLoOKytWMEH/10eZfT/NtrRvL39EMeP9OAd PeCZO65g1riDaPrsaql8uh4xPvphUtvNWOMNvykoAp2kZh3qdJKZV7qXAP0TTVHB W5y+vqk5e6WKTHuhtbLV4RPBRn40gsh6BXzrWjsqEWePfoLN08jrKR7jf3vAj+tL 2IpdPLyyuWvI6oMPa68JGlfDcOKQ46KmNCyokvoEKZG8+LU4E6nY4CsitTQqvwpD nAuk7ViJSbr70kmxRzuUR/LeZeDlm2sjV4zkiGP50PHUdqhvYGQmiOeKKWzq0nfR vbYYrukS8ATq5WFPMPtNVnd6WZ/wgEbVHUIt3I/h2rAWNrXkobh58ZyvD8g3zLE= =UPwp -----END PGP SIGNATURE----- --F80G8ClCP5bmxHiGcpdLNWobkl9b7otcw--