diff mbox

file-posix: Consolidate the locking error message

Message ID 20180601091835.21620-1-famz@redhat.com (mailing list archive)
State New, archived
Headers show

Commit Message

Fam Zheng June 1, 2018, 9:18 a.m. UTC 
When hot-plugging a block device fails due to image locking errors,
users won't see the helpful 'Is another process using the image?'
message in QMP because currently the error hint is not carried over
there.

Even though extending QMP to include hint is a conceivably easy task,
Libvirt will need some change to consume that data.

Before that is fully sorted out, let's just do the easy fix by joining
the two lines.

Signed-off-by: Fam Zheng <famz@redhat.com>
---
 block/file-posix.c         | 10 ++--
 tests/qemu-iotests/153.out | 99 +++++++++++++-------------------------
 tests/qemu-iotests/182.out |  3 +-
 3 files changed, 38 insertions(+), 74 deletions(-)

Comments

Eric Blake June 1, 2018, 12:32 p.m. UTC | #1 
On 06/01/2018 04:18 AM, Fam Zheng wrote:
> When hot-plugging a block device fails due to image locking errors,
> users won't see the helpful 'Is another process using the image?'
> message in QMP because currently the error hint is not carried over
> there.
> 
> Even though extending QMP to include hint is a conceivably easy task,
> Libvirt will need some change to consume that data.
> 
> Before that is fully sorted out, let's just do the easy fix by joining
> the two lines.
> 
> Signed-off-by: Fam Zheng <famz@redhat.com>
> ---
>   block/file-posix.c         | 10 ++--
>   tests/qemu-iotests/153.out | 99 +++++++++++++-------------------------
>   tests/qemu-iotests/182.out |  3 +-
>   3 files changed, 38 insertions(+), 74 deletions(-)
> 
> diff --git a/block/file-posix.c b/block/file-posix.c
> index 5a602cfe37..03776e13b1 100644
> --- a/block/file-posix.c
> +++ b/block/file-posix.c
> @@ -699,11 +699,10 @@ static int raw_check_lock_bytes(BDRVRawState *s,
>               if (ret) {
>                   char *perm_name = bdrv_perm_names(p);
>                   error_setg(errp,
> -                           "Failed to get \"%s\" lock",
> +                           "Failed to get \"%s\" lock. "
> +                           "Is another process using the image?",

Except that this goes against the error message recommendations that 
Markus has tried to remind people of (in general, using a full-stop in 
error_setg() is frowned on).  Markus, do you have any suggestions?
Daniel P. Berrangé June 1, 2018, 12:43 p.m. UTC | #2 
On Fri, Jun 01, 2018 at 05:18:35PM +0800, Fam Zheng wrote:
> When hot-plugging a block device fails due to image locking errors,
> users won't see the helpful 'Is another process using the image?'
> message in QMP because currently the error hint is not carried over
> there.
> 
> Even though extending QMP to include hint is a conceivably easy task,
> Libvirt will need some change to consume that data.
> 
> Before that is fully sorted out, let's just do the easy fix by joining
> the two lines.

There are many places in QEMU which uses error hints and these are all
invisible to libvirt. Arbitrarily picking one hint to remove, while
leaving everything else unfixed is not a very satisfactory approach.

If QEMU passes the hint in QMP, it is trivial for libvirt to be changed
to append the hint when reporting its own error message, so can we just
focus on fixing the root cause instead of special casing file-posix.c


Regards,
Daniel
Fam Zheng June 1, 2018, 1:33 p.m. UTC | #3 
On Fri, 06/01 13:43, Daniel P. Berrangé wrote:
> On Fri, Jun 01, 2018 at 05:18:35PM +0800, Fam Zheng wrote:
> > When hot-plugging a block device fails due to image locking errors,
> > users won't see the helpful 'Is another process using the image?'
> > message in QMP because currently the error hint is not carried over
> > there.
> > 
> > Even though extending QMP to include hint is a conceivably easy task,
> > Libvirt will need some change to consume that data.
> > 
> > Before that is fully sorted out, let's just do the easy fix by joining
> > the two lines.
> 
> There are many places in QEMU which uses error hints and these are all
> invisible to libvirt. Arbitrarily picking one hint to remove, while
> leaving everything else unfixed is not a very satisfactory approach.
> 
> If QEMU passes the hint in QMP, it is trivial for libvirt to be changed
> to append the hint when reporting its own error message, so can we just
> focus on fixing the root cause instead of special casing file-posix.c

The plan was to work on the QMP change in parallel, while this simple patch can
mitigate the confusion caused by the relatively vague message (the text itself
is going a bit on the cryptic side for people who don't know QEMU internals).

Fam
Fam Zheng June 1, 2018, 1:38 p.m. UTC | #4 
On Fri, 06/01 07:32, Eric Blake wrote:
> On 06/01/2018 04:18 AM, Fam Zheng wrote:
> > When hot-plugging a block device fails due to image locking errors,
> > users won't see the helpful 'Is another process using the image?'
> > message in QMP because currently the error hint is not carried over
> > there.
> > 
> > Even though extending QMP to include hint is a conceivably easy task,
> > Libvirt will need some change to consume that data.
> > 
> > Before that is fully sorted out, let's just do the easy fix by joining
> > the two lines.
> > 
> > Signed-off-by: Fam Zheng <famz@redhat.com>
> > ---
> >   block/file-posix.c         | 10 ++--
> >   tests/qemu-iotests/153.out | 99 +++++++++++++-------------------------
> >   tests/qemu-iotests/182.out |  3 +-
> >   3 files changed, 38 insertions(+), 74 deletions(-)
> > 
> > diff --git a/block/file-posix.c b/block/file-posix.c
> > index 5a602cfe37..03776e13b1 100644
> > --- a/block/file-posix.c
> > +++ b/block/file-posix.c
> > @@ -699,11 +699,10 @@ static int raw_check_lock_bytes(BDRVRawState *s,
> >               if (ret) {
> >                   char *perm_name = bdrv_perm_names(p);
> >                   error_setg(errp,
> > -                           "Failed to get \"%s\" lock",
> > +                           "Failed to get \"%s\" lock. "
> > +                           "Is another process using the image?",
> 
> Except that this goes against the error message recommendations that Markus
> has tried to remind people of (in general, using a full-stop in error_setg()
> is frowned on).  Markus, do you have any suggestions?

OK, now I remember what Markus suggested was a paranthesis around the second
sentence instead of following a full-stop. So it will look like:

"Failed to get shared \"%s\" lock (is another process using the image?)"

Is that an acceptable form?

Fam
Markus Armbruster June 7, 2018, 1:20 p.m. UTC | #5 
Daniel P. Berrangé <berrange@redhat.com> writes:

> On Fri, Jun 01, 2018 at 05:18:35PM +0800, Fam Zheng wrote:
>> When hot-plugging a block device fails due to image locking errors,
>> users won't see the helpful 'Is another process using the image?'
>> message in QMP because currently the error hint is not carried over
>> there.
>> 
>> Even though extending QMP to include hint is a conceivably easy task,
>> Libvirt will need some change to consume that data.
>> 
>> Before that is fully sorted out, let's just do the easy fix by joining
>> the two lines.
>
> There are many places in QEMU which uses error hints and these are all
> invisible to libvirt. Arbitrarily picking one hint to remove, while
> leaving everything else unfixed is not a very satisfactory approach.
>
> If QEMU passes the hint in QMP, it is trivial for libvirt to be changed
> to append the hint when reporting its own error message, so can we just
> focus on fixing the root cause instead of special casing file-posix.c

Intended use of hints according to error.h:

 * Intended use is adding helpful hints on the human user interface,
 * e.g. a list of valid values.  It's not for clarifying a confusing
 * error message.

I admit this guidance is widely ignored.

When used as intended, the hints need not make any sense in QMP!
Consider this example in qemu-option.c:

        error_setg(errp, QERR_INVALID_PARAMETER_VALUE, name,
                   "a non-negative number below 2^64");
        error_append_hint(errp, "Optional suffix k, M, G, T, P or E means"
                          " kilo-, mega-, giga-, tera-, peta-\n"
                          "and exabytes, respectively.\n");

The suffixes are only available in the human interface.

Aside: we have lots of code consuming input from both QMP and HMP / CLI.
The error reporting is generally atrocious for at least one of the two.

Perhaps we could use separate functions for providing syntax hints and
for clarifying confusing error messages.  Patches welcome, but they
better convert all existing uses.
Daniel P. Berrangé June 7, 2018, 1:22 p.m. UTC | #6 
On Thu, Jun 07, 2018 at 03:20:24PM +0200, Markus Armbruster wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:
> 
> > On Fri, Jun 01, 2018 at 05:18:35PM +0800, Fam Zheng wrote:
> >> When hot-plugging a block device fails due to image locking errors,
> >> users won't see the helpful 'Is another process using the image?'
> >> message in QMP because currently the error hint is not carried over
> >> there.
> >> 
> >> Even though extending QMP to include hint is a conceivably easy task,
> >> Libvirt will need some change to consume that data.
> >> 
> >> Before that is fully sorted out, let's just do the easy fix by joining
> >> the two lines.
> >
> > There are many places in QEMU which uses error hints and these are all
> > invisible to libvirt. Arbitrarily picking one hint to remove, while
> > leaving everything else unfixed is not a very satisfactory approach.
> >
> > If QEMU passes the hint in QMP, it is trivial for libvirt to be changed
> > to append the hint when reporting its own error message, so can we just
> > focus on fixing the root cause instead of special casing file-posix.c
> 
> Intended use of hints according to error.h:
> 
>  * Intended use is adding helpful hints on the human user interface,
>  * e.g. a list of valid values.  It's not for clarifying a confusing
>  * error message.
> 
> I admit this guidance is widely ignored.

Perhaps if we rename the function "error_append_hmp_hint" it would
make it obvious this is targetted at CLI users, and not QMP users,
and so encourage people to write better initial messages  ?

> 
> When used as intended, the hints need not make any sense in QMP!
> Consider this example in qemu-option.c:
> 
>         error_setg(errp, QERR_INVALID_PARAMETER_VALUE, name,
>                    "a non-negative number below 2^64");
>         error_append_hint(errp, "Optional suffix k, M, G, T, P or E means"
>                           " kilo-, mega-, giga-, tera-, peta-\n"
>                           "and exabytes, respectively.\n");
> 
> The suffixes are only available in the human interface.
> 
> Aside: we have lots of code consuming input from both QMP and HMP / CLI.
> The error reporting is generally atrocious for at least one of the two.
> 
> Perhaps we could use separate functions for providing syntax hints and
> for clarifying confusing error messages.  Patches welcome, but they
> better convert all existing uses.

Regards,
Daniel
diff mbox

Patch

diff --git a/block/file-posix.c b/block/file-posix.c
index 5a602cfe37..03776e13b1 100644
--- a/block/file-posix.c
+++ b/block/file-posix.c
@@ -699,11 +699,10 @@  static int raw_check_lock_bytes(BDRVRawState *s,
             if (ret) {
                 char *perm_name = bdrv_perm_names(p);
                 error_setg(errp,
-                           "Failed to get \"%s\" lock",
+                           "Failed to get \"%s\" lock. "
+                           "Is another process using the image?",
                            perm_name);
                 g_free(perm_name);
-                error_append_hint(errp,
-                                  "Is another process using the image?\n");
                 return ret;
             }
         }
@@ -716,11 +715,10 @@  static int raw_check_lock_bytes(BDRVRawState *s,
             if (ret) {
                 char *perm_name = bdrv_perm_names(p);
                 error_setg(errp,
-                           "Failed to get shared \"%s\" lock",
+                           "Failed to get shared \"%s\" lock. "
+                           "Is another process using the image?",
                            perm_name);
                 g_free(perm_name);
-                error_append_hint(errp,
-                                  "Is another process using the image?\n");
                 return ret;
             }
         }
diff --git a/tests/qemu-iotests/153.out b/tests/qemu-iotests/153.out
index 2510762ba1..e256a9f714 100644
--- a/tests/qemu-iotests/153.out
+++ b/tests/qemu-iotests/153.out
@@ -11,86 +11,67 @@  Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=33554432 backing_file=TEST_DIR/t
 == Launching QEMU, opts: '' ==
 
 == Launching another QEMU, opts: '' ==
-QEMU_PROG: -drive file=TEST_DIR/t.qcow2,if=none,: Failed to get "write" lock
-Is another process using the image?
+QEMU_PROG: -drive file=TEST_DIR/t.qcow2,if=none,: Failed to get "write" lock. Is another process using the image?
 
 == 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
-Is another process using the image?
+QEMU_PROG: -drive file=TEST_DIR/t.qcow2,if=none,read-only=on: Failed to get shared "write" lock. Is another process using the image?
 
 == Launching another QEMU, opts: 'read-only=on,force-share=on' ==
 
 == Running utility commands  ==
 
 _qemu_io_wrapper -c read 0 512 TEST_DIR/t.qcow2
-can't open device TEST_DIR/t.qcow2: Failed to get "write" lock
-Is another process using the image?
+can't open device TEST_DIR/t.qcow2: Failed to get "write" lock. Is another process using the image?
 
 _qemu_io_wrapper -r -c read 0 512 TEST_DIR/t.qcow2
-can't open device TEST_DIR/t.qcow2: Failed to get shared "write" lock
-Is another process using the image?
+can't open device TEST_DIR/t.qcow2: Failed to get shared "write" lock. Is another process using the image?
 
 _qemu_io_wrapper -c open  TEST_DIR/t.qcow2 -c read 0 512
-can't open device TEST_DIR/t.qcow2: Failed to get "write" lock
-Is another process using the image?
+can't open device TEST_DIR/t.qcow2: Failed to get "write" lock. Is another process using the image?
 no file open, try 'help open'
 
 _qemu_io_wrapper -c open -r  TEST_DIR/t.qcow2 -c read 0 512
-can't open device TEST_DIR/t.qcow2: Failed to get shared "write" lock
-Is another process using the image?
+can't open device TEST_DIR/t.qcow2: Failed to get shared "write" lock. Is another process using the image?
 no file open, try 'help open'
 
 _qemu_img_wrapper info TEST_DIR/t.qcow2
-qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get shared "write" lock
-Is another process using the image?
+qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get shared "write" lock. Is another process using the image?
 
 _qemu_img_wrapper check TEST_DIR/t.qcow2
-qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get shared "write" lock
-Is another process using the image?
+qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get shared "write" lock. Is another process using the image?
 
 _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
-Is another process using the image?
+qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get shared "write" lock. Is another process using the image?
 
 _qemu_img_wrapper map TEST_DIR/t.qcow2
-qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get shared "write" lock
-Is another process using the image?
+qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get shared "write" lock. Is another process using the image?
 
 _qemu_img_wrapper amend -o  TEST_DIR/t.qcow2
-qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get "write" lock
-Is another process using the image?
+qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get "write" lock. Is another process using the image?
 
 _qemu_img_wrapper commit TEST_DIR/t.qcow2
-qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get "write" lock
-Is another process using the image?
+qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get "write" lock. Is another process using the image?
 
 _qemu_img_wrapper resize TEST_DIR/t.qcow2 32M
-qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get "write" lock
-Is another process using the image?
+qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get "write" lock. Is another process using the image?
 
 _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
-Is another process using the image?
+qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get "write" lock. Is another process using the image?
 
 _qemu_img_wrapper snapshot -l TEST_DIR/t.qcow2
-qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get shared "write" lock
-Is another process using the image?
+qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get shared "write" lock. Is another process using the image?
 
 _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
-Is another process using the image?
+qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get shared "write" lock. Is another process using the image?
 
 _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
-Is another process using the image?
+qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get shared "write" lock. Is another process using the image?
 
 _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
-Is another process using the image?
+qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get shared "write" lock. Is another process using the image?
 
 _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
-Is another process using the image?
+qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get "write" lock. Is another process using the image?
 
 == Running utility commands -U ==
 
@@ -126,8 +107,7 @@  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
-Is another process using the image?
+qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get "write" lock. Is another process using the image?
 
 _qemu_img_wrapper snapshot -l -U TEST_DIR/t.qcow2
 
@@ -151,8 +131,7 @@  Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=33554432 backing_file=TEST_DIR/t
 == 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
-Is another process using the image?
+QEMU_PROG: -drive file=TEST_DIR/t.qcow2,if=none,: Failed to get "write" lock. Is another process using the image?
 
 == Launching another QEMU, opts: 'read-only=on' ==
 
@@ -161,14 +140,12 @@  Is another process using the image?
 == Running utility commands  ==
 
 _qemu_io_wrapper -c read 0 512 TEST_DIR/t.qcow2
-can't open device TEST_DIR/t.qcow2: Failed to get "write" lock
-Is another process using the image?
+can't open device TEST_DIR/t.qcow2: Failed to get "write" lock. Is another process using the image?
 
 _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
-can't open device TEST_DIR/t.qcow2: Failed to get "write" lock
-Is another process using the image?
+can't open device TEST_DIR/t.qcow2: Failed to get "write" lock. Is another process using the image?
 no file open, try 'help open'
 
 _qemu_io_wrapper -c open -r  TEST_DIR/t.qcow2 -c read 0 512
@@ -182,20 +159,16 @@  _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
-Is another process using the image?
+qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get "write" lock. Is another process using the image?
 
 _qemu_img_wrapper commit TEST_DIR/t.qcow2
-qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get "write" lock
-Is another process using the image?
+qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get "write" lock. Is another process using the image?
 
 _qemu_img_wrapper resize TEST_DIR/t.qcow2 32M
-qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get "write" lock
-Is another process using the image?
+qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get "write" lock. Is another process using the image?
 
 _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
-Is another process using the image?
+qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get "write" lock. Is another process using the image?
 
 _qemu_img_wrapper snapshot -l TEST_DIR/t.qcow2
 
@@ -206,8 +179,7 @@  _qemu_img_wrapper dd if=TEST_DIR/t.qcow2 of=TEST_DIR/t.qcow2.convert bs=512 coun
 _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
-Is another process using the image?
+qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get "write" lock. Is another process using the image?
 
 == Running utility commands -U ==
 
@@ -243,8 +215,7 @@  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
-Is another process using the image?
+qemu-img: Could not open 'TEST_DIR/t.qcow2': Failed to get "write" lock. Is another process using the image?
 
 _qemu_img_wrapper snapshot -l -U TEST_DIR/t.qcow2
 
@@ -364,14 +335,12 @@  Formatting 'TEST_DIR/t.IMGFMT.c', fmt=IMGFMT size=33554432 backing_file=TEST_DIR
 == 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
-Is another process using the image?
+QEMU_PROG: -drive if=none,file=TEST_DIR/t.qcow2: Failed to get "write" lock. Is another process using the image?
 
 == 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
-Is another process using the image?
+QEMU_PROG: -drive if=none,file=TEST_DIR/t.qcow2: Failed to get "write" lock. Is another process using the image?
 
 == Active commit to intermediate layer should work when base in use ==
 {"return": {}}
@@ -381,8 +350,7 @@  _qemu_img_wrapper commit -b TEST_DIR/t.qcow2.b TEST_DIR/t.qcow2.c
 Adding drive
 
 _qemu_io_wrapper TEST_DIR/t.qcow2 -c write 0 512
-can't open device TEST_DIR/t.qcow2: Failed to get "write" lock
-Is another process using the image?
+can't open device TEST_DIR/t.qcow2: Failed to get "write" lock. Is another process using the image?
 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
@@ -394,8 +362,7 @@  Adding two and closing one
 _qemu_img_wrapper info TEST_DIR/t.qcow2
 
 _qemu_io_wrapper TEST_DIR/t.qcow2 -c write 0 512
-can't open device TEST_DIR/t.qcow2: Failed to get "write" lock
-Is another process using the image?
+can't open device TEST_DIR/t.qcow2: Failed to get "write" lock. Is another process using the image?
 Closing the other
 
 _qemu_io_wrapper TEST_DIR/t.qcow2 -c write 0 512
diff --git a/tests/qemu-iotests/182.out b/tests/qemu-iotests/182.out
index 23a4dbf809..66abaa3357 100644
--- a/tests/qemu-iotests/182.out
+++ b/tests/qemu-iotests/182.out
@@ -3,6 +3,5 @@  Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=33554432
 Starting QEMU
 
 Starting a second QEMU using the same image should fail
-QEMU_PROG: -drive file=TEST_DIR/t.qcow2,if=none,id=drive0,file.locking=on: Failed to get "write" lock
-Is another process using the image?
+QEMU_PROG: -drive file=TEST_DIR/t.qcow2,if=none,id=drive0,file.locking=on: Failed to get "write" lock. Is another process using the image?
 *** done