mirror of
git://git.proxmox.com/git/qemu-server.git
synced 2025-02-02 09:47:13 +03:00
ac0077cc33
The previously introduced approach can fail for pinned versions when a new QEMU release is introduced. The saner approach is to use a mapping that gives one pve-version for each QEMU release. Fortunately, the old system has not been bumped yet, so we can still change it without too much effort. QEMU versions without a mapping are assumed to be pve0, 4.1 is mapped to pve1 since thats what we had as our default previously. Pinned machine versions (i.e. pc-i440fx-4.1) are always assumed to be pve0, for specific pve-versions they'd have to be pinned as well (i.e. pc-i440fx-4.1+pve1). The new logic also makes the pve-version dynamic, and starts VMs with the lowest possible 'feature-level', i.e. if a feature is only available with 4.1+pve2, but the VM isn't using it, we still start it with 4.1+pve0. We die if we don't support a version that is requested from us. This allows us to use the pve-version as live-migration blocks (i.e. bumping the version and then live-migrating a VM which uses the new feature (so is running with the bumped version) to an outdated node will present the user with a helpful error message and fail instead of silently modifying the config and only failing *after* the migration). $version_guard is introduced in config_to_command to use for features that need to check pve-version, it automatically handles selecting the newest necessary pve-version for the VM. Tests have to be adjusted, since all of them now resolve to pve0 instead of pve1. EXPECT_ERROR matching is changed to use 'eq' instead of regex to allow special characters in error messages. Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>