[pve-devel] [PATCH docs v2 18/18] qm: machine version: document support in PVE

[Thomas Lamprecht]

Am 16.01.25 um 12:50 schrieb Fiona Ebner:
> Elaborate on new QEMU machine version removal policy and how PVE will
> support machine versions. Make sure to also mention the years, so that
> users immediately have a good idea for how long it will be.
> 
> Signed-off-by: Fiona Ebner <f.ebner at proxmox.com>
> ---
> 
> Changes in v2:
> * get rid of outdated information from "Update to a Newer Machine
>   Version" section
> * drop sentence about early pre-deprecation warning (doesn't exist
>   anymore)
> 
>  qm.adoc | 39 +++++++++++++++++++++++++++++++--------
>  1 file changed, 31 insertions(+), 8 deletions(-)
> 
> diff --git a/qm.adoc b/qm.adoc
> index 94fdd4e..9d8becf 100644
> --- a/qm.adoc
> +++ b/qm.adoc
> @@ -173,19 +173,42 @@ This means that after a fresh start, the newest machine version supported by the
>  QEMU binary is used (e.g. the newest machine version QEMU 8.1 supports is
>  version 8.1 for each machine type).
>  

Maybe make this a separate section and add a `QEMU Machine Version Depreaction`
heading, or the like, here?

> +Starting with QEMU 10.1, machine versions will be removed from upstream QEMU

opinionated nit: s/will be/are/

> +after 6 years. In {pve}, major releases happen approximately every 2 years, so a
> +major {pve} release will support machine versions from approximately two
> +previous major {pve} releases, more details below.

I'd drop the ", more details below." or if you really think it helps then link
to the respective paragraph, as else I as reader get distracted with searching
where this is explained exactly.

> +
> +Before upgrading to a new major {pve} release, you should update VM
> +configurations to avoid all machine versions that will be dropped during the
> +next major {pve} release. This ensures that the guests can still be used
> +throughout that release. See the section
> +xref:qm_machine_update[Update to a Newer Machine Version].
> +
> +The following table shows the expected baselines of supported machine versions
> +for the current and upcoming major {pve} releases (best guesses):

Maybe avoid a table with all releases listed (and the note below) and instead
write a specific example, e.g. for PVE 9, mixed with a description how the
decision/cut-off process works – the table can be surely nice for some, but
probably also not trivial to interpret for all users, and it might get outdated,
especially if we got something like total 5 year (LTS) life span, which is not
very likely very soon, but also not completely out of the question.

Or just a list of the expected base-line, maybe we could generate that through
some small perl script for current - 1, current and current + 1 release and
include that here? Just as an idea, I do not want to inflate the scope to much ^^

> +
> +[width="100%",cols=">s,>,>s,2*>",options="header"]
> +|===============================================================================================
> +| {pve} | active development | supported baseline | dropped during life cycle | last QEMU binary

nit: if, I'd title-case the column titles, I normally use AP style for that and
if unsure I run the title through [0].

[0]: https://titlecaseconverter.com/

Also, "dropped during life cycle" seems a bit redundant to me, a sentence above
or below that states that all machine versions below the baseline are not
supported anymore would be enough.

> +|     8 |          2023-2025 |                2.4 |             2.3 and older |              9.2
> +|     9 |          2025-2027 |                6.0 |             5.2 and older |             11.2
> +|    10 |          2027-2029 |                8.0 |             7.2 and older |             13.2
> +|===============================================================================================


> +
> +NOTE: Support for {pve} releases is longer than active development, but no new
> +QEMU binary versions will be added after active development, just backports and
> +fixes for existing binary versions.
> +
>  [[qm_machine_update]]
>  
>  Update to a Newer Machine Version
>  +++++++++++++++++++++++++++++++++
>  
> -Very old machine versions might become deprecated in QEMU. For example, this is
> -the case for versions 1.4 to 1.7 for the i440fx machine type. It is expected
> -that support for these machine versions will be dropped at some point. If you
> -see a deprecation warning, you should change the machine version to a newer one.
> -Be sure to have a working backup first and be prepared for changes to how the
> -guest sees hardware. In some scenarios, re-installing certain drivers might be
> -required. You should also check for snapshots with RAM that were taken with
> -these machine versions (i.e. the `runningmachine` configuration entry).
> +If you see a deprecation warning, you should change the machine version to a
> +newer one. Be sure to have a working backup first and be prepared for changes to
> +how the guest sees hardware. In some scenarios, re-installing certain drivers
> +might be required. You should also check for snapshots with RAM that were taken
> +with these machine versions (i.e. the `runningmachine` configuration entry).
>  Unfortunately, there is no way to change the machine version of a snapshot, so
>  you'd need to load the snapshot to salvage any data from it.
>