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 exactly > the same after node poweroff, which could happen and really happens in > the real life from time to time. > > In this cases VMs should start automatically and ASAP if configured this > 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 which >> was attached R/W to the VM. > > 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 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 >> raw. > I would like to have this covered by flock and this indeed working for > years with Parallels. > >> >> 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 >> > 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
signature.asc
Description: OpenPGP digital signature
