We've got a separate option to configure the accelerator nowadays, which
is shorter to type and the preferred way of specifying an accelerator.
Use it in the source and examples to show that it is the favored option.
(However, do not touch the places yet which also specify other machine
options or multiple accelerators - these are currently still better
handled with one single "-machine" statement instead)
Signed-off-by: NThomas Huth <thuth@redhat.com>
Acked-by: NPaolo Bonzini <pbonzini@redhat.com>
Message-Id: <20190904052739.22123-1-thuth@redhat.com>
Signed-off-by: NLaurent Vivier <laurent@vivier.eu>

Unfortunately, changes introduced in af2041ed "audio: audiodev=
parameters no longer optional when -audiodev present" breaks backward
compatibility.  This patch changes the error into a deprecation warning.
Signed-off-by: NKővágó, Zoltán <DirtY.iCE.hu@gmail.com>
Message-id: 02d4328c33455742d01e0b62395013e95293c3ba.1566847960.git.DirtY.iCE.hu@gmail.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Let's add a possibility to query dirty-bitmaps not only on root nodes.
It is useful when dealing both with snapshots and incremental backups.
Signed-off-by: NVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Signed-off-by: NJohn Snow <jsnow@redhat.com>
Message-id: 20190717173937.18747-1-jsnow@redhat.com
[Added deprecation information. --js]
Signed-off-by: NJohn Snow <jsnow@redhat.com>
[Fixed spelling --js]

bdrv_create options specified with -o have no effect when skipping image
creation with -n, so this doesn't make sense. Warn against the misuse
and deprecate the combination so we can make it a hard error later.
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
Reviewed-by: NMax Reitz <mreitz@redhat.com>
Reviewed-by: NJohn Snow <jsnow@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

If the user hasn't specified a firmware to load (with -bios) or
specified no bios (with -bios none) then load OpenSBI by default. This
allows users to boot a RISC-V kernel with just -kernel.
Signed-off-by: NAlistair Francis <alistair.francis@wdc.com>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
Tested-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Tested-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>

Document that CPU model runnability guarantees won't apply to
unversioned CPU models anymore.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Message-Id: <20190628002844.24894-9-ehabkost@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>

Fallback might affect guest or worse whole host performance
or functionality if backing file were used to share guest RAM
with another process.

Patch deprecates fallback so that we could remove it in future
and ensure that QEMU will provide expected behavior and fail if
it can't use user provided backing file.
Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Message-Id: <20190626074228.11558-1-imammedo@redhat.com>
Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>

Implicit RAM distribution between nodes has exactly the same issues as:
  "numa: deprecate 'mem' parameter of '-numa node' option"
only with QEMU being the user that's 'adding' 'mem' parameter.

Deprecate it, to get it out of the way so that we could consolidate
guest RAM allocation using memory backends making it consistent and
possibly later on transition to using memory devices instead of
adhoc memory mapping for the initial RAM.
Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
Message-Id: <1559205199-233510-4-git-send-email-imammedo@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>

The parameter allows to configure fake NUMA topology where guest
VM simulates NUMA topology but not actually getting performance
benefits from it. The same or better results could be achieved
using 'memdev' parameter.
Beside of unpredictable performance, '-numa node.mem' option has
other issues when it's used with combination of -mem-path +
+ -mem-prealloc + memdev backends (pc-dimm), breaking binding of
memdev backends since mem-path/mem-prealloc are global and affect
the most of RAM allocations.

It's possible to make memdevs and global -mem-path/mem-prealloc
to play nicely together but that will just complicate already
complicated code and add unobious ways it could break on 2
different memmory allocation pathes and their combinations.

Instead of it, consolidate all guest RAM allocation over memdev
which still allows to create fake NUMA configurations if desired
and leaves one simplifyed code path to consider when it comes
to guest RAM allocation.

To achieve desired simplification deprecate 'mem' parameter as its
ad-hoc partitioning of initial RAM MemoryRegion can't be translated
to memdev based backend transparently to users and in compatible
manner (migration wise).

