qemu-server/test/cfg2cmd
Dominik Csapak 844b55fb89 fix #2510: hostpci: always check if device exists
if the user set a device as hostpci with the 'shorthand' syntax:

hostpciX: 00:12

we ignored it on starting and showcmd and continued.
Since the user explicitly wanted to passthrough a device, we now check
if there is actually a device with that id

for explicitly configured devices (00:12.1), we did not check if it exists,
but the kvm call failed with a non-obvious error message

now we always call 'lspci' from SysFSTools to check if it actually exists,
and fail if not. With this, we can drop the workaround for adding
'0000' if no domain was given, since lspci does it already for us

this fixes #2510, an issue with using mediated devices where the users did not have
the domain in the config, since we forgot to add the default domain there

the only issue with this patch is that it changes the behaviour of
'showcmd' slightly, as in now, we die if the device was explicitly
given, but did not exists (we showed the commandline, now we fail)

this also slightly changes the commandline for qemu (adding always
the domain), which is not a problem since we cannot live migrate
or snapshot such vms, but we have to adapt the tests

Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
2019-12-09 11:30:14 +01:00
..
i440fx-win10-hostpci.conf cfg2cmd: fix descriptions of cfg2cmd test cases 2019-10-02 08:35:27 +02:00
i440fx-win10-hostpci.conf.cmd fix #2510: hostpci: always check if device exists 2019-12-09 11:30:14 +01:00
minimal-defaults.conf add config to command tests 2018-12-11 10:44:04 +01:00
minimal-defaults.conf.cmd implement PVE Version addition for QEMU machine 2019-11-25 16:43:38 +01:00
pinned-version.conf refactor: split qemu_machine_feature_enabled 2019-11-20 18:32:35 +01:00
pinned-version.conf.cmd refactor: split qemu_machine_feature_enabled 2019-11-20 18:32:35 +01:00
q35-linux-hostpci-multifunction.conf cfg2cmd test: add tests for multifunction devices 2019-12-09 11:30:14 +01:00
q35-linux-hostpci-multifunction.conf.cmd cfg2cmd test: add tests for multifunction devices 2019-12-09 11:30:14 +01:00
q35-linux-hostpci.conf cfg2cmd: fix descriptions of cfg2cmd test cases 2019-10-02 08:35:27 +02:00
q35-linux-hostpci.conf.cmd fix #2510: hostpci: always check if device exists 2019-12-09 11:30:14 +01:00
q35-win10-hostpci.conf cfg2cmd test: hostpci, also specify exact PCIe devices 2019-09-09 08:40:07 +02:00
q35-win10-hostpci.conf.cmd fix #2510: hostpci: always check if device exists 2019-12-09 11:30:14 +01:00
README.adoc add config to command tests 2018-12-11 10:44:04 +01:00
simple1.conf add config to command tests 2018-12-11 10:44:04 +01:00
simple1.conf.cmd drop vnc x509 param, deprecated in 2.5 removed in 4.0 2019-06-06 09:52:44 +02:00
spice-enhancments.conf cfg2cmd test: fix spice enhancement test 2019-11-25 07:45:44 +01:00
spice-enhancments.conf.cmd test cfg2cmd: add spice enhancement test 2019-10-09 16:51:03 +02:00
spice-linux-4.1.conf followup: adding qxl max_outputs breaks live-migration/restore 2019-11-20 15:33:48 +01:00
spice-linux-4.1.conf.cmd implement PVE Version addition for QEMU machine 2019-11-25 16:43:38 +01:00
spice-usb3.conf cfg2cmd: support USB 3 SPICE ports with 4.0 machine feature 2019-09-26 11:54:53 +02:00
spice-usb3.conf.cmd followup: adding qxl max_outputs breaks live-migration/restore 2019-11-20 15:33:48 +01:00
spice-win.conf cfg2cmd: add win10 spice test 2019-11-19 16:12:20 +01:00
spice-win.conf.cmd cfg2cmd: add win10 spice test 2019-11-19 16:12:20 +01:00

QemuServer Config 2 Command Test
================================
Thomas Lamprecht <t.lamprecht@proxmox.com>

Overview
--------

This is a relatively simple configuration to command test program.
It's main goals are to better enforce stability of commands, thus reducing
the likelihood that, for example, a migration breaking change which forgot to
bump/check the KVM/QEMU version, slips through

Further you get a certain regression and functional test coverage. You get a
safety net against breaking older or not often (manual) tested setups and
features.

NOTE: The safety net is only as good as the test count *and* quality.


Test Specification
------------------

A single test consists of two files, the input VM config `FILE.conf` and the
expected output command `FILE.conf.cmd`

Input
~~~~~

The `FILE.conf` are standard Proxmox VE VM configuration files, so you can just
copy over a config file from `/etc/pve/qemu-server` to add a configuration you
want to have tested.

Output
~~~~~~

For the expected output `FILE.conf.cmd` we check the KVM/QEMU command produced.
As a single long line would be pretty hard to check for (problematic) changes
by humans, we use a pretty format, i.e., where each key value pair is on it's
own line. With this approach we can just diff expected and actual command and
one can pin point pretty fast in which component (e.g., net, drives, CPU, ...)
the issue is, if any. Such an output would look like:

----
/usr/bin/kvm \
  -id 101 \
  -name vm101 \
  ...
----

TIP: If the expected output file does not exist we have nothing to check, but
for convenience we will write it out. This should happen from clean code, and
the result should not get applied blindly, but only after a (quick) sanity
check.


Environment
~~~~~~~~~~~

It makes sense to have a stable and controlled environment for tests, thus you
one can use the 'description' in VM configurations to control this. The
description consists of all lines beginning with a '#' as first non-whitespace
character. Any environment variable follows the following format:

----
# NAME: VALUE
... rest of config...
----

There are the following variables you can control:

* *TEST*: a one line description for your test, gets outputted one testing and
  should described in a short way any specialty about this specific test,
  i.e., what does this test wants to ensure.

* *QEMU_VERSION*: the version we fake for this test, if not set we use the
  actual one installed on the host.

* *HOST_ARCH*: the architecture we should fake for the test (aarch64 or x86_64),
  defaults to `x86_64` to allow making this optional and still guarantee
  stable tests

The storage environment is currently hardcoded in the test code, you can
extend it there if it's needed.

// vim: noai:tw=78