mirror of
https://git.proxmox.com/git/qemu-server
synced 2025-08-05 08:41:39 +00:00
![]() on storages where the minimum size of images is bigger than the real OVMF_VARS.fd file, they get padded to their minimum size when using such an image, qemu maps it fully to the vm, but the efi does not find the vars region and creates a file on the first efi partition it finds this breaks some settings in the ovmf, such as resolution to fix this, we have to specify the size for the pflash, so that qemu only maps the first n bytes in the vm (this only works for raw files, not for qcow2) we also have to use the correct size when converting between storages in 'clone_disk' (used for move disk and cloning vms) and when live migrating to different storages when we now expect that the source image is always correctly used/created (e.g. raw with size=x in pflash argument) then we always create the target correctly when encountering users which have a non-valid image (e.g. a efidisk moved from zfs to qcow2 before this patch), we have to tell them to recreate the efidisk and the settings on it we have to version_guard it to 4.1+pve2 (since we haven't bumped yet since the change to pve2) also add 2 tests, one for the old version and one for the new Signed-off-by: Dominik Csapak <d.csapak@proxmox.com> Tested-by: Stefan Reiter <s.reiter@proxmox.com> Reviewed-by: Stefan Reiter <s.reiter@proxmox.com> [ Thomas: rebased to master ] Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com> |
||
---|---|---|
.. | ||
efi-raw-old.conf | ||
efi-raw-old.conf.cmd | ||
efi-raw.conf | ||
efi-raw.conf.cmd | ||
i440fx-win10-hostpci.conf | ||
i440fx-win10-hostpci.conf.cmd | ||
minimal-defaults-to-new-machine.conf | ||
minimal-defaults-unsupported-pve-version.conf | ||
minimal-defaults.conf | ||
minimal-defaults.conf.cmd | ||
old-qemu.conf | ||
pinned-version.conf | ||
pinned-version.conf.cmd | ||
q35-linux-hostpci-multifunction.conf | ||
q35-linux-hostpci-multifunction.conf.cmd | ||
q35-linux-hostpci.conf | ||
q35-linux-hostpci.conf.cmd | ||
q35-win10-hostpci.conf | ||
q35-win10-hostpci.conf.cmd | ||
README.adoc | ||
simple1.conf | ||
simple1.conf.cmd | ||
spice-enhancments.conf | ||
spice-enhancments.conf.cmd | ||
spice-linux-4.1.conf | ||
spice-linux-4.1.conf.cmd | ||
spice-usb3.conf | ||
spice-usb3.conf.cmd | ||
spice-win.conf | ||
spice-win.conf.cmd |
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