From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55162) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aG8XF-0007qT-De for qemu-devel@nongnu.org; Mon, 04 Jan 2016 12:03:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aG8XE-0001Ml-ES for qemu-devel@nongnu.org; Mon, 04 Jan 2016 12:03:09 -0500 References: <1450802786-20893-1-git-send-email-kwolf@redhat.com> <20151223031412.GC14423@ad.usersys.redhat.com> <567B2C1F.5030006@redhat.com> <567B8572.4060005@parallels.com> From: Max Reitz Message-ID: <568AA5BC.9000705@redhat.com> Date: Mon, 4 Jan 2016 18:02:52 +0100 MIME-Version: 1.0 In-Reply-To: <567B8572.4060005@parallels.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MvAbUrTq35tRKgc44iO47TO0bjGW6mTpx" Subject: Re: [Qemu-devel] [Qemu-block] [PATCH 00/10] qcow2: Implement image locking List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Denis V. Lunev" , Fam Zheng , Kevin Wolf Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MvAbUrTq35tRKgc44iO47TO0bjGW6mTpx Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 24.12.2015 06:41, Denis V. Lunev wrote: > On 12/24/2015 02:19 AM, Max Reitz wrote: >> 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. > IMHO you are wrong. This is VERY important. The situation would be exac= tly > the same after node poweroff, which could happen and really happens in > the real life from time to time. >=20 > In this cases VMs should start automatically and ASAP if configured thi= s > way. Any manual interaction here is a REAL pain. Thanks, that's a good example. However, I don't know much about management at that layer, so this is probably where I'm out of the discussion. (For instance, I don't know which kind of node you are talking about; I presume it is a physical node, because if it was a virtual node, you'd just kill the qemu instance in question by sending a QMP quit command.) >> 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 whic= h >> was attached R/W to the VM. >=20 > in the situation above libvirt does not have the information or this > information could be unreliable. Well, then s/libvirt/any of the management layers/. As far as I know, qemu-img commands are still used pretty high up in the stack. >>> 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 >>> benefit, >>> and a program crash will automatically drop the lock. >> Making other formats benefit from addressing this issue is a good poin= t, >> 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= >> raw. > I would like to have this covered by flock and this indeed working for > years with Parallels. >=20 >> >> I feel like most of the question which approach to take revolves aroun= d >> "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 >> > pls see above. Node failure and unexpected power loss really matters. Good points indeed (maybe, I can't actually judge, but I'll trust you). Max --MvAbUrTq35tRKgc44iO47TO0bjGW6mTpx 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 iQEcBAEBCAAGBQJWiqW8AAoJEDuxQgLoOKytytwH/3dFxJuAVkhlOizcyA+5Fgsx R+gXqtxqp21D53cCudgQRG37pMBQQ1cC3kx50BuRB/Ba7yt9R78Mvor+5TRwpIKr ITsnoowdfBhtHIGJHuL4xD8DaAw6IxfrHN2N7r4pcl/VxZqDhhUUsH2CFnaKQ7QQ Ex39inPGYxoStRjDOQkV7tDWuI9Oy/2M/p0QVT2M5sV5X7Rzoz6yiS5LuNu8k1p0 /A0tNlNOl1xGxPRlSjPdLUJ6POfvLdR86ti+h11QQxlT17CLU1SfZT9Qy5ng9UN9 5ngF2wLk4f52SpoUeMB/jm6LJN7T+fPqMaiTgCDVzl0gIe0hmjBSGehfeDz6WjU= =VCuH -----END PGP SIGNATURE----- --MvAbUrTq35tRKgc44iO47TO0bjGW6mTpx--