From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <pve-devel-bounces@lists.proxmox.com>
Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9])
by lore.proxmox.com (Postfix) with ESMTPS id DBB301FF15C
for <inbox@lore.proxmox.com>; Fri, 4 Apr 2025 18:08:51 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
by firstgate.proxmox.com (Proxmox) with ESMTP id A736536A7F;
Fri, 4 Apr 2025 18:08:37 +0200 (CEST)
Date: Fri, 4 Apr 2025 18:08:03 +0200
From: Stoiko Ivanov <s.ivanov@proxmox.com>
To: Dominik Csapak <d.csapak@proxmox.com>
Message-ID: <20250404180803.73ca3c6a@rosa.proxmox.com>
In-Reply-To: <20250404125345.3244659-10-d.csapak@proxmox.com>
References: <20250404125345.3244659-1-d.csapak@proxmox.com>
<20250404125345.3244659-10-d.csapak@proxmox.com>
X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; x86_64-pc-linux-gnu)
MIME-Version: 1.0
X-SPAM-LEVEL: Spam detection results: 0
AWL 0.064 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DMARC_MISSING 0.1 Missing DMARC policy
KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to
Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more
information.
RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to
Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more
information.
RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to
Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more
information.
SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record
SPF_PASS -0.001 SPF: sender matches SPF record
URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more
information. [proxmox.com]
Subject: Re: [pve-devel] [PATCH docs v3 1/1] qm: pve machine version: add
section to explain +pveX versions
X-BeenThere: pve-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>,
<mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>,
<mailto:pve-devel-request@lists.proxmox.com?subject=subscribe>
Reply-To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Cc: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: pve-devel-bounces@lists.proxmox.com
Sender: "pve-devel" <pve-devel-bounces@lists.proxmox.com>
some suggestions for rephrasings inline:
On Fri, 4 Apr 2025 14:53:45 +0200
Dominik Csapak <d.csapak@proxmox.com> wrote:
> and clarify what windows guests will be pinned to.
>
> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
> ---
> changes from v2:
> * mention that windows gets pinned during guest creation
>
> qm.adoc | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/qm.adoc b/qm.adoc
> index 2617a7c..ff49c37 100644
> --- a/qm.adoc
> +++ b/qm.adoc
> @@ -173,6 +173,21 @@ 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).
>
> +PVE Machine Version
> ++++++++++++++++++++
> +
> +Sometimes it's necessary to introduce new defaults or change the existing
> +hardware layout for new guests. For this, we have introduces an additional 'pve
s/introduces/introduced/
but on a meta-level:
https://pve.proxmox.com/wiki/Technical_Writing_Style_Guide#Avoid_first_person
Maybe something like:
Some changes to the default settings or hardware layout are done by {pve}
on top of QEMU's defaults. Those are recorded in the 'pve machine
version'.
?
> +machine version'. This version begins with 0 with every new QEMU machine
> +version, for example 'pc-q35-9.2+pve0'. When we want to change the hardware
> +layout or a default option, we bump it to the next one (e.g.
> +'pc-q35-9.2+pve1'), so older running guests are not impacted. When pinning a
When a change is done the number after +pve is increased (e.g.
'pc-q35-9.2+pve1') in order to not impact older running guests.
> +guest to a specific machine, this can be omitted. In that case it defaults to
> +0.
If omitted the 'pve machine version' defaults to 0.
> +
> +Windows guests get pinned to the most current version that is available for the
> +specific machine version during guest creation.
We have a similar statement in the paragraph above (for the qemu-machine
version) - maybe shorten this to:
Windows guests 'pve machine version' is pinnned, along with the QEMU
version during guest creation.
> +
> QEMU Machine Version Deprecation
> ++++++++++++++++++++++++++++++++
>
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel