qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 0/2] qcow2: Release read-only bitmaps when inactivated


From: Vladimir Sementsov-Ogievskiy
Subject: Re: [PATCH 0/2] qcow2: Release read-only bitmaps when inactivated
Date: Wed, 5 Aug 2020 11:15:44 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

30.07.2020 15:02, Max Reitz wrote:
Hi,

When beginning migration, the qcow2 driver syncs all persistent bitmaps
to disk and then releases them.  If the user decides to continue on the
source after migration, those bitmaps are re-loaded from the qcow2
image.

However, we only do this for bitmaps that were actively synced, i.e. R/W
bitmaps.  RO bitmaps (those on backing images) are not written and thus
not released.  However, we still try to re-load them when continuing,
and that will then fail.

To fix this problem, I think we should just consider RO bitmaps to be in
sync from the beginning, so we can release them just like bitmaps that
we have actively written back to the image.  This is done by patch 1.

However, there’s a catch: Peter Krempa noted that it isn’t in libvirt’s
interest for the bitmaps to be released before migration at all, because
this makes them disappear from query-named-block-node’s dirty-bitmaps
list, but libvirt needs the bitmaps to be there:

https://bugzilla.redhat.com/show_bug.cgi?id=1858739#c3

If it’s really not feasible to keep the bitmaps around, then I suppose
what might work for libvirt is to query
image/format-specific/data/bitmaps in addition to dirty-bitmaps (every
bitmap that we released before migration must be a persistent bitmap).

What are your thoughts on this?

Sorry, I was on vocation for a week, so missed this. I see, it was merged, 
still, I'll look through it now.

Hmm.

1. Why we sync bitmaps on inactivation: it's obvious, it's the last point when 
it is possible to store them

2. Why we release bitmaps on inactivation: after inactivation, the bitmaps are 
not owned by Qemu. The image is not locked, someone other can change persistent 
bitmaps (target Qemu for example)..



Max Reitz (2):
   qcow2: Release read-only bitmaps when inactivated
   iotests/169: Test source cont with backing bmap

  block/qcow2-bitmap.c       | 23 +++++++++++---
  tests/qemu-iotests/169     | 64 +++++++++++++++++++++++++++++++++++++-
  tests/qemu-iotests/169.out |  4 +--
  3 files changed, 84 insertions(+), 7 deletions(-)



--
Best regards,
Vladimir



reply via email to

[Prev in Thread] Current Thread [Next in Thread]