mirrors/qemu
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
83704ceff1
qemu/tests/qemu-iotests/153.out

463 lines
16 KiB
Plaintext
Raw Normal View History

qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03: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 ==
Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=33554432 backing_file=TEST_DIR/t.IMGFMT.base
== Launching QEMU, opts: '' ==
== Launching another QEMU, opts: '' ==
QEMU_PROG: -drive file=TEST_DIR/t.qcow2,if=none,: Failed to get "write" lock
file-posix: Include filename in locking error message Image locking errors happening at device initialization time doesn't say which file cannot be locked, for instance, -device scsi-disk,drive=drive-1: Failed to get shared "write" lock Is another process using the image? could refer to either the overlay image or its backing image. Hoist the error_append_hint to the caller of raw_check_lock_bytes where file name is known, and include it in the error hint. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-09-25 08:05:01 +03:00
Is another process using the image [TEST_DIR/t.qcow2]?
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03: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
file-posix: Include filename in locking error message Image locking errors happening at device initialization time doesn't say which file cannot be locked, for instance, -device scsi-disk,drive=drive-1: Failed to get shared "write" lock Is another process using the image? could refer to either the overlay image or its backing image. Hoist the error_append_hint to the caller of raw_check_lock_bytes where file name is known, and include it in the error hint. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-09-25 08:05:01 +03:00
Is another process using the image [TEST_DIR/t.qcow2]?
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03: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
tests/qemu-iotests: Fix output of qemu-io related tests One of the recent commits changed the way qemu-io prints out its errors and warnings - they are now prefixed with the program name. We've got to adapt the iotests accordingly to prevent that they are failing. Fixes: 99e98d7c9fc1a1639fad ("qemu-io: Use error_[gs]et_progname()") Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2019-04-28 18:54:44 +03:00
qemu-io: can't open device TEST_DIR/t.qcow2: Failed to get "write" lock
file-posix: Include filename in locking error message Image locking errors happening at device initialization time doesn't say which file cannot be locked, for instance, -device scsi-disk,drive=drive-1: Failed to get shared "write" lock Is another process using the image? could refer to either the overlay image or its backing image. Hoist the error_append_hint to the caller of raw_check_lock_bytes where file name is known, and include it in the error hint. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-09-25 08:05:01 +03:00
Is another process using the image [TEST_DIR/t.qcow2]?
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03:00
_qemu_io_wrapper -r -c read 0 512 TEST_DIR/t.qcow2
tests/qemu-iotests: Fix output of qemu-io related tests One of the recent commits changed the way qemu-io prints out its errors and warnings - they are now prefixed with the program name. We've got to adapt the iotests accordingly to prevent that they are failing. Fixes: 99e98d7c9fc1a1639fad ("qemu-io: Use error_[gs]et_progname()") Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2019-04-28 18:54:44 +03:00
qemu-io: can't open device TEST_DIR/t.qcow2: Failed to get shared "write" lock
file-posix: Include filename in locking error message Image locking errors happening at device initialization time doesn't say which file cannot be locked, for instance, -device scsi-disk,drive=drive-1: Failed to get shared "write" lock Is another process using the image? could refer to either the overlay image or its backing image. Hoist the error_append_hint to the caller of raw_check_lock_bytes where file name is known, and include it in the error hint. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-09-25 08:05:01 +03:00
Is another process using the image [TEST_DIR/t.qcow2]?
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03:00
_qemu_io_wrapper -c open TEST_DIR/t.qcow2 -c read 0 512
tests/qemu-iotests: Fix output of qemu-io related tests One of the recent commits changed the way qemu-io prints out its errors and warnings - they are now prefixed with the program name. We've got to adapt the iotests accordingly to prevent that they are failing. Fixes: 99e98d7c9fc1a1639fad ("qemu-io: Use error_[gs]et_progname()") Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2019-04-28 18:54:44 +03:00
qemu-io: can't open device TEST_DIR/t.qcow2: Failed to get "write" lock
file-posix: Include filename in locking error message Image locking errors happening at device initialization time doesn't say which file cannot be locked, for instance, -device scsi-disk,drive=drive-1: Failed to get shared "write" lock Is another process using the image? could refer to either the overlay image or its backing image. Hoist the error_append_hint to the caller of raw_check_lock_bytes where file name is known, and include it in the error hint. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-09-25 08:05:01 +03: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 23:38:42 +03:00
no file open, try 'help open'
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03:00
_qemu_io_wrapper -c open -r TEST_DIR/t.qcow2 -c read 0 512
tests/qemu-iotests: Fix output of qemu-io related tests One of the recent commits changed the way qemu-io prints out its errors and warnings - they are now prefixed with the program name. We've got to adapt the iotests accordingly to prevent that they are failing. Fixes: 99e98d7c9fc1a1639fad ("qemu-io: Use error_[gs]et_progname()") Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2019-04-28 18:54:44 +03:00
qemu-io: can't open device TEST_DIR/t.qcow2: Failed to get shared "write" lock
file-posix: Include filename in locking error message Image locking errors happening at device initialization time doesn't say which file cannot be locked, for instance, -device scsi-disk,drive=drive-1: Failed to get shared "write" lock Is another process using the image? could refer to either the overlay image or its backing image. Hoist the error_append_hint to the caller of raw_check_lock_bytes where file name is known, and include it in the error hint. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-09-25 08:05:01 +03: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 23:38:42 +03:00
no file open, try 'help open'
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03:00
_qemu_img_wrapper info TEST_DIR/t.qcow2
qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get shared "write" lock
file-posix: Include filename in locking error message Image locking errors happening at device initialization time doesn't say which file cannot be locked, for instance, -device scsi-disk,drive=drive-1: Failed to get shared "write" lock Is another process using the image? could refer to either the overlay image or its backing image. Hoist the error_append_hint to the caller of raw_check_lock_bytes where file name is known, and include it in the error hint. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-09-25 08:05:01 +03:00
Is another process using the image [TEST_DIR/t.qcow2]?
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03:00
_qemu_img_wrapper check TEST_DIR/t.qcow2
qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get shared "write" lock
file-posix: Include filename in locking error message Image locking errors happening at device initialization time doesn't say which file cannot be locked, for instance, -device scsi-disk,drive=drive-1: Failed to get shared "write" lock Is another process using the image? could refer to either the overlay image or its backing image. Hoist the error_append_hint to the caller of raw_check_lock_bytes where file name is known, and include it in the error hint. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-09-25 08:05:01 +03:00
Is another process using the image [TEST_DIR/t.qcow2]?
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03: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
file-posix: Include filename in locking error message Image locking errors happening at device initialization time doesn't say which file cannot be locked, for instance, -device scsi-disk,drive=drive-1: Failed to get shared "write" lock Is another process using the image? could refer to either the overlay image or its backing image. Hoist the error_append_hint to the caller of raw_check_lock_bytes where file name is known, and include it in the error hint. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-09-25 08:05:01 +03:00
Is another process using the image [TEST_DIR/t.qcow2]?
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03:00
_qemu_img_wrapper map TEST_DIR/t.qcow2
qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get shared "write" lock
file-posix: Include filename in locking error message Image locking errors happening at device initialization time doesn't say which file cannot be locked, for instance, -device scsi-disk,drive=drive-1: Failed to get shared "write" lock Is another process using the image? could refer to either the overlay image or its backing image. Hoist the error_append_hint to the caller of raw_check_lock_bytes where file name is known, and include it in the error hint. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-09-25 08:05:01 +03:00
Is another process using the image [TEST_DIR/t.qcow2]?
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03:00
_qemu_img_wrapper amend -o TEST_DIR/t.qcow2
qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get "write" lock
file-posix: Include filename in locking error message Image locking errors happening at device initialization time doesn't say which file cannot be locked, for instance, -device scsi-disk,drive=drive-1: Failed to get shared "write" lock Is another process using the image? could refer to either the overlay image or its backing image. Hoist the error_append_hint to the caller of raw_check_lock_bytes where file name is known, and include it in the error hint. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-09-25 08:05:01 +03:00
Is another process using the image [TEST_DIR/t.qcow2]?
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03:00
_qemu_img_wrapper commit TEST_DIR/t.qcow2
qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get "write" lock
file-posix: Include filename in locking error message Image locking errors happening at device initialization time doesn't say which file cannot be locked, for instance, -device scsi-disk,drive=drive-1: Failed to get shared "write" lock Is another process using the image? could refer to either the overlay image or its backing image. Hoist the error_append_hint to the caller of raw_check_lock_bytes where file name is known, and include it in the error hint. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-09-25 08:05:01 +03:00
Is another process using the image [TEST_DIR/t.qcow2]?
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03:00
_qemu_img_wrapper resize TEST_DIR/t.qcow2 32M
qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get "write" lock
file-posix: Include filename in locking error message Image locking errors happening at device initialization time doesn't say which file cannot be locked, for instance, -device scsi-disk,drive=drive-1: Failed to get shared "write" lock Is another process using the image? could refer to either the overlay image or its backing image. Hoist the error_append_hint to the caller of raw_check_lock_bytes where file name is known, and include it in the error hint. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-09-25 08:05:01 +03:00
Is another process using the image [TEST_DIR/t.qcow2]?
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03:00
_qemu_img_wrapper rebase TEST_DIR/t.qcow2 -b TEST_DIR/t.qcow2.base
qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get "write" lock
file-posix: Include filename in locking error message Image locking errors happening at device initialization time doesn't say which file cannot be locked, for instance, -device scsi-disk,drive=drive-1: Failed to get shared "write" lock Is another process using the image? could refer to either the overlay image or its backing image. Hoist the error_append_hint to the caller of raw_check_lock_bytes where file name is known, and include it in the error hint. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-09-25 08:05:01 +03:00
Is another process using the image [TEST_DIR/t.qcow2]?
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03: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
file-posix: Include filename in locking error message Image locking errors happening at device initialization time doesn't say which file cannot be locked, for instance, -device scsi-disk,drive=drive-1: Failed to get shared "write" lock Is another process using the image? could refer to either the overlay image or its backing image. Hoist the error_append_hint to the caller of raw_check_lock_bytes where file name is known, and include it in the error hint. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-09-25 08:05:01 +03:00
Is another process using the image [TEST_DIR/t.qcow2]?
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03: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
file-posix: Include filename in locking error message Image locking errors happening at device initialization time doesn't say which file cannot be locked, for instance, -device scsi-disk,drive=drive-1: Failed to get shared "write" lock Is another process using the image? could refer to either the overlay image or its backing image. Hoist the error_append_hint to the caller of raw_check_lock_bytes where file name is known, and include it in the error hint. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-09-25 08:05:01 +03:00
Is another process using the image [TEST_DIR/t.qcow2]?
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03: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
file-posix: Include filename in locking error message Image locking errors happening at device initialization time doesn't say which file cannot be locked, for instance, -device scsi-disk,drive=drive-1: Failed to get shared "write" lock Is another process using the image? could refer to either the overlay image or its backing image. Hoist the error_append_hint to the caller of raw_check_lock_bytes where file name is known, and include it in the error hint. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-09-25 08:05:01 +03:00
Is another process using the image [TEST_DIR/t.qcow2]?
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03: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
file-posix: Include filename in locking error message Image locking errors happening at device initialization time doesn't say which file cannot be locked, for instance, -device scsi-disk,drive=drive-1: Failed to get shared "write" lock Is another process using the image? could refer to either the overlay image or its backing image. Hoist the error_append_hint to the caller of raw_check_lock_bytes where file name is known, and include it in the error hint. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-09-25 08:05:01 +03:00
Is another process using the image [TEST_DIR/t.qcow2]?
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03: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
file-posix: Include filename in locking error message Image locking errors happening at device initialization time doesn't say which file cannot be locked, for instance, -device scsi-disk,drive=drive-1: Failed to get shared "write" lock Is another process using the image? could refer to either the overlay image or its backing image. Hoist the error_append_hint to the caller of raw_check_lock_bytes where file name is known, and include it in the error hint. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-09-25 08:05:01 +03:00
Is another process using the image [TEST_DIR/t.qcow2]?
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03:00
iotests: Add creation test to 153 This patch adds a test case to 153 which tries to overwrite an image (using qemu-img create) while it is in use. Without the original user explicitly sharing the necessary permissions (writing and truncation), this should not be allowed. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Message-id: 20180509215336.31304-4-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2018-05-10 00:53:36 +03:00
_qemu_img_wrapper create -f qcow2 TEST_DIR/t.qcow2 -b TEST_DIR/t.qcow2.base
qemu-img: TEST_DIR/t.qcow2: Failed to get "write" lock
file-posix: Include filename in locking error message Image locking errors happening at device initialization time doesn't say which file cannot be locked, for instance, -device scsi-disk,drive=drive-1: Failed to get shared "write" lock Is another process using the image? could refer to either the overlay image or its backing image. Hoist the error_append_hint to the caller of raw_check_lock_bytes where file name is known, and include it in the error hint. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-09-25 08:05:01 +03:00
Is another process using the image [TEST_DIR/t.qcow2]?
iotests: Add creation test to 153 This patch adds a test case to 153 which tries to overwrite an image (using qemu-img create) while it is in use. Without the original user explicitly sharing the necessary permissions (writing and truncation), this should not be allowed. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Message-id: 20180509215336.31304-4-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2018-05-10 00:53:36 +03:00
file format: IMGFMT
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03:00
== Running utility commands -U ==
_qemu_io_wrapper -U -c read 0 512 TEST_DIR/t.qcow2
tests/qemu-iotests: Fix output of qemu-io related tests One of the recent commits changed the way qemu-io prints out its errors and warnings - they are now prefixed with the program name. We've got to adapt the iotests accordingly to prevent that they are failing. Fixes: 99e98d7c9fc1a1639fad ("qemu-io: Use error_[gs]et_progname()") Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2019-04-28 18:54:44 +03:00
qemu-io: can't open device TEST_DIR/t.qcow2: force-share=on can only be used with read-only images
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03: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
tests/qemu-iotests: Fix output of qemu-io related tests One of the recent commits changed the way qemu-io prints out its errors and warnings - they are now prefixed with the program name. We've got to adapt the iotests accordingly to prevent that they are failing. Fixes: 99e98d7c9fc1a1639fad ("qemu-io: Use error_[gs]et_progname()") Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2019-04-28 18:54:44 +03: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 23:38:42 +03:00
no file open, try 'help open'
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03: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
_qemu_img_wrapper amend -o -U TEST_DIR/t.qcow2
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
_qemu_img_wrapper rebase -U TEST_DIR/t.qcow2 -b TEST_DIR/t.qcow2.base
qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get "write" lock
file-posix: Include filename in locking error message Image locking errors happening at device initialization time doesn't say which file cannot be locked, for instance, -device scsi-disk,drive=drive-1: Failed to get shared "write" lock Is another process using the image? could refer to either the overlay image or its backing image. Hoist the error_append_hint to the caller of raw_check_lock_bytes where file name is known, and include it in the error hint. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-09-25 08:05:01 +03:00
Is another process using the image [TEST_DIR/t.qcow2]?
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03: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
Round done
== Creating base image ==
Formatting 'TEST_DIR/t.IMGFMT.base', fmt=IMGFMT size=33554432
== Creating test image ==
Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=33554432 backing_file=TEST_DIR/t.IMGFMT.base
== 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
file-posix: Include filename in locking error message Image locking errors happening at device initialization time doesn't say which file cannot be locked, for instance, -device scsi-disk,drive=drive-1: Failed to get shared "write" lock Is another process using the image? could refer to either the overlay image or its backing image. Hoist the error_append_hint to the caller of raw_check_lock_bytes where file name is known, and include it in the error hint. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-09-25 08:05:01 +03:00
Is another process using the image [TEST_DIR/t.qcow2]?
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03: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
tests/qemu-iotests: Fix output of qemu-io related tests One of the recent commits changed the way qemu-io prints out its errors and warnings - they are now prefixed with the program name. We've got to adapt the iotests accordingly to prevent that they are failing. Fixes: 99e98d7c9fc1a1639fad ("qemu-io: Use error_[gs]et_progname()") Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2019-04-28 18:54:44 +03:00
qemu-io: can't open device TEST_DIR/t.qcow2: Failed to get "write" lock
file-posix: Include filename in locking error message Image locking errors happening at device initialization time doesn't say which file cannot be locked, for instance, -device scsi-disk,drive=drive-1: Failed to get shared "write" lock Is another process using the image? could refer to either the overlay image or its backing image. Hoist the error_append_hint to the caller of raw_check_lock_bytes where file name is known, and include it in the error hint. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-09-25 08:05:01 +03:00
Is another process using the image [TEST_DIR/t.qcow2]?
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03: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
tests/qemu-iotests: Fix output of qemu-io related tests One of the recent commits changed the way qemu-io prints out its errors and warnings - they are now prefixed with the program name. We've got to adapt the iotests accordingly to prevent that they are failing. Fixes: 99e98d7c9fc1a1639fad ("qemu-io: Use error_[gs]et_progname()") Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2019-04-28 18:54:44 +03:00
qemu-io: can't open device TEST_DIR/t.qcow2: Failed to get "write" lock
file-posix: Include filename in locking error message Image locking errors happening at device initialization time doesn't say which file cannot be locked, for instance, -device scsi-disk,drive=drive-1: Failed to get shared "write" lock Is another process using the image? could refer to either the overlay image or its backing image. Hoist the error_append_hint to the caller of raw_check_lock_bytes where file name is known, and include it in the error hint. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-09-25 08:05:01 +03: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 23:38:42 +03:00
no file open, try 'help open'
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03: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
_qemu_img_wrapper amend -o TEST_DIR/t.qcow2
qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get "write" lock
file-posix: Include filename in locking error message Image locking errors happening at device initialization time doesn't say which file cannot be locked, for instance, -device scsi-disk,drive=drive-1: Failed to get shared "write" lock Is another process using the image? could refer to either the overlay image or its backing image. Hoist the error_append_hint to the caller of raw_check_lock_bytes where file name is known, and include it in the error hint. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-09-25 08:05:01 +03:00
Is another process using the image [TEST_DIR/t.qcow2]?
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03:00
_qemu_img_wrapper commit TEST_DIR/t.qcow2
qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get "write" lock
file-posix: Include filename in locking error message Image locking errors happening at device initialization time doesn't say which file cannot be locked, for instance, -device scsi-disk,drive=drive-1: Failed to get shared "write" lock Is another process using the image? could refer to either the overlay image or its backing image. Hoist the error_append_hint to the caller of raw_check_lock_bytes where file name is known, and include it in the error hint. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-09-25 08:05:01 +03:00
Is another process using the image [TEST_DIR/t.qcow2]?
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03:00
_qemu_img_wrapper resize TEST_DIR/t.qcow2 32M
qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get "write" lock
file-posix: Include filename in locking error message Image locking errors happening at device initialization time doesn't say which file cannot be locked, for instance, -device scsi-disk,drive=drive-1: Failed to get shared "write" lock Is another process using the image? could refer to either the overlay image or its backing image. Hoist the error_append_hint to the caller of raw_check_lock_bytes where file name is known, and include it in the error hint. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-09-25 08:05:01 +03:00
Is another process using the image [TEST_DIR/t.qcow2]?
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03:00
_qemu_img_wrapper rebase TEST_DIR/t.qcow2 -b TEST_DIR/t.qcow2.base
qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get "write" lock
file-posix: Include filename in locking error message Image locking errors happening at device initialization time doesn't say which file cannot be locked, for instance, -device scsi-disk,drive=drive-1: Failed to get shared "write" lock Is another process using the image? could refer to either the overlay image or its backing image. Hoist the error_append_hint to the caller of raw_check_lock_bytes where file name is known, and include it in the error hint. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-09-25 08:05:01 +03:00
Is another process using the image [TEST_DIR/t.qcow2]?
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03: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
file-posix: Include filename in locking error message Image locking errors happening at device initialization time doesn't say which file cannot be locked, for instance, -device scsi-disk,drive=drive-1: Failed to get shared "write" lock Is another process using the image? could refer to either the overlay image or its backing image. Hoist the error_append_hint to the caller of raw_check_lock_bytes where file name is known, and include it in the error hint. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-09-25 08:05:01 +03:00
Is another process using the image [TEST_DIR/t.qcow2]?
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03:00
iotests: Add creation test to 153 This patch adds a test case to 153 which tries to overwrite an image (using qemu-img create) while it is in use. Without the original user explicitly sharing the necessary permissions (writing and truncation), this should not be allowed. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Message-id: 20180509215336.31304-4-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2018-05-10 00:53:36 +03:00
_qemu_img_wrapper create -f qcow2 TEST_DIR/t.qcow2 -b TEST_DIR/t.qcow2.base
qemu-img: TEST_DIR/t.qcow2: Failed to get "write" lock
file-posix: Include filename in locking error message Image locking errors happening at device initialization time doesn't say which file cannot be locked, for instance, -device scsi-disk,drive=drive-1: Failed to get shared "write" lock Is another process using the image? could refer to either the overlay image or its backing image. Hoist the error_append_hint to the caller of raw_check_lock_bytes where file name is known, and include it in the error hint. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-09-25 08:05:01 +03:00
Is another process using the image [TEST_DIR/t.qcow2]?
iotests: Add creation test to 153 This patch adds a test case to 153 which tries to overwrite an image (using qemu-img create) while it is in use. Without the original user explicitly sharing the necessary permissions (writing and truncation), this should not be allowed. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Message-id: 20180509215336.31304-4-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2018-05-10 00:53:36 +03:00
file format: IMGFMT
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03:00
== Running utility commands -U ==
_qemu_io_wrapper -U -c read 0 512 TEST_DIR/t.qcow2
tests/qemu-iotests: Fix output of qemu-io related tests One of the recent commits changed the way qemu-io prints out its errors and warnings - they are now prefixed with the program name. We've got to adapt the iotests accordingly to prevent that they are failing. Fixes: 99e98d7c9fc1a1639fad ("qemu-io: Use error_[gs]et_progname()") Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2019-04-28 18:54:44 +03:00
qemu-io: can't open device TEST_DIR/t.qcow2: force-share=on can only be used with read-only images
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03: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
tests/qemu-iotests: Fix output of qemu-io related tests One of the recent commits changed the way qemu-io prints out its errors and warnings - they are now prefixed with the program name. We've got to adapt the iotests accordingly to prevent that they are failing. Fixes: 99e98d7c9fc1a1639fad ("qemu-io: Use error_[gs]et_progname()") Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2019-04-28 18:54:44 +03: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 23:38:42 +03:00
no file open, try 'help open'
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03: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
_qemu_img_wrapper amend -o -U TEST_DIR/t.qcow2
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
_qemu_img_wrapper rebase -U TEST_DIR/t.qcow2 -b TEST_DIR/t.qcow2.base
qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get "write" lock
file-posix: Include filename in locking error message Image locking errors happening at device initialization time doesn't say which file cannot be locked, for instance, -device scsi-disk,drive=drive-1: Failed to get shared "write" lock Is another process using the image? could refer to either the overlay image or its backing image. Hoist the error_append_hint to the caller of raw_check_lock_bytes where file name is known, and include it in the error hint. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-09-25 08:05:01 +03:00
Is another process using the image [TEST_DIR/t.qcow2]?
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03: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
Round done
== Creating base image ==
Formatting 'TEST_DIR/t.IMGFMT.base', fmt=IMGFMT size=33554432
== Creating test image ==
Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=33554432 backing_file=TEST_DIR/t.IMGFMT.base
== 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
_qemu_img_wrapper amend -o TEST_DIR/t.qcow2
_qemu_img_wrapper commit TEST_DIR/t.qcow2
_qemu_img_wrapper resize TEST_DIR/t.qcow2 32M
_qemu_img_wrapper rebase TEST_DIR/t.qcow2 -b TEST_DIR/t.qcow2.base
_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: Add creation test to 153 This patch adds a test case to 153 which tries to overwrite an image (using qemu-img create) while it is in use. Without the original user explicitly sharing the necessary permissions (writing and truncation), this should not be allowed. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Message-id: 20180509215336.31304-4-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2018-05-10 00:53:36 +03:00
_qemu_img_wrapper create -f qcow2 TEST_DIR/t.qcow2 -b TEST_DIR/t.qcow2.base
file format: IMGFMT
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03:00
== Running utility commands -U ==
_qemu_io_wrapper -U -c read 0 512 TEST_DIR/t.qcow2
tests/qemu-iotests: Fix output of qemu-io related tests One of the recent commits changed the way qemu-io prints out its errors and warnings - they are now prefixed with the program name. We've got to adapt the iotests accordingly to prevent that they are failing. Fixes: 99e98d7c9fc1a1639fad ("qemu-io: Use error_[gs]et_progname()") Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2019-04-28 18:54:44 +03:00
qemu-io: can't open device TEST_DIR/t.qcow2: force-share=on can only be used with read-only images
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03: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
tests/qemu-iotests: Fix output of qemu-io related tests One of the recent commits changed the way qemu-io prints out its errors and warnings - they are now prefixed with the program name. We've got to adapt the iotests accordingly to prevent that they are failing. Fixes: 99e98d7c9fc1a1639fad ("qemu-io: Use error_[gs]et_progname()") Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2019-04-28 18:54:44 +03: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 23:38:42 +03:00
no file open, try 'help open'
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03: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
_qemu_img_wrapper amend -o -U TEST_DIR/t.qcow2
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
_qemu_img_wrapper rebase -U TEST_DIR/t.qcow2 -b TEST_DIR/t.qcow2.base
_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
Round done
iotests: 153: Fix dead code This step was left behind my mistake. As suggested by the echoed text, the intention was to test two devices with the same image, with different options. The behavior should be the same as two QEMU processes. Complete it. Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-07-11 10:05:19 +03: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
file-posix: Include filename in locking error message Image locking errors happening at device initialization time doesn't say which file cannot be locked, for instance, -device scsi-disk,drive=drive-1: Failed to get shared "write" lock Is another process using the image? could refer to either the overlay image or its backing image. Hoist the error_append_hint to the caller of raw_check_lock_bytes where file name is known, and include it in the error hint. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-09-25 08:05:01 +03:00
Is another process using the image [TEST_DIR/t.qcow2]?
iotests: 153: Fix dead code This step was left behind my mistake. As suggested by the echoed text, the intention was to test two devices with the same image, with different options. The behavior should be the same as two QEMU processes. Complete it. Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-07-11 10:05:19 +03: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
file-posix: Include filename in locking error message Image locking errors happening at device initialization time doesn't say which file cannot be locked, for instance, -device scsi-disk,drive=drive-1: Failed to get shared "write" lock Is another process using the image? could refer to either the overlay image or its backing image. Hoist the error_append_hint to the caller of raw_check_lock_bytes where file name is known, and include it in the error hint. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-09-25 08:05:01 +03:00
Is another process using the image [TEST_DIR/t.qcow2]?
iotests: 153: Fix dead code This step was left behind my mistake. As suggested by the echoed text, the intention was to test two devices with the same image, with different options. The behavior should be the same as two QEMU processes. Complete it. Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-07-11 10:05:19 +03: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
file-posix: Include filename in locking error message Image locking errors happening at device initialization time doesn't say which file cannot be locked, for instance, -device scsi-disk,drive=drive-1: Failed to get shared "write" lock Is another process using the image? could refer to either the overlay image or its backing image. Hoist the error_append_hint to the caller of raw_check_lock_bytes where file name is known, and include it in the error hint. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-09-25 08:05:01 +03:00
Is another process using the image [TEST_DIR/t.qcow2]?
iotests: 153: Fix dead code This step was left behind my mistake. As suggested by the echoed text, the intention was to test two devices with the same image, with different options. The behavior should be the same as two QEMU processes. Complete it. Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-07-11 10:05:19 +03: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) ==
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03:00
== Creating TEST_DIR/t.qcow2.[abc] ==
Formatting 'TEST_DIR/t.IMGFMT.a', fmt=IMGFMT size=33554432 backing_file=TEST_DIR/t.IMGFMT
Formatting 'TEST_DIR/t.IMGFMT.b', fmt=IMGFMT size=33554432 backing_file=TEST_DIR/t.IMGFMT
Formatting 'TEST_DIR/t.IMGFMT.c', fmt=IMGFMT size=33554432 backing_file=TEST_DIR/t.IMGFMT.b
== 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
file-posix: Include filename in locking error message Image locking errors happening at device initialization time doesn't say which file cannot be locked, for instance, -device scsi-disk,drive=drive-1: Failed to get shared "write" lock Is another process using the image? could refer to either the overlay image or its backing image. Hoist the error_append_hint to the caller of raw_check_lock_bytes where file name is known, and include it in the error hint. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-09-25 08:05:01 +03:00
Is another process using the image [TEST_DIR/t.qcow2]?
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03: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
file-posix: Include filename in locking error message Image locking errors happening at device initialization time doesn't say which file cannot be locked, for instance, -device scsi-disk,drive=drive-1: Failed to get shared "write" lock Is another process using the image? could refer to either the overlay image or its backing image. Hoist the error_append_hint to the caller of raw_check_lock_bytes where file name is known, and include it in the error hint. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-09-25 08:05:01 +03:00
Is another process using the image [TEST_DIR/t.qcow2]?
iotests: Add regression test for commit base locking Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-03-13 17:20:03 +03:00
== Active commit to intermediate layer should work when base in use ==
{"return": {}}
_qemu_img_wrapper commit -b TEST_DIR/t.qcow2.b TEST_DIR/t.qcow2.c
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03:00
{"return": {}}
Adding drive
iotests: 153: Wait for an answer to QMP commands There are various actions in this test that must be executed sequentially, as the result of it depends on the state triggered by the previous one. If the last argument of _send_qemu_cmd() is an empty string, it just sends the QMP commands without waiting for an answer. While unlikely, it may happen that the next action in the test gets invoked before QEMU processes the QMP request. This issue seems to be easier to reproduce on servers with limited resources or highly loaded. With this change, we wait for an answer on all _send_qemu_cmd() calls. Signed-off-by: Sergio Lopez <slp@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2019-03-15 14:46:55 +03:00
{"return": "OKrn"}
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03:00
_qemu_io_wrapper TEST_DIR/t.qcow2 -c write 0 512
tests/qemu-iotests: Fix output of qemu-io related tests One of the recent commits changed the way qemu-io prints out its errors and warnings - they are now prefixed with the program name. We've got to adapt the iotests accordingly to prevent that they are failing. Fixes: 99e98d7c9fc1a1639fad ("qemu-io: Use error_[gs]et_progname()") Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2019-04-28 18:54:44 +03:00
qemu-io: can't open device TEST_DIR/t.qcow2: Failed to get "write" lock
file-posix: Include filename in locking error message Image locking errors happening at device initialization time doesn't say which file cannot be locked, for instance, -device scsi-disk,drive=drive-1: Failed to get shared "write" lock Is another process using the image? could refer to either the overlay image or its backing image. Hoist the error_append_hint to the caller of raw_check_lock_bytes where file name is known, and include it in the error hint. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-09-25 08:05:01 +03:00
Is another process using the image [TEST_DIR/t.qcow2]?
iotests: Test creating overlay when guest running Signed-off-by: Fam Zheng <famz@redhat.com> Message-id: 20171225025107.23985-1-famz@redhat.com Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-12-25 05:51:07 +03:00
Creating overlay with qemu-img when the guest is running should be allowed
_qemu_img_wrapper create -f qcow2 -b TEST_DIR/t.qcow2 TEST_DIR/t.qcow2.overlay
== Closing an image should unlock it ==
iotests: 153: Wait for an answer to QMP commands There are various actions in this test that must be executed sequentially, as the result of it depends on the state triggered by the previous one. If the last argument of _send_qemu_cmd() is an empty string, it just sends the QMP commands without waiting for an answer. While unlikely, it may happen that the next action in the test gets invoked before QEMU processes the QMP request. This issue seems to be easier to reproduce on servers with limited resources or highly loaded. With this change, we wait for an answer on all _send_qemu_cmd() calls. Signed-off-by: Sergio Lopez <slp@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2019-03-15 14:46:55 +03:00
{"return": ""}
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03:00
_qemu_io_wrapper TEST_DIR/t.qcow2 -c write 0 512
Adding two and closing one
iotests: 153: Wait for an answer to QMP commands There are various actions in this test that must be executed sequentially, as the result of it depends on the state triggered by the previous one. If the last argument of _send_qemu_cmd() is an empty string, it just sends the QMP commands without waiting for an answer. While unlikely, it may happen that the next action in the test gets invoked before QEMU processes the QMP request. This issue seems to be easier to reproduce on servers with limited resources or highly loaded. With this change, we wait for an answer on all _send_qemu_cmd() calls. Signed-off-by: Sergio Lopez <slp@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2019-03-15 14:46:55 +03:00
{"return": "OKrn"}
{"return": "OKrn"}
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03:00
_qemu_img_wrapper info TEST_DIR/t.qcow2
iotests: 153: Wait for an answer to QMP commands There are various actions in this test that must be executed sequentially, as the result of it depends on the state triggered by the previous one. If the last argument of _send_qemu_cmd() is an empty string, it just sends the QMP commands without waiting for an answer. While unlikely, it may happen that the next action in the test gets invoked before QEMU processes the QMP request. This issue seems to be easier to reproduce on servers with limited resources or highly loaded. With this change, we wait for an answer on all _send_qemu_cmd() calls. Signed-off-by: Sergio Lopez <slp@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2019-03-15 14:46:55 +03:00
{"return": ""}
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03:00
_qemu_io_wrapper TEST_DIR/t.qcow2 -c write 0 512
tests/qemu-iotests: Fix output of qemu-io related tests One of the recent commits changed the way qemu-io prints out its errors and warnings - they are now prefixed with the program name. We've got to adapt the iotests accordingly to prevent that they are failing. Fixes: 99e98d7c9fc1a1639fad ("qemu-io: Use error_[gs]et_progname()") Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2019-04-28 18:54:44 +03:00
qemu-io: can't open device TEST_DIR/t.qcow2: Failed to get "write" lock
file-posix: Include filename in locking error message Image locking errors happening at device initialization time doesn't say which file cannot be locked, for instance, -device scsi-disk,drive=drive-1: Failed to get shared "write" lock Is another process using the image? could refer to either the overlay image or its backing image. Hoist the error_append_hint to the caller of raw_check_lock_bytes where file name is known, and include it in the error hint. Signed-off-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-09-25 08:05:01 +03:00
Is another process using the image [TEST_DIR/t.qcow2]?
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03:00
Closing the other
iotests: 153: Wait for an answer to QMP commands There are various actions in this test that must be executed sequentially, as the result of it depends on the state triggered by the previous one. If the last argument of _send_qemu_cmd() is an empty string, it just sends the QMP commands without waiting for an answer. While unlikely, it may happen that the next action in the test gets invoked before QEMU processes the QMP request. This issue seems to be easier to reproduce on servers with limited resources or highly loaded. With this change, we wait for an answer on all _send_qemu_cmd() calls. Signed-off-by: Sergio Lopez <slp@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2019-03-15 14:46:55 +03:00
{"return": ""}
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03:00
_qemu_io_wrapper TEST_DIR/t.qcow2 -c write 0 512
iotests: Add test for -U/force-share conflicts Signed-off-by: Max Reitz <mreitz@redhat.com> Message-id: 20180502202051.15493-4-mreitz@redhat.com Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2018-05-02 23:20:51 +03:00
== Detecting -U and force-share conflicts ==
No conflict:
image: null-co://
file format: null-co
qemu-img: Saner printing of large file sizes Disk sizes close to INT64_MAX cause overflow, for some pretty ridiculous output: $ ./nbdkit -U - memory size=$((2**63 - 512)) --run 'qemu-img info $nbd' image: nbd+unix://?socket=/tmp/nbdkitHSAzNz/socket file format: raw virtual size: -8388607T (9223372036854775296 bytes) disk size: unavailable But there's no reason to have two separate implementations of integer to human-readable abbreviation, where one has overflow and stops at 'T', while the other avoids overflow and goes all the way to 'E'. With this patch, the output now claims 8EiB instead of -8388607T, which really is the correct rounding of largest file size supported by qemu (we could go 511 bytes larger if we used byte-accurate sizing instead of rounding up to the next sector boundary, but that wouldn't change the human-readable result). Quite a few iotests need updates to expected output to match. Reported-by: Richard W.M. Jones <rjones@redhat.com> Signed-off-by: Eric Blake <eblake@redhat.com> Tested-by: Richard W.M. Jones <rjones@redhat.com> Reviewed-by: Alberto Garcia <berto@igalia.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> Tested-by: Max Reitz <mreitz@redhat.com>
2019-04-17 20:11:01 +03:00
virtual size: 1 GiB (1073741824 bytes)
iotests: Add test for -U/force-share conflicts Signed-off-by: Max Reitz <mreitz@redhat.com> Message-id: 20180502202051.15493-4-mreitz@redhat.com Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2018-05-02 23:20:51 +03:00
disk size: unavailable
Conflict:
qemu-img: --force-share/-U conflicts with image options
No conflict:
Conflict:
tests/qemu-iotests: Fix output of qemu-io related tests One of the recent commits changed the way qemu-io prints out its errors and warnings - they are now prefixed with the program name. We've got to adapt the iotests accordingly to prevent that they are failing. Fixes: 99e98d7c9fc1a1639fad ("qemu-io: Use error_[gs]et_progname()") Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2019-04-28 18:54:44 +03:00
qemu-io: -U conflicts with image options
qemu-iotests: Add test case 153 for image locking Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-05-02 19:35:57 +03:00
*** done
Reference in New Issue Copy Permalink