Later down the road that will allow to consolidate means of how
guest RAM is allocated and would permit us to clean up quite
a bit memory allocations and numa code, leaving only 'memdev'
implementation in place.
Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
Message-Id: <1559205199-233510-3-git-send-email-imammedo@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>

Python 2 will reach end of life in January 1 2020.  Declare it as
deprecated.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Message-Id: <20190503193721.18459-1-ehabkost@redhat.com>
Reviewed-by: NThomas Huth <thuth@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
[ehabkost: print "warning:" in lowercase]
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>

Deprecate the RISC-V privledge spec version 1.09.1 in favour of the new
1.10.0 and the ratified 1.11.0.
Signed-off-by: NAlistair Francis <alistair.francis@wdc.com>
Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>

The -mon pretty=on|off switch of the -mon option applies only to QMP
monitors. It's silently ignored for HMP. Deprecate this combination so
that we can make it an error in future versions.
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
Message-Id: <20190613153405.24769-16-kwolf@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
[Commit message tweaked]
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>

Add a generic spike machine (not tied to a version) and deprecate the
spike mahines that are tied to a specific version. As we can now specify
the CPU via the command line we no londer need specific versions of the
spike machines.
Signed-off-by: NAlistair Francis <alistair.francis@wdc.com>
Acked-by: NIgor Mammedov <imammedo@redhat.com>
Reviewed-by: NPalmer Dabbelt <palmer@sifive.com>
Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>

These can now be specified via the command line so we no longer need
these.
Signed-off-by: NAlistair Francis <alistair.francis@wdc.com>
Reviewed-by: NPalmer Dabbelt <palmer@sifive.com>
Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>

At the same time deprecate the ISA string CPUs.

It is dobtful anyone specifies the CPUs, but we are keeping them for the
Spike machine (which is about to be depreated) so we may as well just
mark them as deprecated.
Signed-off-by: NAlistair Francis <alistair.francis@wdc.com>
Reviewed-by: NPalmer Dabbelt <palmer@sifive.com>
Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>

The synth fsdriver never got used for anything else but the QTest
testcase for VirtIO 9P. And even there, QTest uses -fsdev synth and
-device virtio-9p-... directly.
Signed-off-by: NGreg Kurz <groug@kaod.org>
Reviewed-by: NThomas Huth <thuth@redhat.com>

The old -realtime mlock=on|off parameter does exactly the same as the
new -overcommit mem-lock=on|off parameter. Additionally, "-realtime"
does not activate any additional "realtime" capabilities as the name
might indicate. We should avoid to confuse the users this way, so
let's deprecate the old -realtime option.
Signed-off-by: NThomas Huth <thuth@redhat.com>
Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
Message-Id: <20190411175345.19414-1-thuth@redhat.com>

Commit 767abe7f ("chardev: forbid 'wait' option with client sockets")
is a bit too strict. Current libvirt always set wait=false, and will
thus fail to add client chardev.

Make the code more permissive, allowing wait=false with client socket
chardevs. Deprecate usage of 'wait' with client sockets.

Fixes: 767abe7f
Cc: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Message-id: 20190415163337.2795-1-marcandre.lureau@redhat.com
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

The current API allows us to report a single status, which we've defined as:

Frozen: has a successor, treated as qmp_locked, may or may not be enabled.
Locked: no successor, qmp_locked. may or may not be enabled.
Disabled: Not frozen or locked, disabled.
Active: Not frozen, locked, or disabled.

The problem is that both "Frozen" and "Locked" mean nearly the same thing,
and that both of them do not intuit whether they are recording guest writes
or not.

This patch deprecates that status field and introduces two orthogonal
properties instead to replace it.
Signed-off-by: NJohn Snow <jsnow@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-id: 20190223000614.13894-2-jsnow@redhat.com
Signed-off-by: NJohn Snow <jsnow@redhat.com>

This patch adds documentation of an -audiodev command line option, that
deprecates the old QEMU_* environment variables for audio backend
configuration.  It's syntax is similar to existing options (-netdev,
-device, etc):

  -audiodev driver_name,property=value,...

Although now it's possible to specify multiple -audiodev options on
command line, multiple audio backends are not supported yet.
Signed-off-by: NKővágó, Zoltán <DirtY.iCE.hu@gmail.com>
Message-id: ca5e761e58dcfaf591cf46080af3548551b42bb2.1552083282.git.DirtY.iCE.hu@gmail.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

The various ACL related commands are obsolete now that the QAuthZ
framework for authorization is fully integrated throughout QEMU network
services. These only ever worked with VNC and were never used by libvirt.
Mark it as deprecated with no direct replacement to be provided.

Authorization is now provided by using 'object_add' together with
the 'tls-authz' or 'sasl-authz' parameters to the VNC server, and
equivalent for other network services.
Reviewed-by: NJuan Quintela <quintela@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
Message-id: 20190227145755.26556-3-berrange@redhat.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

The VNC server has historically had support for ACLs to check both the
SASL username and the TLS x509 distinguished name. The VNC server was
responsible for creating the initial ACL, and the client app was then
responsible for populating it with rules using the HMP 'acl_add' command.

This is not satisfactory for a variety of reasons. There is no way to
populate the ACLs from the command line, users are forced to use the
HMP. With multiple network services all supporting TLS and ACLs now, it
is desirable to be able to define a single ACL that is referenced by all
services.

To address these limitations, two new options are added to the VNC
server CLI. The 'tls-authz' option takes the ID of a QAuthZ object to
use for checking TLS x509 distinguished names, and the 'sasl-authz'
option takes the ID of another object to use for checking SASL usernames.

In this example, we setup two authorization rules. The first allows any
client with a certificate issued by the 'RedHat' organization in the
'London' locality. The second ACL allows clients with either the
'joe@REDHAT.COM' or  'fred@REDHAT.COM' kerberos usernames. Both checks
must pass for the user to be allowed.

    $QEMU -object tls-creds-x509,id=tls0,dir=/home/berrange/qemutls,\
                  endpoint=server,verify-peer=yes \
          -object authz-simple,id=authz0,policy=deny,\
                  rules.0.match=O=RedHat,,L=London,rules.0.policy=allow \
          -object authz-simple,id=authz1,policy=deny,\
                  rules.0.match=fred@REDHAT.COM,rules.0.policy=allow \
                  rules.0.match=joe@REDHAT.COM,rules.0.policy=allow \
          -vnc 0.0.0.0:1,tls-creds=tls0,tls-authz=authz0,
	       sasl,sasl-authz=authz1 \
          ...other QEMU args...
Reviewed-by: NJuan Quintela <quintela@redhat.com>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
Message-id: 20190227145755.26556-2-berrange@redhat.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

query-events doesn't reflect compile-time configuration.  Instead of
fixing that, deprecate the command in favor of query-qmp-schema.

Libvirt prefers query-qmp-schema as of commit 22d7222ec0 "qemu: caps:
Don't call 'query-events' when we probe events from QMP schema".
It'll be in the next release.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20190214152251.2073-18-armbru@redhat.com>

The option is only a dummy since a long time. We've finally deprecated
it in QEMU v3.0, so it's time to remove it now.
Signed-off-by: NThomas Huth <thuth@redhat.com>
Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <1549545296-18903-3-git-send-email-thuth@redhat.com>
Signed-off-by: NLaurent Vivier <laurent@vivier.eu>

The two sections have accidentally been added again during the
merge of Paolo's and Gerd's trees.

Fixes: 3e29da9fSigned-off-by: NThomas Huth <thuth@redhat.com>
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Message-Id: <1549545296-18903-2-git-send-email-thuth@redhat.com>
Signed-off-by: NLaurent Vivier <laurent@vivier.eu>

It's been deprecated since QEMU 3.0, and nobody complained so far, so
it is time to remove this option now.
Signed-off-by: NThomas Huth <thuth@redhat.com>
Message-Id: <1544684731-18828-1-git-send-email-thuth@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Our command line interface is really quite overcrowded, we should avoid
duplicated options that do the same thing in just a slightly different
way. "-accel hax" is shorter and more generic that "-enable-hax", so
there is really no real usage for the latter option. "-enable-hax" has
been deprecated since two releases, and nobody complained so far, so
it's time to remove this now.
Signed-off-by: NThomas Huth <thuth@redhat.com>
Message-Id: <1544790073-23049-1-git-send-email-thuth@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

The -no-frame option has been deprecated with QEMU v2.12. It was only
useful with SDL1.2 - now that we've removed support for SDL1.2, we
can certainly remove the -no-frame option, too.
Signed-off-by: NThomas Huth <thuth@redhat.com>
Message-id: 1549351769-19620-1-git-send-email-thuth@redhat.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

The existing qemu-nbd --partition code claims to handle logical
partitions up to 8, since its introduction in 2008 (commit 7a5ca864).
However, the implementation is bogus (actual MBR logical partitions
form a sort of linked list, with one partition per extended table
entry, rather than four logical partitions in a single extended
table), making the code unlikely to work for anything beyond -P5 on
actual guest images. What's more, the code does not support GPT
partitions, which are becoming more popular, and maintaining device
subsetting in both NBD and the raw device is unnecessary duplication
of effort (even if it is not too difficult).

Note that obtaining the offsets of a partition (MBR or GPT) can be
learned by using 'qemu-nbd -c /dev/nbd0 file.qcow2 && sfdisk --dump
/dev/nbd0', but by the time you've done that, you might as well
just mount /dev/nbd0p1 that the kernel creates for you instead of
bothering with qemu exporting a subset.  Or, keeping to just
user-space code, use nbdkit's partition filter, which has already
known both GPT and primary MBR partitions for a while, and was
just recently enhanced to support arbitrary logical MBR parititions.

Start the clock on the deprecation cycle, with examples of how
to accomplish device subsetting without using -P.
Signed-off-by: NEric Blake <eblake@redhat.com>
Message-Id: <20190125234837.2272-1-eblake@redhat.com>
Reviewed-by: NRichard W.M. Jones <rjones@redhat.com>
Reviewed-by: NStefano Garzarella <sgarzare@redhat.com>

commit efe2add7 ("spapr/vio: deprecate the "irq" property") was
merged in QEMU version 3.0. The "irq" property" can be removed for
QEMU version 4.0.
Signed-off-by: NCédric Le Goater <clg@kaod.org>
Reviewed-by: NThomas Huth <thuth@redhat.com>
Reviewed-by: NGreg Kurz <groug@kaod.org>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>

SDL1.2 was deprecated in the 2.12.0 release with:

  commit e52c6ba3
  Author: Daniel P. Berrange <berrange@redhat.com>
  Date:   Mon Jan 15 14:25:33 2018 +0000

    ui: deprecate use of SDL 1.2 in favour of 2.0 series

    The SDL 2.0 release was made in Aug, 2013:

      https://www.libsdl.org/release/

    That will soon be 4 + 1/2 years ago, which is enough time to consider
    the 2.0 series widely supported.

    Thus we deprecate the SDL 1.2 support, which will allow us to delete it
    in the last release of 2018. By this time, SDL 2.0 will be more than 5
    years old.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
    Message-id: 20180115142533.24585-1-berrange@redhat.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

It is thus able to be removed in the 3.1.0 release.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
Message-Id: <20180822131554.3398-4-berrange@redhat.com>

[ kraxel: rebase ]
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

It's been marked as deprecated in QEMU v2.6.0 already, so really nobody
should use the legacy "ivshmem" device anymore (but use ivshmem-plain or
ivshmem-doorbell instead). Time to remove the deprecated device now.

