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.eb...@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.
>
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
