2017-05-02 18:35:57 +02:00
|
|
|
QA output created by 153
|
|
|
|
|
== readonly=off,force-share=on should be rejected ==
|
|
|
|
|
QEMU_PROG: -drive if=none,file=null-co://,readonly=off,force-share=on: force-share=on can only be used with read-only images
|
|
|
|
|
|
|
|
|
|
== Creating base image ==
|
|
|
|
|
Formatting 'TEST_DIR/t.IMGFMT.base', fmt=IMGFMT size=33554432
|
|
|
|
|
|
|
|
|
|
== Creating test image ==
|
iotests: Specify explicit backing format where sensible
There are many existing qcow2 images that specify a backing file but
no format. This has been the source of CVEs in the past, but has
become more prominent of a problem now that libvirt has switched to
-blockdev. With older -drive, at least the probing was always done by
qemu (so the only risk of a changed format between successive boots of
a guest was if qemu was upgraded and probed differently). But with
newer -blockdev, libvirt must specify a format; if libvirt guesses raw
where the image was formatted, this results in data corruption visible
to the guest; conversely, if libvirt guesses qcow2 where qemu was
using raw, this can result in potential security holes, so modern
libvirt instead refuses to use images without explicit backing format.
The change in libvirt to reject images without explicit backing format
has pointed out that a number of tools have been far too reliant on
probing in the past. It's time to set a better example in our own
iotests of properly setting this parameter.
iotest calls to create, rebase, and convert are all impacted to some
degree. It's a bit annoying that we are inconsistent on command line
- while all of those accept -o backing_file=...,backing_fmt=..., the
shortcuts are different: create and rebase have -b and -F, while
convert has -B but no -F. (amend has no shortcuts, but the previous
patch just deprecated the use of amend to change backing chains).
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200706203954.341758-9-eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-06 22:39:52 +02:00
|
|
|
Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=33554432 backing_file=TEST_DIR/t.IMGFMT.base backing_fmt=IMGFMT
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
== Launching QEMU, opts: '' ==
|
|
|
|
|
|
|
|
|
|
== Launching another QEMU, opts: '' ==
|
|
|
|
|
QEMU_PROG: -drive file=TEST_DIR/t.qcow2,if=none,: Failed to get "write" lock
|
2018-09-25 07:05:01 +02:00
|
|
|
Is another process using the image [TEST_DIR/t.qcow2]?
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
== Launching another QEMU, opts: 'read-only=on' ==
|
|
|
|
|
QEMU_PROG: -drive file=TEST_DIR/t.qcow2,if=none,read-only=on: Failed to get shared "write" lock
|
2018-09-25 07:05:01 +02:00
|
|
|
Is another process using the image [TEST_DIR/t.qcow2]?
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
== Launching another QEMU, opts: 'read-only=on,force-share=on' ==
|
|
|
|
|
|
|
|
|
|
== Running utility commands ==
|
|
|
|
|
|
|
|
|
|
_qemu_io_wrapper -c read 0 512 TEST_DIR/t.qcow2
|
2019-04-28 17:54:44 +02:00
|
|
|
qemu-io: can't open device TEST_DIR/t.qcow2: Failed to get "write" lock
|
2018-09-25 07:05:01 +02:00
|
|
|
Is another process using the image [TEST_DIR/t.qcow2]?
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
_qemu_io_wrapper -r -c read 0 512 TEST_DIR/t.qcow2
|
2019-04-28 17:54:44 +02:00
|
|
|
qemu-io: can't open device TEST_DIR/t.qcow2: Failed to get shared "write" lock
|
2018-09-25 07:05:01 +02:00
|
|
|
Is another process using the image [TEST_DIR/t.qcow2]?
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
_qemu_io_wrapper -c open TEST_DIR/t.qcow2 -c read 0 512
|
2019-04-28 17:54:44 +02:00
|
|
|
qemu-io: can't open device TEST_DIR/t.qcow2: Failed to get "write" lock
|
2018-09-25 07:05:01 +02:00
|
|
|
Is another process using the image [TEST_DIR/t.qcow2]?
|
qemu-io: Don't die on second open
Most callback commands in qemu-io return 0 to keep the interpreter
loop running, or 1 to quit immediately. However, open_f() just
passed through the return value of openfile(), which has different
semantics of returning 0 if a file was opened, or 1 on any failure.
As a result of mixing the return semantics, we are forcing the
qemu-io interpreter to exit early on any failures, which is rather
annoying when some of the failures are obviously trying to give
the user a hint of how to proceed (if we didn't then kill qemu-io
out from under the user's feet):
$ qemu-io
qemu-io> open foo
qemu-io> open foo
file open already, try 'help close'
$ echo $?
0
In general, we WANT openfile() to report failures, since it is the
function used in the form 'qemu-io -c "$something" no_such_file'
for performing one or more -c options on a single file, and it is
not worth attempting $something if the file itself cannot be opened.
So the solution is to fix open_f() to always return 0 (when we are
in interactive mode, even failure to open should not end the
session), and save the return value of openfile() for command line
use in main().
Note, however, that we do have some qemu-iotests that do 'qemu-io
-c "open file" -c "$something"'; such tests will now proceed to
attempt $something whether or not the open succeeded, the same way
as if the two commands had been attempted in interactive mode. As
such, the expected output for those tests has to be modified. But it
also means that it is now possible to use -c close and have a single
qemu-io command line operate on more than one file even without
using interactive mode. Although the '-c open' action is a subtle
change in behavior, remember that qemu-io is for debugging purposes,
so as long as it serves the needs of qemu-iotests while still being
reasonable for interactive use, it should not be a problem that we
are changing tests to the new behavior.
This has been awkward since at least as far back as commit
e3aff4f, in 2009.
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-06-05 22:38:42 +02:00
|
|
|
no file open, try 'help open'
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
_qemu_io_wrapper -c open -r TEST_DIR/t.qcow2 -c read 0 512
|
2019-04-28 17:54:44 +02:00
|
|
|
qemu-io: can't open device TEST_DIR/t.qcow2: Failed to get shared "write" lock
|
2018-09-25 07:05:01 +02:00
|
|
|
Is another process using the image [TEST_DIR/t.qcow2]?
|
qemu-io: Don't die on second open
Most callback commands in qemu-io return 0 to keep the interpreter
loop running, or 1 to quit immediately. However, open_f() just
passed through the return value of openfile(), which has different
semantics of returning 0 if a file was opened, or 1 on any failure.
As a result of mixing the return semantics, we are forcing the
qemu-io interpreter to exit early on any failures, which is rather
annoying when some of the failures are obviously trying to give
the user a hint of how to proceed (if we didn't then kill qemu-io
out from under the user's feet):
$ qemu-io
qemu-io> open foo
qemu-io> open foo
file open already, try 'help close'
$ echo $?
0
In general, we WANT openfile() to report failures, since it is the
function used in the form 'qemu-io -c "$something" no_such_file'
for performing one or more -c options on a single file, and it is
not worth attempting $something if the file itself cannot be opened.
So the solution is to fix open_f() to always return 0 (when we are
in interactive mode, even failure to open should not end the
session), and save the return value of openfile() for command line
use in main().
Note, however, that we do have some qemu-iotests that do 'qemu-io
-c "open file" -c "$something"'; such tests will now proceed to
attempt $something whether or not the open succeeded, the same way
as if the two commands had been attempted in interactive mode. As
such, the expected output for those tests has to be modified. But it
also means that it is now possible to use -c close and have a single
qemu-io command line operate on more than one file even without
using interactive mode. Although the '-c open' action is a subtle
change in behavior, remember that qemu-io is for debugging purposes,
so as long as it serves the needs of qemu-iotests while still being
reasonable for interactive use, it should not be a problem that we
are changing tests to the new behavior.
This has been awkward since at least as far back as commit
e3aff4f, in 2009.
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-06-05 22:38:42 +02:00
|
|
|
no file open, try 'help open'
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
_qemu_img_wrapper info TEST_DIR/t.qcow2
|
|
|
|
|
qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get shared "write" lock
|
2018-09-25 07:05:01 +02:00
|
|
|
Is another process using the image [TEST_DIR/t.qcow2]?
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
_qemu_img_wrapper check TEST_DIR/t.qcow2
|
|
|
|
|
qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get shared "write" lock
|
2018-09-25 07:05:01 +02:00
|
|
|
Is another process using the image [TEST_DIR/t.qcow2]?
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
_qemu_img_wrapper compare TEST_DIR/t.qcow2 TEST_DIR/t.qcow2
|
|
|
|
|
qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get shared "write" lock
|
2018-09-25 07:05:01 +02:00
|
|
|
Is another process using the image [TEST_DIR/t.qcow2]?
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
_qemu_img_wrapper map TEST_DIR/t.qcow2
|
|
|
|
|
qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get shared "write" lock
|
2018-09-25 07:05:01 +02:00
|
|
|
Is another process using the image [TEST_DIR/t.qcow2]?
|
2017-05-02 18:35:57 +02:00
|
|
|
|
2020-05-04 15:19:59 +02:00
|
|
|
_qemu_img_wrapper amend -o size=32M TEST_DIR/t.qcow2
|
2017-05-02 18:35:57 +02:00
|
|
|
qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get "write" lock
|
2018-09-25 07:05:01 +02:00
|
|
|
Is another process using the image [TEST_DIR/t.qcow2]?
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
_qemu_img_wrapper commit TEST_DIR/t.qcow2
|
|
|
|
|
qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get "write" lock
|
2018-09-25 07:05:01 +02:00
|
|
|
Is another process using the image [TEST_DIR/t.qcow2]?
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
_qemu_img_wrapper resize TEST_DIR/t.qcow2 32M
|
|
|
|
|
qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get "write" lock
|
2018-09-25 07:05:01 +02:00
|
|
|
Is another process using the image [TEST_DIR/t.qcow2]?
|
2017-05-02 18:35:57 +02:00
|
|
|
|
iotests: Specify explicit backing format where sensible
There are many existing qcow2 images that specify a backing file but
no format. This has been the source of CVEs in the past, but has
become more prominent of a problem now that libvirt has switched to
-blockdev. With older -drive, at least the probing was always done by
qemu (so the only risk of a changed format between successive boots of
a guest was if qemu was upgraded and probed differently). But with
newer -blockdev, libvirt must specify a format; if libvirt guesses raw
where the image was formatted, this results in data corruption visible
to the guest; conversely, if libvirt guesses qcow2 where qemu was
using raw, this can result in potential security holes, so modern
libvirt instead refuses to use images without explicit backing format.
The change in libvirt to reject images without explicit backing format
has pointed out that a number of tools have been far too reliant on
probing in the past. It's time to set a better example in our own
iotests of properly setting this parameter.
iotest calls to create, rebase, and convert are all impacted to some
degree. It's a bit annoying that we are inconsistent on command line
- while all of those accept -o backing_file=...,backing_fmt=..., the
shortcuts are different: create and rebase have -b and -F, while
convert has -B but no -F. (amend has no shortcuts, but the previous
patch just deprecated the use of amend to change backing chains).
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200706203954.341758-9-eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-06 22:39:52 +02:00
|
|
|
_qemu_img_wrapper rebase TEST_DIR/t.qcow2 -b TEST_DIR/t.qcow2.base -F qcow2
|
2017-05-02 18:35:57 +02:00
|
|
|
qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get "write" lock
|
2018-09-25 07:05:01 +02:00
|
|
|
Is another process using the image [TEST_DIR/t.qcow2]?
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
_qemu_img_wrapper snapshot -l TEST_DIR/t.qcow2
|
|
|
|
|
qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get shared "write" lock
|
2018-09-25 07:05:01 +02:00
|
|
|
Is another process using the image [TEST_DIR/t.qcow2]?
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
_qemu_img_wrapper convert TEST_DIR/t.qcow2 TEST_DIR/t.qcow2.convert
|
|
|
|
|
qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get shared "write" lock
|
2018-09-25 07:05:01 +02:00
|
|
|
Is another process using the image [TEST_DIR/t.qcow2]?
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
_qemu_img_wrapper dd if=TEST_DIR/t.qcow2 of=TEST_DIR/t.qcow2.convert bs=512 count=1
|
|
|
|
|
qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get shared "write" lock
|
2018-09-25 07:05:01 +02:00
|
|
|
Is another process using the image [TEST_DIR/t.qcow2]?
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
_qemu_img_wrapper bench -c 1 TEST_DIR/t.qcow2
|
|
|
|
|
qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get shared "write" lock
|
2018-09-25 07:05:01 +02:00
|
|
|
Is another process using the image [TEST_DIR/t.qcow2]?
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
_qemu_img_wrapper bench -w -c 1 TEST_DIR/t.qcow2
|
|
|
|
|
qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get "write" lock
|
2018-09-25 07:05:01 +02:00
|
|
|
Is another process using the image [TEST_DIR/t.qcow2]?
|
2017-05-02 18:35:57 +02:00
|
|
|
|
iotests: Specify explicit backing format where sensible
There are many existing qcow2 images that specify a backing file but
no format. This has been the source of CVEs in the past, but has
become more prominent of a problem now that libvirt has switched to
-blockdev. With older -drive, at least the probing was always done by
qemu (so the only risk of a changed format between successive boots of
a guest was if qemu was upgraded and probed differently). But with
newer -blockdev, libvirt must specify a format; if libvirt guesses raw
where the image was formatted, this results in data corruption visible
to the guest; conversely, if libvirt guesses qcow2 where qemu was
using raw, this can result in potential security holes, so modern
libvirt instead refuses to use images without explicit backing format.
The change in libvirt to reject images without explicit backing format
has pointed out that a number of tools have been far too reliant on
probing in the past. It's time to set a better example in our own
iotests of properly setting this parameter.
iotest calls to create, rebase, and convert are all impacted to some
degree. It's a bit annoying that we are inconsistent on command line
- while all of those accept -o backing_file=...,backing_fmt=..., the
shortcuts are different: create and rebase have -b and -F, while
convert has -B but no -F. (amend has no shortcuts, but the previous
patch just deprecated the use of amend to change backing chains).
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200706203954.341758-9-eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-06 22:39:52 +02:00
|
|
|
_qemu_img_wrapper create -f qcow2 TEST_DIR/t.qcow2 -b TEST_DIR/t.qcow2.base -F qcow2
|
2018-05-09 23:53:36 +02:00
|
|
|
qemu-img: TEST_DIR/t.qcow2: Failed to get "write" lock
|
2018-09-25 07:05:01 +02:00
|
|
|
Is another process using the image [TEST_DIR/t.qcow2]?
|
2018-05-09 23:53:36 +02:00
|
|
|
file format: IMGFMT
|
iotests: Specify explicit backing format where sensible
There are many existing qcow2 images that specify a backing file but
no format. This has been the source of CVEs in the past, but has
become more prominent of a problem now that libvirt has switched to
-blockdev. With older -drive, at least the probing was always done by
qemu (so the only risk of a changed format between successive boots of
a guest was if qemu was upgraded and probed differently). But with
newer -blockdev, libvirt must specify a format; if libvirt guesses raw
where the image was formatted, this results in data corruption visible
to the guest; conversely, if libvirt guesses qcow2 where qemu was
using raw, this can result in potential security holes, so modern
libvirt instead refuses to use images without explicit backing format.
The change in libvirt to reject images without explicit backing format
has pointed out that a number of tools have been far too reliant on
probing in the past. It's time to set a better example in our own
iotests of properly setting this parameter.
iotest calls to create, rebase, and convert are all impacted to some
degree. It's a bit annoying that we are inconsistent on command line
- while all of those accept -o backing_file=...,backing_fmt=..., the
shortcuts are different: create and rebase have -b and -F, while
convert has -B but no -F. (amend has no shortcuts, but the previous
patch just deprecated the use of amend to change backing chains).
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200706203954.341758-9-eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-06 22:39:52 +02:00
|
|
|
backing file format: IMGFMT
|
2018-05-09 23:53:36 +02:00
|
|
|
|
2017-05-02 18:35:57 +02:00
|
|
|
== Running utility commands -U ==
|
|
|
|
|
|
|
|
|
|
_qemu_io_wrapper -U -c read 0 512 TEST_DIR/t.qcow2
|
2019-04-28 17:54:44 +02:00
|
|
|
qemu-io: can't open device TEST_DIR/t.qcow2: force-share=on can only be used with read-only images
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
_qemu_io_wrapper -U -r -c read 0 512 TEST_DIR/t.qcow2
|
|
|
|
|
|
|
|
|
|
_qemu_io_wrapper -c open -U TEST_DIR/t.qcow2 -c read 0 512
|
2019-04-28 17:54:44 +02:00
|
|
|
qemu-io: can't open device TEST_DIR/t.qcow2: force-share=on can only be used with read-only images
|
qemu-io: Don't die on second open
Most callback commands in qemu-io return 0 to keep the interpreter
loop running, or 1 to quit immediately. However, open_f() just
passed through the return value of openfile(), which has different
semantics of returning 0 if a file was opened, or 1 on any failure.
As a result of mixing the return semantics, we are forcing the
qemu-io interpreter to exit early on any failures, which is rather
annoying when some of the failures are obviously trying to give
the user a hint of how to proceed (if we didn't then kill qemu-io
out from under the user's feet):
$ qemu-io
qemu-io> open foo
qemu-io> open foo
file open already, try 'help close'
$ echo $?
0
In general, we WANT openfile() to report failures, since it is the
function used in the form 'qemu-io -c "$something" no_such_file'
for performing one or more -c options on a single file, and it is
not worth attempting $something if the file itself cannot be opened.
So the solution is to fix open_f() to always return 0 (when we are
in interactive mode, even failure to open should not end the
session), and save the return value of openfile() for command line
use in main().
Note, however, that we do have some qemu-iotests that do 'qemu-io
-c "open file" -c "$something"'; such tests will now proceed to
attempt $something whether or not the open succeeded, the same way
as if the two commands had been attempted in interactive mode. As
such, the expected output for those tests has to be modified. But it
also means that it is now possible to use -c close and have a single
qemu-io command line operate on more than one file even without
using interactive mode. Although the '-c open' action is a subtle
change in behavior, remember that qemu-io is for debugging purposes,
so as long as it serves the needs of qemu-iotests while still being
reasonable for interactive use, it should not be a problem that we
are changing tests to the new behavior.
This has been awkward since at least as far back as commit
e3aff4f, in 2009.
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-06-05 22:38:42 +02:00
|
|
|
no file open, try 'help open'
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
_qemu_io_wrapper -c open -r -U TEST_DIR/t.qcow2 -c read 0 512
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper info -U TEST_DIR/t.qcow2
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper check -U TEST_DIR/t.qcow2
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper compare -U TEST_DIR/t.qcow2 TEST_DIR/t.qcow2
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper map -U TEST_DIR/t.qcow2
|
|
|
|
|
|
2020-05-04 15:19:59 +02:00
|
|
|
_qemu_img_wrapper amend -o size=32M -U TEST_DIR/t.qcow2
|
2017-05-02 18:35:57 +02:00
|
|
|
qemu-img: unrecognized option '-U'
|
|
|
|
|
Try 'qemu-img --help' for more information
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper commit -U TEST_DIR/t.qcow2
|
|
|
|
|
qemu-img: unrecognized option '-U'
|
|
|
|
|
Try 'qemu-img --help' for more information
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper resize -U TEST_DIR/t.qcow2 32M
|
|
|
|
|
qemu-img: unrecognized option '-U'
|
|
|
|
|
Try 'qemu-img --help' for more information
|
|
|
|
|
|
iotests: Specify explicit backing format where sensible
There are many existing qcow2 images that specify a backing file but
no format. This has been the source of CVEs in the past, but has
become more prominent of a problem now that libvirt has switched to
-blockdev. With older -drive, at least the probing was always done by
qemu (so the only risk of a changed format between successive boots of
a guest was if qemu was upgraded and probed differently). But with
newer -blockdev, libvirt must specify a format; if libvirt guesses raw
where the image was formatted, this results in data corruption visible
to the guest; conversely, if libvirt guesses qcow2 where qemu was
using raw, this can result in potential security holes, so modern
libvirt instead refuses to use images without explicit backing format.
The change in libvirt to reject images without explicit backing format
has pointed out that a number of tools have been far too reliant on
probing in the past. It's time to set a better example in our own
iotests of properly setting this parameter.
iotest calls to create, rebase, and convert are all impacted to some
degree. It's a bit annoying that we are inconsistent on command line
- while all of those accept -o backing_file=...,backing_fmt=..., the
shortcuts are different: create and rebase have -b and -F, while
convert has -B but no -F. (amend has no shortcuts, but the previous
patch just deprecated the use of amend to change backing chains).
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200706203954.341758-9-eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-06 22:39:52 +02:00
|
|
|
_qemu_img_wrapper rebase -U TEST_DIR/t.qcow2 -b TEST_DIR/t.qcow2.base -F qcow2
|
2017-05-02 18:35:57 +02:00
|
|
|
qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get "write" lock
|
2018-09-25 07:05:01 +02:00
|
|
|
Is another process using the image [TEST_DIR/t.qcow2]?
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
_qemu_img_wrapper snapshot -l -U TEST_DIR/t.qcow2
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper convert -U TEST_DIR/t.qcow2 TEST_DIR/t.qcow2.convert
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper dd -U if=TEST_DIR/t.qcow2 of=TEST_DIR/t.qcow2.convert bs=512 count=1
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper bench -U -c 1 TEST_DIR/t.qcow2
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper bench -U -w -c 1 TEST_DIR/t.qcow2
|
|
|
|
|
qemu-img: Could not open 'TEST_DIR/t.qcow2': force-share=on can only be used with read-only images
|
2019-11-14 22:34:14 +01:00
|
|
|
{ 'execute': 'quit' }
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
Round done
|
|
|
|
|
|
|
|
|
|
== Creating base image ==
|
|
|
|
|
Formatting 'TEST_DIR/t.IMGFMT.base', fmt=IMGFMT size=33554432
|
|
|
|
|
|
|
|
|
|
== Creating test image ==
|
iotests: Specify explicit backing format where sensible
There are many existing qcow2 images that specify a backing file but
no format. This has been the source of CVEs in the past, but has
become more prominent of a problem now that libvirt has switched to
-blockdev. With older -drive, at least the probing was always done by
qemu (so the only risk of a changed format between successive boots of
a guest was if qemu was upgraded and probed differently). But with
newer -blockdev, libvirt must specify a format; if libvirt guesses raw
where the image was formatted, this results in data corruption visible
to the guest; conversely, if libvirt guesses qcow2 where qemu was
using raw, this can result in potential security holes, so modern
libvirt instead refuses to use images without explicit backing format.
The change in libvirt to reject images without explicit backing format
has pointed out that a number of tools have been far too reliant on
probing in the past. It's time to set a better example in our own
iotests of properly setting this parameter.
iotest calls to create, rebase, and convert are all impacted to some
degree. It's a bit annoying that we are inconsistent on command line
- while all of those accept -o backing_file=...,backing_fmt=..., the
shortcuts are different: create and rebase have -b and -F, while
convert has -B but no -F. (amend has no shortcuts, but the previous
patch just deprecated the use of amend to change backing chains).
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200706203954.341758-9-eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-06 22:39:52 +02:00
|
|
|
Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=33554432 backing_file=TEST_DIR/t.IMGFMT.base backing_fmt=IMGFMT
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
== Launching QEMU, opts: 'read-only=on' ==
|
|
|
|
|
|
|
|
|
|
== Launching another QEMU, opts: '' ==
|
|
|
|
|
QEMU_PROG: -drive file=TEST_DIR/t.qcow2,if=none,: Failed to get "write" lock
|
2018-09-25 07:05:01 +02:00
|
|
|
Is another process using the image [TEST_DIR/t.qcow2]?
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
== Launching another QEMU, opts: 'read-only=on' ==
|
|
|
|
|
|
|
|
|
|
== Launching another QEMU, opts: 'read-only=on,force-share=on' ==
|
|
|
|
|
|
|
|
|
|
== Running utility commands ==
|
|
|
|
|
|
|
|
|
|
_qemu_io_wrapper -c read 0 512 TEST_DIR/t.qcow2
|
2019-04-28 17:54:44 +02:00
|
|
|
qemu-io: can't open device TEST_DIR/t.qcow2: Failed to get "write" lock
|
2018-09-25 07:05:01 +02:00
|
|
|
Is another process using the image [TEST_DIR/t.qcow2]?
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
_qemu_io_wrapper -r -c read 0 512 TEST_DIR/t.qcow2
|
|
|
|
|
|
|
|
|
|
_qemu_io_wrapper -c open TEST_DIR/t.qcow2 -c read 0 512
|
2019-04-28 17:54:44 +02:00
|
|
|
qemu-io: can't open device TEST_DIR/t.qcow2: Failed to get "write" lock
|
2018-09-25 07:05:01 +02:00
|
|
|
Is another process using the image [TEST_DIR/t.qcow2]?
|
qemu-io: Don't die on second open
Most callback commands in qemu-io return 0 to keep the interpreter
loop running, or 1 to quit immediately. However, open_f() just
passed through the return value of openfile(), which has different
semantics of returning 0 if a file was opened, or 1 on any failure.
As a result of mixing the return semantics, we are forcing the
qemu-io interpreter to exit early on any failures, which is rather
annoying when some of the failures are obviously trying to give
the user a hint of how to proceed (if we didn't then kill qemu-io
out from under the user's feet):
$ qemu-io
qemu-io> open foo
qemu-io> open foo
file open already, try 'help close'
$ echo $?
0
In general, we WANT openfile() to report failures, since it is the
function used in the form 'qemu-io -c "$something" no_such_file'
for performing one or more -c options on a single file, and it is
not worth attempting $something if the file itself cannot be opened.
So the solution is to fix open_f() to always return 0 (when we are
in interactive mode, even failure to open should not end the
session), and save the return value of openfile() for command line
use in main().
Note, however, that we do have some qemu-iotests that do 'qemu-io
-c "open file" -c "$something"'; such tests will now proceed to
attempt $something whether or not the open succeeded, the same way
as if the two commands had been attempted in interactive mode. As
such, the expected output for those tests has to be modified. But it
also means that it is now possible to use -c close and have a single
qemu-io command line operate on more than one file even without
using interactive mode. Although the '-c open' action is a subtle
change in behavior, remember that qemu-io is for debugging purposes,
so as long as it serves the needs of qemu-iotests while still being
reasonable for interactive use, it should not be a problem that we
are changing tests to the new behavior.
This has been awkward since at least as far back as commit
e3aff4f, in 2009.
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-06-05 22:38:42 +02:00
|
|
|
no file open, try 'help open'
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
_qemu_io_wrapper -c open -r TEST_DIR/t.qcow2 -c read 0 512
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper info TEST_DIR/t.qcow2
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper check TEST_DIR/t.qcow2
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper compare TEST_DIR/t.qcow2 TEST_DIR/t.qcow2
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper map TEST_DIR/t.qcow2
|
|
|
|
|
|
2020-05-04 15:19:59 +02:00
|
|
|
_qemu_img_wrapper amend -o size=32M TEST_DIR/t.qcow2
|
2017-05-02 18:35:57 +02:00
|
|
|
qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get "write" lock
|
2018-09-25 07:05:01 +02:00
|
|
|
Is another process using the image [TEST_DIR/t.qcow2]?
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
_qemu_img_wrapper commit TEST_DIR/t.qcow2
|
|
|
|
|
qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get "write" lock
|
2018-09-25 07:05:01 +02:00
|
|
|
Is another process using the image [TEST_DIR/t.qcow2]?
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
_qemu_img_wrapper resize TEST_DIR/t.qcow2 32M
|
|
|
|
|
qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get "write" lock
|
2018-09-25 07:05:01 +02:00
|
|
|
Is another process using the image [TEST_DIR/t.qcow2]?
|
2017-05-02 18:35:57 +02:00
|
|
|
|
iotests: Specify explicit backing format where sensible
There are many existing qcow2 images that specify a backing file but
no format. This has been the source of CVEs in the past, but has
become more prominent of a problem now that libvirt has switched to
-blockdev. With older -drive, at least the probing was always done by
qemu (so the only risk of a changed format between successive boots of
a guest was if qemu was upgraded and probed differently). But with
newer -blockdev, libvirt must specify a format; if libvirt guesses raw
where the image was formatted, this results in data corruption visible
to the guest; conversely, if libvirt guesses qcow2 where qemu was
using raw, this can result in potential security holes, so modern
libvirt instead refuses to use images without explicit backing format.
The change in libvirt to reject images without explicit backing format
has pointed out that a number of tools have been far too reliant on
probing in the past. It's time to set a better example in our own
iotests of properly setting this parameter.
iotest calls to create, rebase, and convert are all impacted to some
degree. It's a bit annoying that we are inconsistent on command line
- while all of those accept -o backing_file=...,backing_fmt=..., the
shortcuts are different: create and rebase have -b and -F, while
convert has -B but no -F. (amend has no shortcuts, but the previous
patch just deprecated the use of amend to change backing chains).
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200706203954.341758-9-eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-06 22:39:52 +02:00
|
|
|
_qemu_img_wrapper rebase TEST_DIR/t.qcow2 -b TEST_DIR/t.qcow2.base -F qcow2
|
2017-05-02 18:35:57 +02:00
|
|
|
qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get "write" lock
|
2018-09-25 07:05:01 +02:00
|
|
|
Is another process using the image [TEST_DIR/t.qcow2]?
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
_qemu_img_wrapper snapshot -l TEST_DIR/t.qcow2
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper convert TEST_DIR/t.qcow2 TEST_DIR/t.qcow2.convert
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper dd if=TEST_DIR/t.qcow2 of=TEST_DIR/t.qcow2.convert bs=512 count=1
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper bench -c 1 TEST_DIR/t.qcow2
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper bench -w -c 1 TEST_DIR/t.qcow2
|
|
|
|
|
qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get "write" lock
|
2018-09-25 07:05:01 +02:00
|
|
|
Is another process using the image [TEST_DIR/t.qcow2]?
|
2017-05-02 18:35:57 +02:00
|
|
|
|
iotests: Specify explicit backing format where sensible
There are many existing qcow2 images that specify a backing file but
no format. This has been the source of CVEs in the past, but has
become more prominent of a problem now that libvirt has switched to
-blockdev. With older -drive, at least the probing was always done by
qemu (so the only risk of a changed format between successive boots of
a guest was if qemu was upgraded and probed differently). But with
newer -blockdev, libvirt must specify a format; if libvirt guesses raw
where the image was formatted, this results in data corruption visible
to the guest; conversely, if libvirt guesses qcow2 where qemu was
using raw, this can result in potential security holes, so modern
libvirt instead refuses to use images without explicit backing format.
The change in libvirt to reject images without explicit backing format
has pointed out that a number of tools have been far too reliant on
probing in the past. It's time to set a better example in our own
iotests of properly setting this parameter.
iotest calls to create, rebase, and convert are all impacted to some
degree. It's a bit annoying that we are inconsistent on command line
- while all of those accept -o backing_file=...,backing_fmt=..., the
shortcuts are different: create and rebase have -b and -F, while
convert has -B but no -F. (amend has no shortcuts, but the previous
patch just deprecated the use of amend to change backing chains).
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200706203954.341758-9-eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-06 22:39:52 +02:00
|
|
|
_qemu_img_wrapper create -f qcow2 TEST_DIR/t.qcow2 -b TEST_DIR/t.qcow2.base -F qcow2
|
2018-05-09 23:53:36 +02:00
|
|
|
qemu-img: TEST_DIR/t.qcow2: Failed to get "write" lock
|
2018-09-25 07:05:01 +02:00
|
|
|
Is another process using the image [TEST_DIR/t.qcow2]?
|
2018-05-09 23:53:36 +02:00
|
|
|
file format: IMGFMT
|
iotests: Specify explicit backing format where sensible
There are many existing qcow2 images that specify a backing file but
no format. This has been the source of CVEs in the past, but has
become more prominent of a problem now that libvirt has switched to
-blockdev. With older -drive, at least the probing was always done by
qemu (so the only risk of a changed format between successive boots of
a guest was if qemu was upgraded and probed differently). But with
newer -blockdev, libvirt must specify a format; if libvirt guesses raw
where the image was formatted, this results in data corruption visible
to the guest; conversely, if libvirt guesses qcow2 where qemu was
using raw, this can result in potential security holes, so modern
libvirt instead refuses to use images without explicit backing format.
The change in libvirt to reject images without explicit backing format
has pointed out that a number of tools have been far too reliant on
probing in the past. It's time to set a better example in our own
iotests of properly setting this parameter.
iotest calls to create, rebase, and convert are all impacted to some
degree. It's a bit annoying that we are inconsistent on command line
- while all of those accept -o backing_file=...,backing_fmt=..., the
shortcuts are different: create and rebase have -b and -F, while
convert has -B but no -F. (amend has no shortcuts, but the previous
patch just deprecated the use of amend to change backing chains).
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200706203954.341758-9-eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-06 22:39:52 +02:00
|
|
|
backing file format: IMGFMT
|
2018-05-09 23:53:36 +02:00
|
|
|
|
2017-05-02 18:35:57 +02:00
|
|
|
== Running utility commands -U ==
|
|
|
|
|
|
|
|
|
|
_qemu_io_wrapper -U -c read 0 512 TEST_DIR/t.qcow2
|
2019-04-28 17:54:44 +02:00
|
|
|
qemu-io: can't open device TEST_DIR/t.qcow2: force-share=on can only be used with read-only images
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
_qemu_io_wrapper -U -r -c read 0 512 TEST_DIR/t.qcow2
|
|
|
|
|
|
|
|
|
|
_qemu_io_wrapper -c open -U TEST_DIR/t.qcow2 -c read 0 512
|
2019-04-28 17:54:44 +02:00
|
|
|
qemu-io: can't open device TEST_DIR/t.qcow2: force-share=on can only be used with read-only images
|
qemu-io: Don't die on second open
Most callback commands in qemu-io return 0 to keep the interpreter
loop running, or 1 to quit immediately. However, open_f() just
passed through the return value of openfile(), which has different
semantics of returning 0 if a file was opened, or 1 on any failure.
As a result of mixing the return semantics, we are forcing the
qemu-io interpreter to exit early on any failures, which is rather
annoying when some of the failures are obviously trying to give
the user a hint of how to proceed (if we didn't then kill qemu-io
out from under the user's feet):
$ qemu-io
qemu-io> open foo
qemu-io> open foo
file open already, try 'help close'
$ echo $?
0
In general, we WANT openfile() to report failures, since it is the
function used in the form 'qemu-io -c "$something" no_such_file'
for performing one or more -c options on a single file, and it is
not worth attempting $something if the file itself cannot be opened.
So the solution is to fix open_f() to always return 0 (when we are
in interactive mode, even failure to open should not end the
session), and save the return value of openfile() for command line
use in main().
Note, however, that we do have some qemu-iotests that do 'qemu-io
-c "open file" -c "$something"'; such tests will now proceed to
attempt $something whether or not the open succeeded, the same way
as if the two commands had been attempted in interactive mode. As
such, the expected output for those tests has to be modified. But it
also means that it is now possible to use -c close and have a single
qemu-io command line operate on more than one file even without
using interactive mode. Although the '-c open' action is a subtle
change in behavior, remember that qemu-io is for debugging purposes,
so as long as it serves the needs of qemu-iotests while still being
reasonable for interactive use, it should not be a problem that we
are changing tests to the new behavior.
This has been awkward since at least as far back as commit
e3aff4f, in 2009.
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-06-05 22:38:42 +02:00
|
|
|
no file open, try 'help open'
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
_qemu_io_wrapper -c open -r -U TEST_DIR/t.qcow2 -c read 0 512
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper info -U TEST_DIR/t.qcow2
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper check -U TEST_DIR/t.qcow2
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper compare -U TEST_DIR/t.qcow2 TEST_DIR/t.qcow2
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper map -U TEST_DIR/t.qcow2
|
|
|
|
|
|
2020-05-04 15:19:59 +02:00
|
|
|
_qemu_img_wrapper amend -o size=32M -U TEST_DIR/t.qcow2
|
2017-05-02 18:35:57 +02:00
|
|
|
qemu-img: unrecognized option '-U'
|
|
|
|
|
Try 'qemu-img --help' for more information
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper commit -U TEST_DIR/t.qcow2
|
|
|
|
|
qemu-img: unrecognized option '-U'
|
|
|
|
|
Try 'qemu-img --help' for more information
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper resize -U TEST_DIR/t.qcow2 32M
|
|
|
|
|
qemu-img: unrecognized option '-U'
|
|
|
|
|
Try 'qemu-img --help' for more information
|
|
|
|
|
|
iotests: Specify explicit backing format where sensible
There are many existing qcow2 images that specify a backing file but
no format. This has been the source of CVEs in the past, but has
become more prominent of a problem now that libvirt has switched to
-blockdev. With older -drive, at least the probing was always done by
qemu (so the only risk of a changed format between successive boots of
a guest was if qemu was upgraded and probed differently). But with
newer -blockdev, libvirt must specify a format; if libvirt guesses raw
where the image was formatted, this results in data corruption visible
to the guest; conversely, if libvirt guesses qcow2 where qemu was
using raw, this can result in potential security holes, so modern
libvirt instead refuses to use images without explicit backing format.
The change in libvirt to reject images without explicit backing format
has pointed out that a number of tools have been far too reliant on
probing in the past. It's time to set a better example in our own
iotests of properly setting this parameter.
iotest calls to create, rebase, and convert are all impacted to some
degree. It's a bit annoying that we are inconsistent on command line
- while all of those accept -o backing_file=...,backing_fmt=..., the
shortcuts are different: create and rebase have -b and -F, while
convert has -B but no -F. (amend has no shortcuts, but the previous
patch just deprecated the use of amend to change backing chains).
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200706203954.341758-9-eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-06 22:39:52 +02:00
|
|
|
_qemu_img_wrapper rebase -U TEST_DIR/t.qcow2 -b TEST_DIR/t.qcow2.base -F qcow2
|
2017-05-02 18:35:57 +02:00
|
|
|
qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get "write" lock
|
2018-09-25 07:05:01 +02:00
|
|
|
Is another process using the image [TEST_DIR/t.qcow2]?
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
_qemu_img_wrapper snapshot -l -U TEST_DIR/t.qcow2
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper convert -U TEST_DIR/t.qcow2 TEST_DIR/t.qcow2.convert
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper dd -U if=TEST_DIR/t.qcow2 of=TEST_DIR/t.qcow2.convert bs=512 count=1
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper bench -U -c 1 TEST_DIR/t.qcow2
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper bench -U -w -c 1 TEST_DIR/t.qcow2
|
|
|
|
|
qemu-img: Could not open 'TEST_DIR/t.qcow2': force-share=on can only be used with read-only images
|
2019-11-14 22:34:14 +01:00
|
|
|
{ 'execute': 'quit' }
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
Round done
|
|
|
|
|
|
|
|
|
|
== Creating base image ==
|
|
|
|
|
Formatting 'TEST_DIR/t.IMGFMT.base', fmt=IMGFMT size=33554432
|
|
|
|
|
|
|
|
|
|
== Creating test image ==
|
iotests: Specify explicit backing format where sensible
There are many existing qcow2 images that specify a backing file but
no format. This has been the source of CVEs in the past, but has
become more prominent of a problem now that libvirt has switched to
-blockdev. With older -drive, at least the probing was always done by
qemu (so the only risk of a changed format between successive boots of
a guest was if qemu was upgraded and probed differently). But with
newer -blockdev, libvirt must specify a format; if libvirt guesses raw
where the image was formatted, this results in data corruption visible
to the guest; conversely, if libvirt guesses qcow2 where qemu was
using raw, this can result in potential security holes, so modern
libvirt instead refuses to use images without explicit backing format.
The change in libvirt to reject images without explicit backing format
has pointed out that a number of tools have been far too reliant on
probing in the past. It's time to set a better example in our own
iotests of properly setting this parameter.
iotest calls to create, rebase, and convert are all impacted to some
degree. It's a bit annoying that we are inconsistent on command line
- while all of those accept -o backing_file=...,backing_fmt=..., the
shortcuts are different: create and rebase have -b and -F, while
convert has -B but no -F. (amend has no shortcuts, but the previous
patch just deprecated the use of amend to change backing chains).
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200706203954.341758-9-eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-06 22:39:52 +02:00
|
|
|
Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=33554432 backing_file=TEST_DIR/t.IMGFMT.base backing_fmt=IMGFMT
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
== Launching QEMU, opts: 'read-only=on,force-share=on' ==
|
|
|
|
|
|
|
|
|
|
== Launching another QEMU, opts: '' ==
|
|
|
|
|
|
|
|
|
|
== Launching another QEMU, opts: 'read-only=on' ==
|
|
|
|
|
|
|
|
|
|
== Launching another QEMU, opts: 'read-only=on,force-share=on' ==
|
|
|
|
|
|
|
|
|
|
== Running utility commands ==
|
|
|
|
|
|
|
|
|
|
_qemu_io_wrapper -c read 0 512 TEST_DIR/t.qcow2
|
|
|
|
|
|
|
|
|
|
_qemu_io_wrapper -r -c read 0 512 TEST_DIR/t.qcow2
|
|
|
|
|
|
|
|
|
|
_qemu_io_wrapper -c open TEST_DIR/t.qcow2 -c read 0 512
|
|
|
|
|
|
|
|
|
|
_qemu_io_wrapper -c open -r TEST_DIR/t.qcow2 -c read 0 512
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper info TEST_DIR/t.qcow2
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper check TEST_DIR/t.qcow2
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper compare TEST_DIR/t.qcow2 TEST_DIR/t.qcow2
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper map TEST_DIR/t.qcow2
|
|
|
|
|
|
2020-05-04 15:19:59 +02:00
|
|
|
_qemu_img_wrapper amend -o size=32M TEST_DIR/t.qcow2
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
_qemu_img_wrapper commit TEST_DIR/t.qcow2
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper resize TEST_DIR/t.qcow2 32M
|
|
|
|
|
|
iotests: Specify explicit backing format where sensible
There are many existing qcow2 images that specify a backing file but
no format. This has been the source of CVEs in the past, but has
become more prominent of a problem now that libvirt has switched to
-blockdev. With older -drive, at least the probing was always done by
qemu (so the only risk of a changed format between successive boots of
a guest was if qemu was upgraded and probed differently). But with
newer -blockdev, libvirt must specify a format; if libvirt guesses raw
where the image was formatted, this results in data corruption visible
to the guest; conversely, if libvirt guesses qcow2 where qemu was
using raw, this can result in potential security holes, so modern
libvirt instead refuses to use images without explicit backing format.
The change in libvirt to reject images without explicit backing format
has pointed out that a number of tools have been far too reliant on
probing in the past. It's time to set a better example in our own
iotests of properly setting this parameter.
iotest calls to create, rebase, and convert are all impacted to some
degree. It's a bit annoying that we are inconsistent on command line
- while all of those accept -o backing_file=...,backing_fmt=..., the
shortcuts are different: create and rebase have -b and -F, while
convert has -B but no -F. (amend has no shortcuts, but the previous
patch just deprecated the use of amend to change backing chains).
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200706203954.341758-9-eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-06 22:39:52 +02:00
|
|
|
_qemu_img_wrapper rebase TEST_DIR/t.qcow2 -b TEST_DIR/t.qcow2.base -F qcow2
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
_qemu_img_wrapper snapshot -l TEST_DIR/t.qcow2
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper convert TEST_DIR/t.qcow2 TEST_DIR/t.qcow2.convert
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper dd if=TEST_DIR/t.qcow2 of=TEST_DIR/t.qcow2.convert bs=512 count=1
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper bench -c 1 TEST_DIR/t.qcow2
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper bench -w -c 1 TEST_DIR/t.qcow2
|
|
|
|
|
|
iotests: Specify explicit backing format where sensible
There are many existing qcow2 images that specify a backing file but
no format. This has been the source of CVEs in the past, but has
become more prominent of a problem now that libvirt has switched to
-blockdev. With older -drive, at least the probing was always done by
qemu (so the only risk of a changed format between successive boots of
a guest was if qemu was upgraded and probed differently). But with
newer -blockdev, libvirt must specify a format; if libvirt guesses raw
where the image was formatted, this results in data corruption visible
to the guest; conversely, if libvirt guesses qcow2 where qemu was
using raw, this can result in potential security holes, so modern
libvirt instead refuses to use images without explicit backing format.
The change in libvirt to reject images without explicit backing format
has pointed out that a number of tools have been far too reliant on
probing in the past. It's time to set a better example in our own
iotests of properly setting this parameter.
iotest calls to create, rebase, and convert are all impacted to some
degree. It's a bit annoying that we are inconsistent on command line
- while all of those accept -o backing_file=...,backing_fmt=..., the
shortcuts are different: create and rebase have -b and -F, while
convert has -B but no -F. (amend has no shortcuts, but the previous
patch just deprecated the use of amend to change backing chains).
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200706203954.341758-9-eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-06 22:39:52 +02:00
|
|
|
_qemu_img_wrapper create -f qcow2 TEST_DIR/t.qcow2 -b TEST_DIR/t.qcow2.base -F qcow2
|
2018-05-09 23:53:36 +02:00
|
|
|
file format: IMGFMT
|
iotests: Specify explicit backing format where sensible
There are many existing qcow2 images that specify a backing file but
no format. This has been the source of CVEs in the past, but has
become more prominent of a problem now that libvirt has switched to
-blockdev. With older -drive, at least the probing was always done by
qemu (so the only risk of a changed format between successive boots of
a guest was if qemu was upgraded and probed differently). But with
newer -blockdev, libvirt must specify a format; if libvirt guesses raw
where the image was formatted, this results in data corruption visible
to the guest; conversely, if libvirt guesses qcow2 where qemu was
using raw, this can result in potential security holes, so modern
libvirt instead refuses to use images without explicit backing format.
The change in libvirt to reject images without explicit backing format
has pointed out that a number of tools have been far too reliant on
probing in the past. It's time to set a better example in our own
iotests of properly setting this parameter.
iotest calls to create, rebase, and convert are all impacted to some
degree. It's a bit annoying that we are inconsistent on command line
- while all of those accept -o backing_file=...,backing_fmt=..., the
shortcuts are different: create and rebase have -b and -F, while
convert has -B but no -F. (amend has no shortcuts, but the previous
patch just deprecated the use of amend to change backing chains).
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200706203954.341758-9-eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-06 22:39:52 +02:00
|
|
|
backing file format: IMGFMT
|
2018-05-09 23:53:36 +02:00
|
|
|
|
2017-05-02 18:35:57 +02:00
|
|
|
== Running utility commands -U ==
|
|
|
|
|
|
|
|
|
|
_qemu_io_wrapper -U -c read 0 512 TEST_DIR/t.qcow2
|
2019-04-28 17:54:44 +02:00
|
|
|
qemu-io: can't open device TEST_DIR/t.qcow2: force-share=on can only be used with read-only images
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
_qemu_io_wrapper -U -r -c read 0 512 TEST_DIR/t.qcow2
|
|
|
|
|
|
|
|
|
|
_qemu_io_wrapper -c open -U TEST_DIR/t.qcow2 -c read 0 512
|
2019-04-28 17:54:44 +02:00
|
|
|
qemu-io: can't open device TEST_DIR/t.qcow2: force-share=on can only be used with read-only images
|
qemu-io: Don't die on second open
Most callback commands in qemu-io return 0 to keep the interpreter
loop running, or 1 to quit immediately. However, open_f() just
passed through the return value of openfile(), which has different
semantics of returning 0 if a file was opened, or 1 on any failure.
As a result of mixing the return semantics, we are forcing the
qemu-io interpreter to exit early on any failures, which is rather
annoying when some of the failures are obviously trying to give
the user a hint of how to proceed (if we didn't then kill qemu-io
out from under the user's feet):
$ qemu-io
qemu-io> open foo
qemu-io> open foo
file open already, try 'help close'
$ echo $?
0
In general, we WANT openfile() to report failures, since it is the
function used in the form 'qemu-io -c "$something" no_such_file'
for performing one or more -c options on a single file, and it is
not worth attempting $something if the file itself cannot be opened.
So the solution is to fix open_f() to always return 0 (when we are
in interactive mode, even failure to open should not end the
session), and save the return value of openfile() for command line
use in main().
Note, however, that we do have some qemu-iotests that do 'qemu-io
-c "open file" -c "$something"'; such tests will now proceed to
attempt $something whether or not the open succeeded, the same way
as if the two commands had been attempted in interactive mode. As
such, the expected output for those tests has to be modified. But it
also means that it is now possible to use -c close and have a single
qemu-io command line operate on more than one file even without
using interactive mode. Although the '-c open' action is a subtle
change in behavior, remember that qemu-io is for debugging purposes,
so as long as it serves the needs of qemu-iotests while still being
reasonable for interactive use, it should not be a problem that we
are changing tests to the new behavior.
This has been awkward since at least as far back as commit
e3aff4f, in 2009.
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-06-05 22:38:42 +02:00
|
|
|
no file open, try 'help open'
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
_qemu_io_wrapper -c open -r -U TEST_DIR/t.qcow2 -c read 0 512
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper info -U TEST_DIR/t.qcow2
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper check -U TEST_DIR/t.qcow2
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper compare -U TEST_DIR/t.qcow2 TEST_DIR/t.qcow2
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper map -U TEST_DIR/t.qcow2
|
|
|
|
|
|
2020-05-04 15:19:59 +02:00
|
|
|
_qemu_img_wrapper amend -o size=32M -U TEST_DIR/t.qcow2
|
2017-05-02 18:35:57 +02:00
|
|
|
qemu-img: unrecognized option '-U'
|
|
|
|
|
Try 'qemu-img --help' for more information
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper commit -U TEST_DIR/t.qcow2
|
|
|
|
|
qemu-img: unrecognized option '-U'
|
|
|
|
|
Try 'qemu-img --help' for more information
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper resize -U TEST_DIR/t.qcow2 32M
|
|
|
|
|
qemu-img: unrecognized option '-U'
|
|
|
|
|
Try 'qemu-img --help' for more information
|
|
|
|
|
|
iotests: Specify explicit backing format where sensible
There are many existing qcow2 images that specify a backing file but
no format. This has been the source of CVEs in the past, but has
become more prominent of a problem now that libvirt has switched to
-blockdev. With older -drive, at least the probing was always done by
qemu (so the only risk of a changed format between successive boots of
a guest was if qemu was upgraded and probed differently). But with
newer -blockdev, libvirt must specify a format; if libvirt guesses raw
where the image was formatted, this results in data corruption visible
to the guest; conversely, if libvirt guesses qcow2 where qemu was
using raw, this can result in potential security holes, so modern
libvirt instead refuses to use images without explicit backing format.
The change in libvirt to reject images without explicit backing format
has pointed out that a number of tools have been far too reliant on
probing in the past. It's time to set a better example in our own
iotests of properly setting this parameter.
iotest calls to create, rebase, and convert are all impacted to some
degree. It's a bit annoying that we are inconsistent on command line
- while all of those accept -o backing_file=...,backing_fmt=..., the
shortcuts are different: create and rebase have -b and -F, while
convert has -B but no -F. (amend has no shortcuts, but the previous
patch just deprecated the use of amend to change backing chains).
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200706203954.341758-9-eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-06 22:39:52 +02:00
|
|
|
_qemu_img_wrapper rebase -U TEST_DIR/t.qcow2 -b TEST_DIR/t.qcow2.base -F qcow2
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
_qemu_img_wrapper snapshot -l -U TEST_DIR/t.qcow2
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper convert -U TEST_DIR/t.qcow2 TEST_DIR/t.qcow2.convert
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper dd -U if=TEST_DIR/t.qcow2 of=TEST_DIR/t.qcow2.convert bs=512 count=1
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper bench -U -c 1 TEST_DIR/t.qcow2
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper bench -U -w -c 1 TEST_DIR/t.qcow2
|
|
|
|
|
qemu-img: Could not open 'TEST_DIR/t.qcow2': force-share=on can only be used with read-only images
|
2019-11-14 22:34:14 +01:00
|
|
|
{ 'execute': 'quit' }
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
Round done
|
2018-07-11 09:05:19 +02:00
|
|
|
|
|
|
|
|
== Two devices with the same image (read-only=off - read-only=off) ==
|
|
|
|
|
QEMU_PROG: -drive if=none,file=TEST_DIR/t.qcow2,read-only=off: Failed to get "write" lock
|
2018-09-25 07:05:01 +02:00
|
|
|
Is another process using the image [TEST_DIR/t.qcow2]?
|
2018-07-11 09:05:19 +02:00
|
|
|
|
|
|
|
|
== Two devices with the same image (read-only=off - read-only=on) ==
|
|
|
|
|
QEMU_PROG: -drive if=none,file=TEST_DIR/t.qcow2,read-only=on: Failed to get shared "write" lock
|
2018-09-25 07:05:01 +02:00
|
|
|
Is another process using the image [TEST_DIR/t.qcow2]?
|
2018-07-11 09:05:19 +02:00
|
|
|
|
|
|
|
|
== Two devices with the same image (read-only=off - read-only=on,force-share=on) ==
|
|
|
|
|
|
|
|
|
|
== Two devices with the same image (read-only=on - read-only=off) ==
|
|
|
|
|
QEMU_PROG: -drive if=none,file=TEST_DIR/t.qcow2,read-only=off: Failed to get "write" lock
|
2018-09-25 07:05:01 +02:00
|
|
|
Is another process using the image [TEST_DIR/t.qcow2]?
|
2018-07-11 09:05:19 +02:00
|
|
|
|
|
|
|
|
== Two devices with the same image (read-only=on - read-only=on) ==
|
|
|
|
|
|
|
|
|
|
== Two devices with the same image (read-only=on - read-only=on,force-share=on) ==
|
|
|
|
|
|
|
|
|
|
== Two devices with the same image (read-only=on,force-share=on - read-only=off) ==
|
|
|
|
|
|
|
|
|
|
== Two devices with the same image (read-only=on,force-share=on - read-only=on) ==
|
|
|
|
|
|
|
|
|
|
== Two devices with the same image (read-only=on,force-share=on - read-only=on,force-share=on) ==
|
|
|
|
|
|
2017-05-02 18:35:57 +02:00
|
|
|
== Creating TEST_DIR/t.qcow2.[abc] ==
|
iotests: Specify explicit backing format where sensible
There are many existing qcow2 images that specify a backing file but
no format. This has been the source of CVEs in the past, but has
become more prominent of a problem now that libvirt has switched to
-blockdev. With older -drive, at least the probing was always done by
qemu (so the only risk of a changed format between successive boots of
a guest was if qemu was upgraded and probed differently). But with
newer -blockdev, libvirt must specify a format; if libvirt guesses raw
where the image was formatted, this results in data corruption visible
to the guest; conversely, if libvirt guesses qcow2 where qemu was
using raw, this can result in potential security holes, so modern
libvirt instead refuses to use images without explicit backing format.
The change in libvirt to reject images without explicit backing format
has pointed out that a number of tools have been far too reliant on
probing in the past. It's time to set a better example in our own
iotests of properly setting this parameter.
iotest calls to create, rebase, and convert are all impacted to some
degree. It's a bit annoying that we are inconsistent on command line
- while all of those accept -o backing_file=...,backing_fmt=..., the
shortcuts are different: create and rebase have -b and -F, while
convert has -B but no -F. (amend has no shortcuts, but the previous
patch just deprecated the use of amend to change backing chains).
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200706203954.341758-9-eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-06 22:39:52 +02:00
|
|
|
Formatting 'TEST_DIR/t.IMGFMT.a', fmt=IMGFMT size=33554432 backing_file=TEST_DIR/t.IMGFMT backing_fmt=IMGFMT
|
|
|
|
|
Formatting 'TEST_DIR/t.IMGFMT.b', fmt=IMGFMT size=33554432 backing_file=TEST_DIR/t.IMGFMT backing_fmt=IMGFMT
|
|
|
|
|
Formatting 'TEST_DIR/t.IMGFMT.c', fmt=IMGFMT size=33554432 backing_file=TEST_DIR/t.IMGFMT.b backing_fmt=IMGFMT
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
== Two devices sharing the same file in backing chain ==
|
|
|
|
|
|
|
|
|
|
== Backing image also as an active device ==
|
|
|
|
|
QEMU_PROG: -drive if=none,file=TEST_DIR/t.qcow2: Failed to get "write" lock
|
2018-09-25 07:05:01 +02:00
|
|
|
Is another process using the image [TEST_DIR/t.qcow2]?
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
== Backing image also as an active device (ro) ==
|
|
|
|
|
|
|
|
|
|
== Symbolic link ==
|
|
|
|
|
QEMU_PROG: -drive if=none,file=TEST_DIR/t.qcow2: Failed to get "write" lock
|
2018-09-25 07:05:01 +02:00
|
|
|
Is another process using the image [TEST_DIR/t.qcow2]?
|
2018-03-13 15:20:03 +01:00
|
|
|
|
|
|
|
|
== Active commit to intermediate layer should work when base in use ==
|
2019-11-14 22:34:14 +01:00
|
|
|
{ 'execute': 'qmp_capabilities' }
|
2018-03-13 15:20:03 +01:00
|
|
|
{"return": {}}
|
|
|
|
|
|
|
|
|
|
_qemu_img_wrapper commit -b TEST_DIR/t.qcow2.b TEST_DIR/t.qcow2.c
|
2019-11-14 22:34:14 +01:00
|
|
|
{ 'execute': 'qmp_capabilities' }
|
2017-05-02 18:35:57 +02:00
|
|
|
{"return": {}}
|
|
|
|
|
Adding drive
|
iotests: Fix _send_qemu_cmd with bash 5.1
With bash 5.1, the output of the following script changes:
a=("double space")
a=${a[@]:0:1}
echo "$a"
from "double space" to "double space", i.e. all white space is
preserved as-is. This is probably what we actually want here (judging
from the "...to accommodate pathnames with spaces" comment), but before
5.1, we would have to quote the ${} slice to get the same behavior.
In any case, without quoting, the reference output of many iotests is
different between bash 5.1 and pre-5.1, which is not very good. The
output of 5.1 is what we want, so whatever we do to get pre-5.1 to the
same result, it means we have to fix the reference output of basically
all tests that invoke _send_qemu_cmd (except the ones that only use
single spaces in the commands they invoke).
Instead of quoting the ${} slice (cmd="${$@: 1:...}"), we can also just
not use array slicing and replace the whole thing with a simple "cmd=$1;
shift", which works because all callers quote the whole $cmd argument
anyway.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20201217153803.101231-3-mreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
2020-12-17 16:38:03 +01:00
|
|
|
{ 'execute': 'human-monitor-command',
|
|
|
|
|
'arguments': { 'command-line': 'drive_add 0 if=none,id=d0,file=TEST_DIR/t.IMGFMT' } }
|
2019-03-15 12:46:55 +01:00
|
|
|
{"return": "OKrn"}
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
_qemu_io_wrapper TEST_DIR/t.qcow2 -c write 0 512
|
2019-04-28 17:54:44 +02:00
|
|
|
qemu-io: can't open device TEST_DIR/t.qcow2: Failed to get "write" lock
|
2018-09-25 07:05:01 +02:00
|
|
|
Is another process using the image [TEST_DIR/t.qcow2]?
|
2017-12-25 03:51:07 +01:00
|
|
|
Creating overlay with qemu-img when the guest is running should be allowed
|
|
|
|
|
|
iotests: Specify explicit backing format where sensible
There are many existing qcow2 images that specify a backing file but
no format. This has been the source of CVEs in the past, but has
become more prominent of a problem now that libvirt has switched to
-blockdev. With older -drive, at least the probing was always done by
qemu (so the only risk of a changed format between successive boots of
a guest was if qemu was upgraded and probed differently). But with
newer -blockdev, libvirt must specify a format; if libvirt guesses raw
where the image was formatted, this results in data corruption visible
to the guest; conversely, if libvirt guesses qcow2 where qemu was
using raw, this can result in potential security holes, so modern
libvirt instead refuses to use images without explicit backing format.
The change in libvirt to reject images without explicit backing format
has pointed out that a number of tools have been far too reliant on
probing in the past. It's time to set a better example in our own
iotests of properly setting this parameter.
iotest calls to create, rebase, and convert are all impacted to some
degree. It's a bit annoying that we are inconsistent on command line
- while all of those accept -o backing_file=...,backing_fmt=..., the
shortcuts are different: create and rebase have -b and -F, while
convert has -B but no -F. (amend has no shortcuts, but the previous
patch just deprecated the use of amend to change backing chains).
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200706203954.341758-9-eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-06 22:39:52 +02:00
|
|
|
_qemu_img_wrapper create -f qcow2 -b TEST_DIR/t.qcow2 -F qcow2 TEST_DIR/t.qcow2.overlay
|
2017-12-25 03:51:07 +01:00
|
|
|
== Closing an image should unlock it ==
|
iotests: Fix _send_qemu_cmd with bash 5.1
With bash 5.1, the output of the following script changes:
a=("double space")
a=${a[@]:0:1}
echo "$a"
from "double space" to "double space", i.e. all white space is
preserved as-is. This is probably what we actually want here (judging
from the "...to accommodate pathnames with spaces" comment), but before
5.1, we would have to quote the ${} slice to get the same behavior.
In any case, without quoting, the reference output of many iotests is
different between bash 5.1 and pre-5.1, which is not very good. The
output of 5.1 is what we want, so whatever we do to get pre-5.1 to the
same result, it means we have to fix the reference output of basically
all tests that invoke _send_qemu_cmd (except the ones that only use
single spaces in the commands they invoke).
Instead of quoting the ${} slice (cmd="${$@: 1:...}"), we can also just
not use array slicing and replace the whole thing with a simple "cmd=$1;
shift", which works because all callers quote the whole $cmd argument
anyway.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20201217153803.101231-3-mreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
2020-12-17 16:38:03 +01:00
|
|
|
{ 'execute': 'human-monitor-command',
|
|
|
|
|
'arguments': { 'command-line': 'drive_del d0' } }
|
2019-03-15 12:46:55 +01:00
|
|
|
{"return": ""}
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
_qemu_io_wrapper TEST_DIR/t.qcow2 -c write 0 512
|
|
|
|
|
Adding two and closing one
|
iotests: Fix _send_qemu_cmd with bash 5.1
With bash 5.1, the output of the following script changes:
a=("double space")
a=${a[@]:0:1}
echo "$a"
from "double space" to "double space", i.e. all white space is
preserved as-is. This is probably what we actually want here (judging
from the "...to accommodate pathnames with spaces" comment), but before
5.1, we would have to quote the ${} slice to get the same behavior.
In any case, without quoting, the reference output of many iotests is
different between bash 5.1 and pre-5.1, which is not very good. The
output of 5.1 is what we want, so whatever we do to get pre-5.1 to the
same result, it means we have to fix the reference output of basically
all tests that invoke _send_qemu_cmd (except the ones that only use
single spaces in the commands they invoke).
Instead of quoting the ${} slice (cmd="${$@: 1:...}"), we can also just
not use array slicing and replace the whole thing with a simple "cmd=$1;
shift", which works because all callers quote the whole $cmd argument
anyway.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20201217153803.101231-3-mreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
2020-12-17 16:38:03 +01:00
|
|
|
{ 'execute': 'human-monitor-command',
|
|
|
|
|
'arguments': { 'command-line': 'drive_add 0 if=none,id=d0,file=TEST_DIR/t.IMGFMT,readonly=on' } }
|
2019-03-15 12:46:55 +01:00
|
|
|
{"return": "OKrn"}
|
iotests: Fix _send_qemu_cmd with bash 5.1
With bash 5.1, the output of the following script changes:
a=("double space")
a=${a[@]:0:1}
echo "$a"
from "double space" to "double space", i.e. all white space is
preserved as-is. This is probably what we actually want here (judging
from the "...to accommodate pathnames with spaces" comment), but before
5.1, we would have to quote the ${} slice to get the same behavior.
In any case, without quoting, the reference output of many iotests is
different between bash 5.1 and pre-5.1, which is not very good. The
output of 5.1 is what we want, so whatever we do to get pre-5.1 to the
same result, it means we have to fix the reference output of basically
all tests that invoke _send_qemu_cmd (except the ones that only use
single spaces in the commands they invoke).
Instead of quoting the ${} slice (cmd="${$@: 1:...}"), we can also just
not use array slicing and replace the whole thing with a simple "cmd=$1;
shift", which works because all callers quote the whole $cmd argument
anyway.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20201217153803.101231-3-mreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
2020-12-17 16:38:03 +01:00
|
|
|
{ 'execute': 'human-monitor-command',
|
|
|
|
|
'arguments': { 'command-line': 'drive_add 0 if=none,id=d1,file=TEST_DIR/t.IMGFMT,readonly=on' } }
|
2019-03-15 12:46:55 +01:00
|
|
|
{"return": "OKrn"}
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
_qemu_img_wrapper info TEST_DIR/t.qcow2
|
iotests: Fix _send_qemu_cmd with bash 5.1
With bash 5.1, the output of the following script changes:
a=("double space")
a=${a[@]:0:1}
echo "$a"
from "double space" to "double space", i.e. all white space is
preserved as-is. This is probably what we actually want here (judging
from the "...to accommodate pathnames with spaces" comment), but before
5.1, we would have to quote the ${} slice to get the same behavior.
In any case, without quoting, the reference output of many iotests is
different between bash 5.1 and pre-5.1, which is not very good. The
output of 5.1 is what we want, so whatever we do to get pre-5.1 to the
same result, it means we have to fix the reference output of basically
all tests that invoke _send_qemu_cmd (except the ones that only use
single spaces in the commands they invoke).
Instead of quoting the ${} slice (cmd="${$@: 1:...}"), we can also just
not use array slicing and replace the whole thing with a simple "cmd=$1;
shift", which works because all callers quote the whole $cmd argument
anyway.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20201217153803.101231-3-mreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
2020-12-17 16:38:03 +01:00
|
|
|
{ 'execute': 'human-monitor-command',
|
|
|
|
|
'arguments': { 'command-line': 'drive_del d0' } }
|
2019-03-15 12:46:55 +01:00
|
|
|
{"return": ""}
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
_qemu_io_wrapper TEST_DIR/t.qcow2 -c write 0 512
|
2019-04-28 17:54:44 +02:00
|
|
|
qemu-io: can't open device TEST_DIR/t.qcow2: Failed to get "write" lock
|
2018-09-25 07:05:01 +02:00
|
|
|
Is another process using the image [TEST_DIR/t.qcow2]?
|
2017-05-02 18:35:57 +02:00
|
|
|
Closing the other
|
iotests: Fix _send_qemu_cmd with bash 5.1
With bash 5.1, the output of the following script changes:
a=("double space")
a=${a[@]:0:1}
echo "$a"
from "double space" to "double space", i.e. all white space is
preserved as-is. This is probably what we actually want here (judging
from the "...to accommodate pathnames with spaces" comment), but before
5.1, we would have to quote the ${} slice to get the same behavior.
In any case, without quoting, the reference output of many iotests is
different between bash 5.1 and pre-5.1, which is not very good. The
output of 5.1 is what we want, so whatever we do to get pre-5.1 to the
same result, it means we have to fix the reference output of basically
all tests that invoke _send_qemu_cmd (except the ones that only use
single spaces in the commands they invoke).
Instead of quoting the ${} slice (cmd="${$@: 1:...}"), we can also just
not use array slicing and replace the whole thing with a simple "cmd=$1;
shift", which works because all callers quote the whole $cmd argument
anyway.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20201217153803.101231-3-mreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
2020-12-17 16:38:03 +01:00
|
|
|
{ 'execute': 'human-monitor-command',
|
|
|
|
|
'arguments': { 'command-line': 'drive_del d1' } }
|
2019-03-15 12:46:55 +01:00
|
|
|
{"return": ""}
|
2017-05-02 18:35:57 +02:00
|
|
|
|
|
|
|
|
_qemu_io_wrapper TEST_DIR/t.qcow2 -c write 0 512
|
2018-05-02 22:20:51 +02:00
|
|
|
|
|
|
|
|
== Detecting -U and force-share conflicts ==
|
|
|
|
|
|
|
|
|
|
No conflict:
|
|
|
|
|
image: null-co://
|
|
|
|
|
file format: null-co
|
2019-04-17 19:11:01 +02:00
|
|
|
virtual size: 1 GiB (1073741824 bytes)
|
2020-06-22 13:58:45 +02:00
|
|
|
disk size: 0 B
|
2018-05-02 22:20:51 +02:00
|
|
|
|
|
|
|
|
Conflict:
|
|
|
|
|
qemu-img: --force-share/-U conflicts with image options
|
|
|
|
|
|
|
|
|
|
No conflict:
|
|
|
|
|
|
|
|
|
|
Conflict:
|
2019-04-28 17:54:44 +02:00
|
|
|
qemu-io: -U conflicts with image options
|
2017-05-02 18:35:57 +02:00
|
|
|
*** done
|
