file-posix: Consolidate the locking error message
diff mbox series

Message ID 20180601091835.21620-1-famz@redhat.com
State New
Headers show
Series
  • file-posix: Consolidate the locking error message
Related 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
Daniel P. Berrangé June 1, 2018, 2 p.m. UTC | #5
On Fri, Jun 01, 2018 at 09:33:59PM +0800, Fam Zheng wrote:
> 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).

I still don't think that it makes sense to remove the use of hints in the
block layer.

If we don't care about improved error messages for existing libvirt
versions, we can just add a 'hint' field in QMP and let new libvirt
use that:

diff --git a/qapi/qmp-dispatch.c b/qapi/qmp-dispatch.c
index 935f9e159c..82eb823f1f 100644
--- a/qapi/qmp-dispatch.c
+++ b/qapi/qmp-dispatch.c
@@ -132,9 +132,15 @@ static QObject *do_qmp_dispatch(QmpCommandList *cmds, QObject *request,
 
 QObject *qmp_build_error_object(Error *err)
 {
-    return qobject_from_jsonf("{ 'class': %s, 'desc': %s }",
-                              QapiErrorClass_str(error_get_class(err)),
-                              error_get_pretty(err));
+    const char *hint = error_get_hint(err);
+    if (hint)
+        return qobject_from_jsonf("{ 'class': %s, 'desc': %s, 'hint': %s }",
+                                  QapiErrorClass_str(error_get_class(err)),
+                                  error_get_pretty(err), hint);
+    else
+        return qobject_from_jsonf("{ 'class': %s, 'desc': %s }",
+                                  QapiErrorClass_str(error_get_class(err)),
+                                  error_get_pretty(err));
 }
 
 /*


there's no error_get_hint method right now, but its impl is essentially
the same as error_get_pretty.


If, however, we want to get better error messages for existing libvirt,
then, we should do:

diff --git a/qapi/qmp-dispatch.c b/qapi/qmp-dispatch.c
index 935f9e159c..bf6f92375a 100644
--- a/qapi/qmp-dispatch.c
+++ b/qapi/qmp-dispatch.c
@@ -132,9 +132,18 @@ static QObject *do_qmp_dispatch(QmpCommandList *cmds, QObject *request,
 
 QObject *qmp_build_error_object(Error *err)
 {
-    return qobject_from_jsonf("{ 'class': %s, 'desc': %s }",
-                              QapiErrorClass_str(error_get_class(err)),
-                              error_get_pretty(err));
+    const char *hint = error_get_hint(err);
+    const char *msg;
+    if (hint) {
+        msg = g_strdup_printf("%s: %s", error_get_pretty(), hint);
+    } else {
+        msg = g_strdup(error_get_pretty());
+    }
+    QObject *ret = qobject_from_jsonf("{ 'class': %s, 'desc': %s }",
+                                      QapiErrorClass_str(error_get_class(err)),
+                                      msg);
+    g_free(msg);
+    return ret;
 }
 
 /*

Personally I'd just go for the first case and only care about new libvirts.

Regards,
Daniel
Fam Zheng June 1, 2018, 2:17 p.m. UTC | #6
On Fri, 06/01 15:00, Daniel P. Berrangé wrote:
> On Fri, Jun 01, 2018 at 09:33:59PM +0800, Fam Zheng wrote:
> > 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).
> 
> I still don't think that it makes sense to remove the use of hints in the
> block layer.

I have no inclination to changing any other hints in the block layer. See
below..

> 
> If we don't care about improved error messages for existing libvirt
> versions, we can just add a 'hint' field in QMP and let new libvirt
> use that:
> 
> diff --git a/qapi/qmp-dispatch.c b/qapi/qmp-dispatch.c
> index 935f9e159c..82eb823f1f 100644
> --- a/qapi/qmp-dispatch.c
> +++ b/qapi/qmp-dispatch.c
> @@ -132,9 +132,15 @@ static QObject *do_qmp_dispatch(QmpCommandList *cmds, QObject *request,
>  
>  QObject *qmp_build_error_object(Error *err)
>  {
> -    return qobject_from_jsonf("{ 'class': %s, 'desc': %s }",
> -                              QapiErrorClass_str(error_get_class(err)),
> -                              error_get_pretty(err));
> +    const char *hint = error_get_hint(err);
> +    if (hint)
> +        return qobject_from_jsonf("{ 'class': %s, 'desc': %s, 'hint': %s }",
> +                                  QapiErrorClass_str(error_get_class(err)),
> +                                  error_get_pretty(err), hint);
> +    else
> +        return qobject_from_jsonf("{ 'class': %s, 'desc': %s }",
> +                                  QapiErrorClass_str(error_get_class(err)),
> +                                  error_get_pretty(err));
>  }
>  
>  /*
> 
> 
> there's no error_get_hint method right now, but its impl is essentially
> the same as error_get_pretty.
> 
> 
> If, however, we want to get better error messages for existing libvirt,
> then, we should do:
> 
> diff --git a/qapi/qmp-dispatch.c b/qapi/qmp-dispatch.c
> index 935f9e159c..bf6f92375a 100644
> --- a/qapi/qmp-dispatch.c
> +++ b/qapi/qmp-dispatch.c
> @@ -132,9 +132,18 @@ static QObject *do_qmp_dispatch(QmpCommandList *cmds, QObject *request,
>  
>  QObject *qmp_build_error_object(Error *err)
>  {
> -    return qobject_from_jsonf("{ 'class': %s, 'desc': %s }",
> -                              QapiErrorClass_str(error_get_class(err)),
> -                              error_get_pretty(err));
> +    const char *hint = error_get_hint(err);
> +    const char *msg;
> +    if (hint) {
> +        msg = g_strdup_printf("%s: %s", error_get_pretty(), hint);
> +    } else {
> +        msg = g_strdup(error_get_pretty());
> +    }
> +    QObject *ret = qobject_from_jsonf("{ 'class': %s, 'desc': %s }",
> +                                      QapiErrorClass_str(error_get_class(err)),
> +                                      msg);
> +    g_free(msg);
> +    return ret;
>  }
>  
>  /*
> 
> Personally I'd just go for the first case and only care about new libvirts.

Yes I think that is the plan. And that's the reason for exceptional cases like
this patch, for older libvirts (which of course is subjective).

Fam
Markus Armbruster June 7, 2018, 1:20 p.m. UTC | #7
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 | #8
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

Patch
diff mbox series

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