all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: Filip Schauer <f.schauer@proxmox.com>
To: Fiona Ebner <f.ebner@proxmox.com>,
	Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH qemu-server] Properly identify the CPU architecture of 32-bit VMs
Date: Tue, 12 Dec 2023 11:39:37 +0100	[thread overview]
Message-ID: <544700e6-14ca-4db8-88b4-117202a972d9@proxmox.com> (raw)
In-Reply-To: <474c3df6-a8ed-4294-8e46-37c3f2008689@proxmox.com>

It's actually not a different binary. qemu-system-i386 is a symlink that
points to qemu-system-x86_64. But still this does indeed break migration
between a node that has this patch applied and another node without the
patch.

A patch v2 that only adds the check is available here:
https://lists.proxmox.com/pipermail/pve-devel/2023-December/061034.html

On 11/12/2023 15:37, Fiona Ebner wrote:
> Am 11.12.23 um 15:12 schrieb Filip Schauer:
>> @@ -3293,11 +3293,12 @@ sub is_native($) {
>>   
>>   sub get_vm_arch {
>>       my ($conf) = @_;
>> -    return $conf->{arch} // get_host_arch();
>> +    return $conf->{arch} // cpu_type_to_arch($conf->{cpu}) // get_host_arch();
>>   }
>>   
>>   my $default_machines = {
>>       x86_64 => 'pc',
>> +    i386 => 'pc',
>>       aarch64 => 'virt',
>>   };
>>   
>> @@ -3390,6 +3391,7 @@ sub get_ovmf_files($$$) {
>>   
>>   my $Arch2Qemu = {
>>       aarch64 => '/usr/bin/qemu-system-aarch64',
>> +    i386 => '/usr/bin/qemu-system-i386',
>>       x86_64 => '/usr/bin/qemu-system-x86_64',
> Am I understanding correctly that you would automatically pick a
> different binary depending on the CPU type? Does that actually work with
> KVM and/or live migration, i.e. source was started with
> qemu-system-x86_64 and now suddenly on the target with qemu-system-i386?
>
> And even if it does, I'd rather not add support for running machines
> with this binary. Especially if the only reason is to have this new
> check. Once the new binary is there, we'd need to support it (even if
> it's not prominently exposed).
>
> If there is no easy way to do the check otherwise, I'd rather wait until
> enough users complain and re-consider how to implement the check only then.




  reply	other threads:[~2023-12-12 10:40 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-11 14:12 Filip Schauer
2023-12-11 14:37 ` Fiona Ebner
2023-12-12 10:39   ` Filip Schauer [this message]
2023-12-12 11:48     ` Fiona Ebner
2023-12-13 17:31       ` Filip Schauer
2023-12-14  9:13         ` Fiona Ebner

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=544700e6-14ca-4db8-88b4-117202a972d9@proxmox.com \
    --to=f.schauer@proxmox.com \
    --cc=f.ebner@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