2019-03-07 17:58:38 +03:00
|
|
|
#!/usr/bin/env bash
|
2018-07-02 22:14:58 +03:00
|
|
|
#
|
|
|
|
# Test reading dirty bitmap over NBD
|
|
|
|
#
|
2019-09-21 01:07:29 +03:00
|
|
|
# Copyright (C) 2018-2019 Red Hat, Inc.
|
2018-07-02 22:14:58 +03:00
|
|
|
#
|
|
|
|
# This program is free software; you can redistribute it and/or modify
|
|
|
|
# it under the terms of the GNU General Public License as published by
|
|
|
|
# the Free Software Foundation; either version 2 of the License, or
|
|
|
|
# (at your option) any later version.
|
|
|
|
#
|
|
|
|
# This program is distributed in the hope that it will be useful,
|
|
|
|
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
# GNU General Public License for more details.
|
|
|
|
#
|
|
|
|
# You should have received a copy of the GNU General Public License
|
|
|
|
# along with this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
#
|
|
|
|
|
|
|
|
seq="$(basename $0)"
|
|
|
|
echo "QA output created by $seq"
|
|
|
|
|
|
|
|
status=1 # failure is the default!
|
|
|
|
|
|
|
|
_cleanup()
|
|
|
|
{
|
2019-01-11 22:47:20 +03:00
|
|
|
nbd_server_stop
|
2018-07-02 22:14:58 +03:00
|
|
|
_cleanup_test_img
|
|
|
|
_cleanup_qemu
|
2019-10-17 16:31:52 +03:00
|
|
|
rm -f "$SOCK_DIR/nbd"
|
2018-07-02 22:14:58 +03:00
|
|
|
}
|
|
|
|
trap "_cleanup; exit \$status" 0 1 2 3 15
|
|
|
|
|
|
|
|
# get standard environment, filters and checks
|
|
|
|
. ./common.rc
|
|
|
|
. ./common.filter
|
|
|
|
. ./common.qemu
|
2019-01-11 22:47:20 +03:00
|
|
|
. ./common.nbd
|
2018-07-02 22:14:58 +03:00
|
|
|
|
|
|
|
_supported_fmt qcow2
|
|
|
|
_supported_proto file # uses NBD as well
|
|
|
|
_supported_os Linux
|
2018-07-13 22:15:06 +03:00
|
|
|
# Persistent dirty bitmaps require compat=1.1
|
|
|
|
_unsupported_imgopts 'compat=0.10'
|
2018-07-02 22:14:58 +03:00
|
|
|
|
2018-11-17 00:50:02 +03:00
|
|
|
do_run_qemu()
|
2018-07-02 22:14:58 +03:00
|
|
|
{
|
|
|
|
echo Testing: "$@"
|
|
|
|
$QEMU -nographic -qmp stdio -serial none "$@"
|
|
|
|
echo
|
|
|
|
}
|
|
|
|
|
2018-11-17 00:50:02 +03:00
|
|
|
run_qemu()
|
2018-07-02 22:14:58 +03:00
|
|
|
{
|
|
|
|
do_run_qemu "$@" 2>&1 | _filter_testdir | _filter_qmp \
|
|
|
|
| _filter_qemu | _filter_imgfmt \
|
|
|
|
| _filter_actual_image_size
|
|
|
|
}
|
|
|
|
|
|
|
|
echo
|
2018-11-19 20:29:24 +03:00
|
|
|
echo "=== Create partially sparse image, then add dirty bitmaps ==="
|
2018-07-02 22:14:58 +03:00
|
|
|
echo
|
|
|
|
|
2018-11-19 20:29:24 +03:00
|
|
|
# Two bitmaps, to contrast granularity issues
|
nbd: Only require disabled bitmap for read-only exports
Our initial implementation of x-nbd-server-add-bitmap put
in a restriction because of incremental backups: in that
usage, we are exporting one qcow2 file (the temporary overlay
target of a blockdev-backup sync:none job) and a dirty bitmap
owned by a second qcow2 file (the source of the
blockdev-backup, which is the backing file of the temporary).
While both qcow2 files are still writable (the target in
order to capture copy-on-write of old contents, and the
source in order to track live guest writes in the meantime),
the NBD client expects to see constant data, including the
dirty bitmap. An enabled bitmap in the source would be
modified by guest writes, which is at odds with the NBD
export being a read-only constant view, hence the initial
code choice of enforcing a disabled bitmap (the intent is
that the exposed bitmap was disabled in the same transaction
that started the blockdev-backup job, although we don't want
to track enough state to actually enforce that).
However, consider the case of a bitmap contained in a read-only
node (including when the bitmap is found in a backing layer of
the active image). Because the node can't be modified, the
bitmap won't change due to writes, regardless of whether it is
still enabled. Forbidding the export unless the bitmap is
disabled is awkward, paritcularly since we can't change the
bitmap to be disabled (because the node is read-only).
Alternatively, consider the case of live storage migration,
where management directs the destination to create a writable
NBD server, then performs a drive-mirror from the source to
the target, prior to doing the rest of the live migration.
Since storage migration can be time-consuming, it may be wise
to let the destination include a dirty bitmap to track which
portions it has already received, where even if the migration
is interrupted and restarted, the source can query the
destination block status in order to potentially minimize
re-sending data that has not changed in the meantime on a
second attempt. Such code has not been written, and might not
be trivial (after all, a cluster being marked dirty in the
bitmap does not necessarily guarantee it has the desired
contents), but it makes sense that letting an active dirty
bitmap be exposed and changing alongside writes may prove
useful in the future.
Solve both issues by gating the restriction against a
disabled bitmap to only happen when the caller has requested
a read-only export, and where the BDS that owns the bitmap
(whether or not it is the BDS handed to nbd_export_new() or
from its backing chain) is still writable. We could drop
the check altogether (if management apps are prepared to
deal with a changing bitmap even on a read-only image), but
for now keeping a check for the read-only case still stands
a chance of preventing management errors.
Update iotest 223 to show the looser behavior by leaving
a bitmap enabled the whole run; note that we have to tear
down and re-export a node when handling an error.
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20190111194720.15671-4-eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2019-01-11 22:47:15 +03:00
|
|
|
# Also note that b will be disabled, while b2 is left enabled, to
|
|
|
|
# check for read-only interactions
|
2018-11-19 20:29:24 +03:00
|
|
|
_make_test_img -o cluster_size=4k 4M
|
2018-07-02 22:14:58 +03:00
|
|
|
$QEMU_IO -c 'w -P 0x11 1M 2M' "$TEST_IMG" | _filter_qemu_io
|
|
|
|
run_qemu <<EOF
|
|
|
|
{ "execute": "qmp_capabilities" }
|
|
|
|
{ "execute": "blockdev-add",
|
|
|
|
"arguments": {
|
|
|
|
"driver": "$IMGFMT",
|
|
|
|
"node-name": "n",
|
|
|
|
"file": {
|
|
|
|
"driver": "file",
|
|
|
|
"filename": "$TEST_IMG"
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
{ "execute": "block-dirty-bitmap-add",
|
|
|
|
"arguments": {
|
|
|
|
"node": "n",
|
|
|
|
"name": "b",
|
2018-11-19 20:29:24 +03:00
|
|
|
"persistent": true,
|
|
|
|
"granularity": 65536
|
|
|
|
}
|
|
|
|
}
|
|
|
|
{ "execute": "block-dirty-bitmap-add",
|
|
|
|
"arguments": {
|
|
|
|
"node": "n",
|
|
|
|
"name": "b2",
|
|
|
|
"persistent": true,
|
|
|
|
"granularity": 512
|
2018-07-02 22:14:58 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
{ "execute": "quit" }
|
|
|
|
EOF
|
|
|
|
|
|
|
|
echo
|
|
|
|
echo "=== Write part of the file under active bitmap ==="
|
|
|
|
echo
|
|
|
|
|
2018-11-19 20:29:24 +03:00
|
|
|
$QEMU_IO -c 'w -P 0x22 512 512' -c 'w -P 0x33 2M 2M' "$TEST_IMG" \
|
|
|
|
| _filter_qemu_io
|
2018-07-02 22:14:58 +03:00
|
|
|
|
|
|
|
echo
|
2018-11-19 20:29:24 +03:00
|
|
|
echo "=== End dirty bitmaps, and start serving image over NBD ==="
|
2018-07-02 22:14:58 +03:00
|
|
|
echo
|
|
|
|
|
2019-09-21 01:07:29 +03:00
|
|
|
_launch_qemu -object iothread,id=io0 2> >(_filter_nbd)
|
2018-07-02 22:14:58 +03:00
|
|
|
|
2019-01-11 22:47:13 +03:00
|
|
|
# Intentionally provoke some errors as well, to check error handling
|
2018-07-02 22:14:58 +03:00
|
|
|
silent=
|
|
|
|
_send_qemu_cmd $QEMU_HANDLE '{"execute":"qmp_capabilities"}' "return"
|
|
|
|
_send_qemu_cmd $QEMU_HANDLE '{"execute":"blockdev-add",
|
|
|
|
"arguments":{"driver":"qcow2", "node-name":"n",
|
|
|
|
"file":{"driver":"file", "filename":"'"$TEST_IMG"'"}}}' "return"
|
2018-12-21 12:35:22 +03:00
|
|
|
_send_qemu_cmd $QEMU_HANDLE '{"execute":"block-dirty-bitmap-disable",
|
2018-07-02 22:14:58 +03:00
|
|
|
"arguments":{"node":"n", "name":"b"}}' "return"
|
2019-11-15 00:34:15 +03:00
|
|
|
|
|
|
|
for attempt in normal iothread; do
|
|
|
|
|
|
|
|
echo
|
|
|
|
echo "=== Set up NBD with $attempt access ==="
|
|
|
|
echo
|
|
|
|
if [ $attempt = iothread ]; then
|
|
|
|
_send_qemu_cmd $QEMU_HANDLE '{"execute":"x-blockdev-set-iothread",
|
|
|
|
"arguments":{"node-name":"n", "iothread":"io0"}}' "return"
|
|
|
|
fi
|
|
|
|
|
2019-01-11 22:47:13 +03:00
|
|
|
_send_qemu_cmd $QEMU_HANDLE '{"execute":"nbd-server-add",
|
|
|
|
"arguments":{"device":"n"}}' "error" # Attempt add without server
|
2018-07-02 22:14:58 +03:00
|
|
|
_send_qemu_cmd $QEMU_HANDLE '{"execute":"nbd-server-start",
|
|
|
|
"arguments":{"addr":{"type":"unix",
|
2019-10-17 16:31:52 +03:00
|
|
|
"data":{"path":"'"$SOCK_DIR/nbd"'"}}}}' "return"
|
2019-01-11 22:47:13 +03:00
|
|
|
_send_qemu_cmd $QEMU_HANDLE '{"execute":"nbd-server-start",
|
|
|
|
"arguments":{"addr":{"type":"unix",
|
2019-10-17 16:31:52 +03:00
|
|
|
"data":{"path":"'"$SOCK_DIR/nbd"1'"}}}}' "error" # Attempt second server
|
|
|
|
$QEMU_NBD_PROG -L -k "$SOCK_DIR/nbd"
|
2018-07-02 22:14:58 +03:00
|
|
|
_send_qemu_cmd $QEMU_HANDLE '{"execute":"nbd-server-add",
|
nbd: Allow bitmap export during QMP nbd-server-add
With the experimental x-nbd-server-add-bitmap command, there was
a window of time where an NBD client could see the export but not
the associated dirty bitmap, which can cause a client that planned
on using the dirty bitmap to be forced to treat the entire image
as dirty as a safety fallback. Furthermore, if the QMP client
successfully exports a disk but then fails to add the bitmap, it
has to take on the burden of removing the export. Since we don't
allow changing the exposed dirty bitmap (whether to a different
bitmap, or removing advertisement of the bitmap), it is nicer to
make the bitmap tied to the export at the time the export is
created, with automatic failure to export if the bitmap is not
available.
The experimental command included an optional 'bitmap-export-name'
field for remapping the name exposed over NBD to be different from
the bitmap name stored on disk. However, my libvirt demo code
for implementing differential backups on top of persistent bitmaps
did not need to take advantage of that feature (it is instead
possible to create a new temporary bitmap with the desired name,
use block-dirty-bitmap-merge to merge one or more persistent
bitmaps into the temporary, then associate the temporary with the
NBD export, if control is needed over the exported bitmap name).
Hence, I'm not copying that part of the experiment over to the
stable addition. For more details on the libvirt demo, see
https://www.redhat.com/archives/libvir-list/2018-October/msg01254.html,
https://kvmforum2018.sched.com/event/FzuB/facilitating-incremental-backup-eric-blake-red-hat
This patch focuses on the user interface, and reduces (but does
not completely eliminate) the window where an NBD client can see
the export but not the dirty bitmap, with less work to clean up
after errors. Later patches will add further cleanups now that
this interface is declared stable via a single QMP command,
including removing the race window.
Update test 223 to use the new interface.
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20190111194720.15671-6-eblake@redhat.com>
2019-01-11 22:47:17 +03:00
|
|
|
"arguments":{"device":"n", "bitmap":"b"}}' "return"
|
2019-01-11 22:47:13 +03:00
|
|
|
_send_qemu_cmd $QEMU_HANDLE '{"execute":"nbd-server-add",
|
|
|
|
"arguments":{"device":"nosuch"}}' "error" # Attempt to export missing node
|
|
|
|
_send_qemu_cmd $QEMU_HANDLE '{"execute":"nbd-server-add",
|
|
|
|
"arguments":{"device":"n"}}' "error" # Attempt to export same name twice
|
2018-11-19 20:29:24 +03:00
|
|
|
_send_qemu_cmd $QEMU_HANDLE '{"execute":"nbd-server-add",
|
nbd: Allow bitmap export during QMP nbd-server-add
With the experimental x-nbd-server-add-bitmap command, there was
a window of time where an NBD client could see the export but not
the associated dirty bitmap, which can cause a client that planned
on using the dirty bitmap to be forced to treat the entire image
as dirty as a safety fallback. Furthermore, if the QMP client
successfully exports a disk but then fails to add the bitmap, it
has to take on the burden of removing the export. Since we don't
allow changing the exposed dirty bitmap (whether to a different
bitmap, or removing advertisement of the bitmap), it is nicer to
make the bitmap tied to the export at the time the export is
created, with automatic failure to export if the bitmap is not
available.
The experimental command included an optional 'bitmap-export-name'
field for remapping the name exposed over NBD to be different from
the bitmap name stored on disk. However, my libvirt demo code
for implementing differential backups on top of persistent bitmaps
did not need to take advantage of that feature (it is instead
possible to create a new temporary bitmap with the desired name,
use block-dirty-bitmap-merge to merge one or more persistent
bitmaps into the temporary, then associate the temporary with the
NBD export, if control is needed over the exported bitmap name).
Hence, I'm not copying that part of the experiment over to the
stable addition. For more details on the libvirt demo, see
https://www.redhat.com/archives/libvir-list/2018-October/msg01254.html,
https://kvmforum2018.sched.com/event/FzuB/facilitating-incremental-backup-eric-blake-red-hat
This patch focuses on the user interface, and reduces (but does
not completely eliminate) the window where an NBD client can see
the export but not the dirty bitmap, with less work to clean up
after errors. Later patches will add further cleanups now that
this interface is declared stable via a single QMP command,
including removing the race window.
Update test 223 to use the new interface.
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20190111194720.15671-6-eblake@redhat.com>
2019-01-11 22:47:17 +03:00
|
|
|
"arguments":{"device":"n", "name":"n2",
|
|
|
|
"bitmap":"b2"}}' "error" # enabled vs. read-only
|
nbd: Only require disabled bitmap for read-only exports
Our initial implementation of x-nbd-server-add-bitmap put
in a restriction because of incremental backups: in that
usage, we are exporting one qcow2 file (the temporary overlay
target of a blockdev-backup sync:none job) and a dirty bitmap
owned by a second qcow2 file (the source of the
blockdev-backup, which is the backing file of the temporary).
While both qcow2 files are still writable (the target in
order to capture copy-on-write of old contents, and the
source in order to track live guest writes in the meantime),
the NBD client expects to see constant data, including the
dirty bitmap. An enabled bitmap in the source would be
modified by guest writes, which is at odds with the NBD
export being a read-only constant view, hence the initial
code choice of enforcing a disabled bitmap (the intent is
that the exposed bitmap was disabled in the same transaction
that started the blockdev-backup job, although we don't want
to track enough state to actually enforce that).
However, consider the case of a bitmap contained in a read-only
node (including when the bitmap is found in a backing layer of
the active image). Because the node can't be modified, the
bitmap won't change due to writes, regardless of whether it is
still enabled. Forbidding the export unless the bitmap is
disabled is awkward, paritcularly since we can't change the
bitmap to be disabled (because the node is read-only).
Alternatively, consider the case of live storage migration,
where management directs the destination to create a writable
NBD server, then performs a drive-mirror from the source to
the target, prior to doing the rest of the live migration.
Since storage migration can be time-consuming, it may be wise
to let the destination include a dirty bitmap to track which
portions it has already received, where even if the migration
is interrupted and restarted, the source can query the
destination block status in order to potentially minimize
re-sending data that has not changed in the meantime on a
second attempt. Such code has not been written, and might not
be trivial (after all, a cluster being marked dirty in the
bitmap does not necessarily guarantee it has the desired
contents), but it makes sense that letting an active dirty
bitmap be exposed and changing alongside writes may prove
useful in the future.
Solve both issues by gating the restriction against a
disabled bitmap to only happen when the caller has requested
a read-only export, and where the BDS that owns the bitmap
(whether or not it is the BDS handed to nbd_export_new() or
from its backing chain) is still writable. We could drop
the check altogether (if management apps are prepared to
deal with a changing bitmap even on a read-only image), but
for now keeping a check for the read-only case still stands
a chance of preventing management errors.
Update iotest 223 to show the looser behavior by leaving
a bitmap enabled the whole run; note that we have to tear
down and re-export a node when handling an error.
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20190111194720.15671-4-eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2019-01-11 22:47:15 +03:00
|
|
|
_send_qemu_cmd $QEMU_HANDLE '{"execute":"nbd-server-add",
|
nbd: Allow bitmap export during QMP nbd-server-add
With the experimental x-nbd-server-add-bitmap command, there was
a window of time where an NBD client could see the export but not
the associated dirty bitmap, which can cause a client that planned
on using the dirty bitmap to be forced to treat the entire image
as dirty as a safety fallback. Furthermore, if the QMP client
successfully exports a disk but then fails to add the bitmap, it
has to take on the burden of removing the export. Since we don't
allow changing the exposed dirty bitmap (whether to a different
bitmap, or removing advertisement of the bitmap), it is nicer to
make the bitmap tied to the export at the time the export is
created, with automatic failure to export if the bitmap is not
available.
The experimental command included an optional 'bitmap-export-name'
field for remapping the name exposed over NBD to be different from
the bitmap name stored on disk. However, my libvirt demo code
for implementing differential backups on top of persistent bitmaps
did not need to take advantage of that feature (it is instead
possible to create a new temporary bitmap with the desired name,
use block-dirty-bitmap-merge to merge one or more persistent
bitmaps into the temporary, then associate the temporary with the
NBD export, if control is needed over the exported bitmap name).
Hence, I'm not copying that part of the experiment over to the
stable addition. For more details on the libvirt demo, see
https://www.redhat.com/archives/libvir-list/2018-October/msg01254.html,
https://kvmforum2018.sched.com/event/FzuB/facilitating-incremental-backup-eric-blake-red-hat
This patch focuses on the user interface, and reduces (but does
not completely eliminate) the window where an NBD client can see
the export but not the dirty bitmap, with less work to clean up
after errors. Later patches will add further cleanups now that
this interface is declared stable via a single QMP command,
including removing the race window.
Update test 223 to use the new interface.
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20190111194720.15671-6-eblake@redhat.com>
2019-01-11 22:47:17 +03:00
|
|
|
"arguments":{"device":"n", "name":"n2",
|
|
|
|
"bitmap":"b3"}}' "error" # Missing bitmap
|
|
|
|
_send_qemu_cmd $QEMU_HANDLE '{"execute":"nbd-server-add",
|
|
|
|
"arguments":{"device":"n", "name":"n2", "writable":true,
|
|
|
|
"bitmap":"b2"}}' "return"
|
2019-10-17 16:31:52 +03:00
|
|
|
$QEMU_NBD_PROG -L -k "$SOCK_DIR/nbd"
|
2018-07-02 22:14:58 +03:00
|
|
|
|
|
|
|
echo
|
2018-11-19 20:29:24 +03:00
|
|
|
echo "=== Contrast normal status to large granularity dirty-bitmap ==="
|
2018-07-02 22:14:58 +03:00
|
|
|
echo
|
|
|
|
|
|
|
|
QEMU_IO_OPTIONS=$QEMU_IO_OPTIONS_NO_FMT
|
2019-10-17 16:31:52 +03:00
|
|
|
IMG="driver=nbd,export=n,server.type=unix,server.path=$SOCK_DIR/nbd"
|
2018-11-19 20:29:24 +03:00
|
|
|
$QEMU_IO -r -c 'r -P 0x22 512 512' -c 'r -P 0 512k 512k' -c 'r -P 0x11 1m 1m' \
|
|
|
|
-c 'r -P 0x33 2m 2m' --image-opts "$IMG" | _filter_qemu_io
|
2018-07-02 22:14:58 +03:00
|
|
|
$QEMU_IMG map --output=json --image-opts \
|
|
|
|
"$IMG" | _filter_qemu_img_map
|
|
|
|
$QEMU_IMG map --output=json --image-opts \
|
|
|
|
"$IMG,x-dirty-bitmap=qemu:dirty-bitmap:b" | _filter_qemu_img_map
|
|
|
|
|
2018-11-19 20:29:24 +03:00
|
|
|
echo
|
|
|
|
echo "=== Contrast to small granularity dirty-bitmap ==="
|
|
|
|
echo
|
|
|
|
|
2019-10-17 16:31:52 +03:00
|
|
|
IMG="driver=nbd,export=n2,server.type=unix,server.path=$SOCK_DIR/nbd"
|
2018-11-19 20:29:24 +03:00
|
|
|
$QEMU_IMG map --output=json --image-opts \
|
|
|
|
"$IMG,x-dirty-bitmap=qemu:dirty-bitmap:b2" | _filter_qemu_img_map
|
|
|
|
|
2018-07-02 22:14:58 +03:00
|
|
|
echo
|
2019-01-11 22:47:20 +03:00
|
|
|
echo "=== End qemu NBD server ==="
|
2018-07-02 22:14:58 +03:00
|
|
|
echo
|
|
|
|
|
|
|
|
_send_qemu_cmd $QEMU_HANDLE '{"execute":"nbd-server-remove",
|
|
|
|
"arguments":{"name":"n"}}' "return"
|
2018-11-19 20:29:24 +03:00
|
|
|
_send_qemu_cmd $QEMU_HANDLE '{"execute":"nbd-server-remove",
|
|
|
|
"arguments":{"name":"n2"}}' "return"
|
2019-01-11 22:47:13 +03:00
|
|
|
_send_qemu_cmd $QEMU_HANDLE '{"execute":"nbd-server-remove",
|
|
|
|
"arguments":{"name":"n2"}}' "error" # Attempt duplicate clean
|
2018-07-02 22:14:58 +03:00
|
|
|
_send_qemu_cmd $QEMU_HANDLE '{"execute":"nbd-server-stop"}' "return"
|
2019-01-11 22:47:14 +03:00
|
|
|
_send_qemu_cmd $QEMU_HANDLE '{"execute":"nbd-server-stop"}' "error" # Again
|
2019-11-15 00:34:15 +03:00
|
|
|
|
|
|
|
done
|
|
|
|
|
2018-07-02 22:14:58 +03:00
|
|
|
_send_qemu_cmd $QEMU_HANDLE '{"execute":"quit"}' "return"
|
iotests: Wait for qemu to end in 223
When iotest 223 was first written, it didn't matter if we waited for
the qemu process to clean up. But with the introduction of a later
qemu-nbd process trying to reuse the same file, there is a race where
even though the asynchronous qemu process has responded to "quit", it
has not yet had time to unlock the file and exit, resulting in:
-[{ "start": 0, "length": 65536, "depth": 0, "zero": false, "data": false},
-{ "start": 65536, "length": 2031616, "depth": 0, "zero": false, "data": true},
-{ "start": 2097152, "length": 2097152, "depth": 0, "zero": false, "data": false}]
+qemu-nbd: Failed to blk_new_open 'tests/qemu-iotests/scratch/t.qcow2': Failed to get shared "write" lock
+Is another process using the image [tests/qemu-iotests/scratch/t.qcow2]?
+qemu-img: Could not open 'driver=nbd,server.type=unix,server.path=tests/qemu-iotests/scratch/qemu-nbd.sock,x-dirty-bitmap=qemu:dirty-bitmap:b': Failed to connect socket tests/qemu-iotests/scratch/qemu-nbd.sock: Connection refused
+./common.nbd: line 33: kill: (11122) - No such process
Fixes: ddd09448
Reported-by: Alberto Garcia <berto@igalia.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20190305182908.13557-1-eblake@redhat.com>
Tested-by: Alberto Garcia <berto@igalia.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
2019-03-05 21:29:08 +03:00
|
|
|
wait=yes _cleanup_qemu
|
2018-07-02 22:14:58 +03:00
|
|
|
|
2019-01-11 22:47:20 +03:00
|
|
|
echo
|
|
|
|
echo "=== Use qemu-nbd as server ==="
|
|
|
|
echo
|
|
|
|
|
|
|
|
nbd_server_start_unix_socket -r -f $IMGFMT -B b "$TEST_IMG"
|
|
|
|
IMG="driver=nbd,server.type=unix,server.path=$nbd_unix_socket"
|
|
|
|
$QEMU_IMG map --output=json --image-opts \
|
|
|
|
"$IMG,x-dirty-bitmap=qemu:dirty-bitmap:b" | _filter_qemu_img_map
|
|
|
|
|
|
|
|
nbd_server_start_unix_socket -f $IMGFMT -B b2 "$TEST_IMG"
|
|
|
|
IMG="driver=nbd,server.type=unix,server.path=$nbd_unix_socket"
|
|
|
|
$QEMU_IMG map --output=json --image-opts \
|
|
|
|
"$IMG,x-dirty-bitmap=qemu:dirty-bitmap:b2" | _filter_qemu_img_map
|
|
|
|
|
2018-07-02 22:14:58 +03:00
|
|
|
# success, all done
|
|
|
|
echo '*** done'
|
|
|
|
rm -f $seq.full
|
|
|
|
status=0
|