summaryrefslogtreecommitdiffstats
path: root/hw/display
diff options
context:
space:
mode:
authorEric Blake2018-07-02 21:14:58 +0200
committerEric Blake2018-07-03 02:50:37 +0200
commita1532a225a183c9fa60b9c1e8ac8a00c7771f64d (patch)
tree1b06dcc85fb145d71d5137de8d8999fb6962ccd4 /hw/display
parentnbd/client: Add x-dirty-bitmap to query bitmap from server (diff)
downloadqemu-a1532a225a183c9fa60b9c1e8ac8a00c7771f64d.tar.gz
qemu-a1532a225a183c9fa60b9c1e8ac8a00c7771f64d.tar.xz
qemu-a1532a225a183c9fa60b9c1e8ac8a00c7771f64d.zip
iotests: New test 223 for exporting dirty bitmap over NBD
Although this test is NOT a full test of image fleecing (as it intentionally uses just a single block device directly exported over NBD, rather than trying to set up a blockdev-backup job with multiple BDS involved), it DOES prove that qemu as a server is able to properly expose a dirty bitmap over NBD. When coupled with image fleecing, it is then possible for a third-party client to do an incremental backup by using qemu-img map with the x-dirty-bitmap option to learn which parts of the file are dirty (perhaps confusingly, they are the portions mapped as "data":false - which is part of the reason this is still in the x- experimental namespace), along with another normal client (perhaps 'qemu-nbd -c' to expose the server over /dev/nbd0 and then just use normal I/O on that block device) to read the dirty sections. Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20180702191458.28741-3-eblake@redhat.com> Tested-by: John Snow <jsnow@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com>
Diffstat (limited to 'hw/display')
0 files changed, 0 insertions, 0 deletions