On 12/6/19 1:02 PM, John Snow wrote:
>> I'm afraid that the only thing is not remove persistent
bitmaps, which
>> were never synced to the image. So, instead the sequence above, we need
>>
>>
>> 1. create persistent bitmap A
>> 2. shutdown vm
>> 3. start vm
>> 4. create persistent bitmap B
>> 5. remember, that we want to remove bitmap B after vm shutdown
>> ...
>> some other operations
>> ...
>> 6. vm shutdown
>> 7. start vm in stopped mode, and remove all bitmaps marked for removing
>> 8. stop vm
>>
>> But, I think that in real circumstances, vm shutdown is rare thing...
Part of me wonders if we would have detected this MUCH sooner if I had
gotten my wish of having the qcow2 metadata updated on creation of any
persistent bitmap (not actually writing out the bitmap itself, just
updating the bitmap table to mark that there is a new persistent
inconsistent bitmap), so that a) qemu-img info -U can see the persistent
bitmap's existence, and b) an unexpected abrupt crash of qemu does not
lose the existence of the bitmap. At the time I raised the question,
the push-back at the time was a desire to minimize writes to the qcow2
metadata at all costs, warranting our current extreme code contortions
to keep persistent bitmaps were kept in memory only until VM shutdown.
But had we been doing it, we would spot problems like this without
having to do VM shutdown, and our code might actually be simpler than
our current contortions. Maybe we should still revisit that decision
(of course, that question is independent of this patch, and therefore
5.0 material at earliest).
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization:
qemu.org |
libvirt.org