Re: [PATCH v4 5/5] qcow2: repair a dirty image when it becomes writable

["Denis V. Lunev" <den@virtuozzo.com>]

On 8/31/26 21:01, Denis V. Lunev wrote:
> On 8/31/26 14:31, Markus Armbruster wrote:
>> "Denis V. Lunev" <den@virtuozzo.com> writes:
>>
>>> On 8/27/26 11:15, Markus Armbruster wrote:
>> [...]
>>
>>>> We must not (re)open a dirty image read/write without cleaning it,
>>>> because writing to risks corruption, i.e. data loss.
>>>>
>>>> When we open a dirty image read/write, we can clean it without
>>>> inconveniencing the guest, because the guest cannot access it until
>>>> after open completes and we connect the newly open image.  Correct?
>>> correct.
>>>
>>>> When we reopen a read/only dirty image read/write, cleaning it *can*
>>>> affect the guest, as discussed above.
>>>>
>>>> As far as I can tell, all the trouble discussed above ultimately comes
>>>> from letting the guest work with read-only dirty images.  Why is that
>>>> useful?
>>>>
>>>> What are the use cases for opening dirty images read-only?
>>> Read only images usually comes in image chains (snapshots, backing
>>> stores). How RO image becomes dirty is very good question. May
>>> be this was due to QEMU stop/node crash during running commit.
>>>
>>> Why this is needed? VM should continue to start with dirty
>>> RO image. Doing maintenance at start? That is also problematic.
>>> At this moment we can face shared lock on base image (so called
>>> golden image scenario).
>> We can "do maintenance" during initial open proactively, or during
>> reopen read/write as needed.
>>
>> In both cases, we risk delays that can make the guest hang.
>>
>> Cleaning as needed might avoid some delays.  It can also shift delays
>> from QEMU startup (sometimes bad) to guest operation (commonly worse).
>>
>> Cleaning as needed in its current state appears to violate
>> blockdev-reopen's contract: it breaks the transaction.  This feels like
>> a regression.
>>
>> I think cleaning as needed poses challenges to management applications.
>> I figure sophisticated ones can make a reasonable choice between "clean
>> offline before you pass to QEMU" and "don't, and manage the delay on
>> reopen".  For less sophisticated ones, and also human users, all this
>> feels like a trap.
>>
>> Have we considered dirty image open to require an "I'm sophisticated"
>> flag?
>>
>> Anyway, this is how far I can take this.  Now the block layer
>> maintainers need to chime in.
>>
>> [...]
> The problem is that we are opening RO and could not change the
> image. That is the worst part and not just by the fact that
> we opening RO (we can try to reopen RW) but by the fact that
> another QEMU has already opened that image and we could not
> take the lock. Reopen here may not happen ever.
>
> Both ways are weird, the question is what is worse? :-)
>
> Den
There are 2 additional note, which I would like to share.

1. Denying start of VM with dirty RO image is no-go for
any migration of such VM over shared storage. Nothing
could be done with such a VM once node would need to be
upgraded and thus to be moved. That would be real hell
for any operation.

2. Though this could be mitigated with an addition of
forced image check through QMP and that makes a lot of
sense. Fixing image integrity for alive VM even with
several seconds pause could be a real life saver. This
functionality smells useful.

Thus we could
* make a check of RO images on start and deny if the fix
could not be made for whatever reason
* and add qmp-image-check as a command for specific node
as command

This could be correct API wise.

Thanks,
    Den