Belatedly also update a mention of the deprecated "ivshmem" in the file
docs/specs/ivshmem-spec.txt to "ivshmem-doorbell". Missed in commit
5400c02b ("ivshmem: Split ivshmem-plain, ivshmem-doorbell off ivshmem").
Signed-off-by: NThomas Huth <thuth@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Signed-off-by: NKashyap Chamarthy <kchamart@redhat.com>
Message-Id: <20181213124224.31585-4-kchamart@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
Reviewed-by: NThomas Huth <thuth@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>

Signed-off-by: NKashyap Chamarthy <kchamart@redhat.com>
Message-Id: <20181213124224.31585-3-kchamart@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
[ehabkost: revert back to 'cpu-add' spelling]
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>

So that it is consistent with the naming of QMP's
Signed-off-by: NKashyap Chamarthy <kchamart@redhat.com>
Message-Id: <20181213124224.31585-2-kchamart@redhat.com>
Reviewed-by: NThomas Huth <thuth@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>

They've been deprecated for two releases and nobody complained that they
are still required anymore, so it's time to remove these now.
And while we're at it, mark the other remaining old 0.x machine types
as deprecated (since they can not properly be used for live-migration
anyway).
Signed-off-by: NThomas Huth <thuth@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>

The "handle" fsdev backend was deprecated in QEMU 2.12.0 with:

commit db3b3c72
Author: Greg Kurz <groug@kaod.org>
Date:   Mon Jan 8 11:18:23 2018 +0100

    9pfs: deprecate handle backend

    This backend raise some concerns:

    - doesn't support symlinks
    - fails +100 tests in the PJD POSIX file system test suite [1]
    - requires the QEMU process to run with the CAP_DAC_READ_SEARCH
      capability, which isn't recommended for security reasons

    This backend should not be used and wil be removed. The 'local'
    backend is the recommended alternative.

    [1] https://www.tuxera.com/community/posix-test-suite/Signed-off-by: NGreg Kurz <groug@kaod.org>
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>
Reviewed-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>

It has passed the two release cooling period without any complaint.

Remove it now.
Signed-off-by: NGreg Kurz <groug@kaod.org>
Reviewed-by: NThomas Huth <thuth@redhat.com>

The intended functionality of QMP `cpu-add` is replaced with
`device_add` (and `query-hotpluggable-cpus`).  So let's deprecate
`cpu-add`.

A complete example of vCPU hotplug with the recommended way (using
`device_add`) is provided as part of a seperate docs patch.

Suggested-by: Eduardo Habkost <ehabkost@redhat.com
Signed-off-by: NKashyap Chamarthy <kchamart@redhat.com>
Message-Id: <20181030123526.26415-2-kchamart@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>

It has been unmaintained since years, and there were only trivial or
tree-wide changes to the related files since many years, so the
code is likely very bitrotten and broken. For example the following
segfaults as soon as as you press a key:

 qemu-system-x86_64 -usb -device usb-bt-dongle -bt hci -bt device:keyboard

Since we are not aware of anybody using bluetooth with the current
version of QEMU, let's mark the subsystem as deprecated, with a special
request for the users to write to the qemu-devel mailing list in case
they still use it (so we could revert the deprecation status in that
case).
Signed-off-by: NThomas Huth <thuth@redhat.com>
Message-id: 1542016830-19189-1-git-send-email-thuth@redhat.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

-smp [cpus],sockets/cores/threads[,maxcpus] should describe topology
so that total number of logical CPUs [sockets * cores * threads]
would be equal to [maxcpus], however historically we didn't have
such check in QEMU and it is possible to start VM with an invalid
topology.
Deprecate invalid options combination so we can make sure that
the topology VM started with is always correct in the future.
Users with an invalid sockets/cores/threads/maxcpus values should
fix their CLI to make sure that
   [sockets * cores * threads] == [maxcpus]
Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
Reviewed-by: NAndrew Jones <drjones@redhat.com>
Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
Message-Id: <1536836762-273036-2-git-send-email-imammedo@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
[ehabkost: squashed unit test fix]
Message-Id: <20181019215345.521d58d7@igors-macbook-pro.local>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>