From: Fiona Ebner <f.ebner@proxmox.com>
To: Dominik Csapak <d.csapak@proxmox.com>,
Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH qemu-server 4/8] machine: correctly select pve machine version for non pinned windows guests
Date: Thu, 6 Mar 2025 15:20:54 +0100 [thread overview]
Message-ID: <44562ad1-b232-42c9-b07b-86f21fca005b@proxmox.com> (raw)
In-Reply-To: <fbd8674b-909a-4cf6-a612-c652f2aa70ab@proxmox.com>
Am 06.03.25 um 15:15 schrieb Dominik Csapak:
> On 3/6/25 15:10, Fiona Ebner wrote:
>> Am 06.03.25 um 14:36 schrieb Dominik Csapak:
>>> On 3/6/25 14:10, Fiona Ebner wrote:
>>>> Am 06.03.25 um 11:44 schrieb Dominik Csapak:
>>>>> diff --git a/PVE/QemuServer/Machine.pm b/PVE/QemuServer/Machine.pm
>>>>> index f1acde8f..e3da8e21 100644
>>>>> --- a/PVE/QemuServer/Machine.pm
>>>>> +++ b/PVE/QemuServer/Machine.pm
>>>>> @@ -237,14 +237,19 @@ sub get_vm_machine {
>>>>> if (PVE::QemuServer::Helpers::min_version($meta-
>>>>>> {'creation-qemu'}, 9, 1)) {
>>>>> # need only major.minor
>>>>> ($base_version) = ($meta->{'creation-qemu'} =~ m/^(\d+.
>>>>> \d+)/);
>>>>> + # append pve machine version if we have one
>>>>> + if (my $pvever = $meta->{'creation-pve-machine'}) {
>>>>> + $base_version .= "+pve$pvever"
>>>>
>>>> Since this is only the fallback handling for the rare edge case
>>>> where no
>>>> explicit machine version is set for a Windows guest, not sure if it's
>>>> even worth doing this. I.e. can we just avoid the additional meta
>>>> property and always use pve0 here? Did you intend any other use for the
>>>> creation-pve-machine?
>>>>
>>>
>>> I though the intention of the code was to pin the guest to that version
>>> where it
>>> was created. If we omit the machine version, this is not true anymore,
>>> since I'd then create a windows vm with e.g. pc-q35-9.2+pve1 then set it
>>> to q35, and would get pc-q35-9.2+pve0
>>
>> Fair enough. There might be people manually changing windows guests to
>> use the latest machine even if we don't recommend it or allow it in the
>> UI. Still, it would just mean a pve machine version downgrade for
>> subsequent boots, which also can happen if you offline migrate to a node
>> that does not yet support the newest pve machine version.
>>
>>>
>>> and while i don't have anymore use cases for the current case, wouldn't
>>> this approach here correct also when we decide to bump again in the
>>> future?
>>
>> Correct what?
>>
>
> i wanted to write 'wouldn't this approach here be correct [..]'
I never said it's not correct. Just questioning if it's worth it.
>>> also recording with which pve version the vm was created could help in
>>> debugging
>>> issues at some point.. (my patch only adds the version in the meta info
>>> if it's > 0 anyway)
>>>
>>
>> In principle, yes. But honestly, it's much less informative than the
>> creation QEMU version, and even that is rather rarely useful for
>> debugging in my experience.
>>
>> So not a huge fan, since I'd find it nicer to keep the meta info slick,
>> but we can go for it if you really think it's worth it.
>
>
> mhmm i get what you mean, would it be an ok compromise to record the pve
> version with
> the creation machine maybe?
>
> i'd have to touch the places where we read that ofc but that shouldn't
> be too many
>
The creation-qemu is the binary version, but the latest pve version is
related to the qemu-server version/machine version, so while I get where
you're coming from, I'd rather keep them separate.
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
next prev parent reply other threads:[~2025-03-06 14:21 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-06 10:44 [pve-devel] [PATCH qemu-server 0/8] disable S3/S4 power states by default Dominik Csapak
2025-03-06 10:44 ` [pve-devel] [RFC PATCH qemu-server 1/8] tests: cfg2cmd: pin QEMU version Dominik Csapak
2025-03-06 12:00 ` Fiona Ebner
2025-03-06 12:07 ` Dominik Csapak
2025-03-06 12:43 ` Fiona Ebner
2025-03-06 10:44 ` [pve-devel] [PATCH qemu-server 2/8] config to command: add one '-global' option for each flag Dominik Csapak
2025-03-06 12:13 ` Fiona Ebner
2025-03-06 12:15 ` Dominik Csapak
2025-03-06 12:55 ` Fiona Ebner
2025-03-07 9:54 ` Dominik Csapak
2025-03-07 10:00 ` Fiona Ebner
2025-03-07 10:05 ` Dominik Csapak
2025-03-07 10:14 ` Fiona Ebner
2025-03-06 10:44 ` [pve-devel] [PATCH qemu-server 3/8] meta info: also add current pve-machine version Dominik Csapak
2025-03-06 10:44 ` [pve-devel] [PATCH qemu-server 4/8] machine: correctly select pve machine version for non pinned windows guests Dominik Csapak
2025-03-06 13:10 ` Fiona Ebner
2025-03-06 13:36 ` Dominik Csapak
2025-03-06 14:10 ` Fiona Ebner
2025-03-06 14:14 ` Fiona Ebner
2025-03-06 14:15 ` Dominik Csapak
2025-03-06 14:20 ` Fiona Ebner [this message]
2025-03-07 9:55 ` Dominik Csapak
2025-03-06 10:44 ` [pve-devel] [PATCH qemu-server 5/8] machine: incorporate pve machine version when pinning " Dominik Csapak
2025-03-06 14:32 ` Fiona Ebner
2025-03-07 9:58 ` Dominik Csapak
2025-03-07 10:06 ` Fiona Ebner
2025-03-06 10:44 ` [pve-devel] [PATCH qemu-server 6/8] machine: add S3/S4 power state properties Dominik Csapak
2025-03-06 14:52 ` Fiona Ebner
2025-03-07 10:02 ` Dominik Csapak
2025-03-07 10:10 ` Fiona Ebner
2025-03-06 10:44 ` [pve-devel] [PATCH qemu-server 7/8] machine: bump pve machine version and reverse the s3/s4 defaults Dominik Csapak
2025-03-06 15:04 ` Fiona Ebner
2025-03-06 10:44 ` [pve-devel] [PATCH qemu-server 8/8] tests: cfg2cmd: add test for windows machine pinning from meta info Dominik Csapak
2025-03-06 15:10 ` Fiona Ebner
2025-03-07 14:46 ` [pve-devel] [PATCH qemu-server 0/8] disable S3/S4 power states by default Dominik Csapak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44562ad1-b232-42c9-b07b-86f21fca005b@proxmox.com \
--to=f.ebner@proxmox.com \
--cc=d.csapak@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal