On 16.02.22 20:46, Vladimir Sementsov-Ogievskiy wrote:
Note that reads zero areas (not dirty in the bitmap) fails, that's
correct.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsement...@virtuozzo.com>
---
tests/qemu-iotests/tests/image-fleecing | 32 ++++++--
tests/qemu-iotests/tests/image-fleecing.out | 84 +++++++++++++++++++++
2 files changed, 108 insertions(+), 8 deletions(-)
Looks good, just one general usage question:
diff --git a/tests/qemu-iotests/tests/image-fleecing
b/tests/qemu-iotests/tests/image-fleecing
index 909fc0a7ad..33995612be 100755
--- a/tests/qemu-iotests/tests/image-fleecing
+++ b/tests/qemu-iotests/tests/image-fleecing
@@ -23,7 +23,7 @@
# Creator/Owner: John Snow <js...@redhat.com>
import iotests
-from iotests import log, qemu_img, qemu_io, qemu_io_silent
+from iotests import log, qemu_img, qemu_io, qemu_io_silent,
qemu_io_pipe_and_status
iotests.script_initialize(
supported_fmts=['qcow2', 'qcow', 'qed', 'vmdk', 'vhdx', 'raw'],
@@ -50,11 +50,15 @@ remainder = [('0xd5', '0x108000', '32k'), # Right-end of
partial-left [1]
('0xcd', '0x3ff0000', '64k')] # patterns[3]
def do_test(use_cbw, use_snapshot_access_filter, base_img_path,
- fleece_img_path, nbd_sock_path, vm):
+ fleece_img_path, nbd_sock_path, vm,
+ bitmap=False):
log('--- Setting up images ---')
log('')
assert qemu_img('create', '-f', iotests.imgfmt, base_img_path, '64M') == 0
+ if bitmap:
+ assert qemu_img('bitmap', '--add', base_img_path, 'bitmap0') == 0
+
if use_snapshot_access_filter:
assert use_cbw
assert qemu_img('create', '-f', 'raw', fleece_img_path, '64M') == 0
@@ -106,12 +110,17 @@ def do_test(use_cbw, use_snapshot_access_filter,
base_img_path,
# Establish CBW from source to fleecing node
if use_cbw:
- log(vm.qmp('blockdev-add', {
+ fl_cbw = {
'driver': 'copy-before-write',
'node-name': 'fl-cbw',
'file': src_node,
'target': tmp_node
- }))
+ }
+
+ if bitmap:
+ fl_cbw['bitmap'] = {'node': src_node, 'name': 'bitmap0'}
+
+ log(vm.qmp('blockdev-add', fl_cbw))
log(vm.qmp('qom-set', path=qom_path, property='drive', value='fl-cbw'))
This makes me wonder how exactly the @bitmap parameter is to be used.
In this case here, we use an active bitmap that tracks all writes, so it
looks like a case of trying to copy the changes since some previous
checkpoint (as a point-in-time state). But if there are any writes
between the blockdev-add and the qom-set, then they will not be included
in the CBW bitmap. Is that fine? Or is it perhaps even intentional?
(Is the idea that one would use a transaction to disable the current
bitmap (say “A”), and add a new one (say “B”) at the same time, then use
bitmap A for the CBW filter, delete it after the backup, and then use B
for the subsequent backup?)