From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 1E5101FF189 for ; Thu, 4 Sep 2025 14:42:11 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 4D1712EB4D; Thu, 4 Sep 2025 14:41:57 +0200 (CEST) From: Fiona Ebner To: pve-devel@lists.proxmox.com Date: Thu, 4 Sep 2025 14:40:51 +0200 Message-ID: <20250904124113.81772-8-f.ebner@proxmox.com> X-Mailer: git-send-email 2.47.2 In-Reply-To: <20250904124113.81772-1-f.ebner@proxmox.com> References: <20250904124113.81772-1-f.ebner@proxmox.com> MIME-Version: 1.0 X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1756989664317 X-SPAM-LEVEL: Spam detection results: 0 AWL -0.023 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 SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: [pve-devel] [PATCH qemu-server v3 stable-bookworm 7/8] api: vm start: introduce nets-host-mtu parameter for migration compat X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox VE development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" The virtual hardware is generated differently (at least for i440fx machines) when host_mtu is set or not set on the netdev command line [0]. When the MTU is the same value as the default 1500, Proxmox VE did not add a host_mtu parameter. This is problematic for migration where host_mtu is present on one end of the migration, but not on the other [1]. Moreover, the effective setting in the guest (state) will still be the host_mtu from the source side, even if a different value is used for host_mtu on the target instance's commandline. This will not lead to an error loading the migration stream in QEMU, but having a larger host_mtu than the bridge MTU is still problematic for certain network traffic like > iperf3 -c 10.10.10.11 -u -l 2k when host_mtu=9000 and bridge MTU=1500. Starting a VM cold with such a configuration is already prohibited, so also prevent it for migration. Add the necessary parameter for VM start to allow preserving the values going forward. [0]: https://bugzilla.redhat.com/show_bug.cgi?id=1449346 [1]: https://forum.proxmox.com/threads/live-vm-migration-fails.169537/post-796379 Signed-off-by: Fiona Ebner --- New in v3. src/PVE/API2/Qemu.pm | 12 ++++++++++ src/PVE/QemuServer.pm | 54 ++++++++++++++++++++++++++++++++++++++----- 2 files changed, 60 insertions(+), 6 deletions(-) diff --git a/src/PVE/API2/Qemu.pm b/src/PVE/API2/Qemu.pm index ce6f362d..9d026bc5 100644 --- a/src/PVE/API2/Qemu.pm +++ b/src/PVE/API2/Qemu.pm @@ -3364,6 +3364,16 @@ __PACKAGE__->register_method({ default => 'max(30, vm memory in GiB)', optional => 1, }, + 'nets-host-mtu' => { + type => 'string', + pattern => 'net\d+=\d+(,net\d+=\d+)*', + optional => 1, + description => + 'Used for migration compat. List of VirtIO network devices and their effective' + . ' host_mtu setting according to the QEMU object model on the source side of' + . ' the migration. A value of 0 means that the host_mtu parameter is to be' + . ' avoided for the corresponding device.', + }, }, }, returns => { @@ -3394,6 +3404,7 @@ __PACKAGE__->register_method({ my $migration_network = $get_root_param->('migration_network'); my $targetstorage = $get_root_param->('targetstorage'); my $force_cpu = $get_root_param->('force-cpu'); + my $nets_host_mtu = $get_root_param->('nets-host-mtu'); my $storagemap; @@ -3480,6 +3491,7 @@ __PACKAGE__->register_method({ forcemachine => $machine, timeout => $timeout, forcecpu => $force_cpu, + 'nets-host-mtu' => $nets_host_mtu, }; PVE::QemuServer::vm_start($storecfg, $vmid, $params, $migrate_opts); diff --git a/src/PVE/QemuServer.pm b/src/PVE/QemuServer.pm index 0f46b396..47c96726 100644 --- a/src/PVE/QemuServer.pm +++ b/src/PVE/QemuServer.pm @@ -1647,7 +1647,17 @@ sub print_pbs_blockdev { } sub print_netdevice_full { - my ($vmid, $conf, $net, $netid, $bridges, $use_old_bios_files, $arch, $machine_version) = @_; + my ( + $vmid, + $conf, + $net, + $netid, + $bridges, + $use_old_bios_files, + $arch, + $machine_version, + $host_mtu_migration, # force this value for host_mtu, 0 means force absence of param + ) = @_; my $device = $net->{model}; if ($net->{model} eq 'virtio') { @@ -1673,19 +1683,37 @@ sub print_netdevice_full { $tmpstr .= ",bootindex=$net->{bootindex}" if $net->{bootindex}; if (my $mtu = $net->{mtu}) { - if ($net->{model} eq 'virtio' && $net->{bridge}) { + my $migration_skip_host_mtu = defined($host_mtu_migration) && $host_mtu_migration == 0; + print "netdev $netid: not adding 'host_mtu' parameter for migration compat\n" + if $migration_skip_host_mtu; + + if ($net->{model} eq 'virtio' && $net->{bridge} && !$migration_skip_host_mtu) { my $bridge_mtu = PVE::Network::read_bridge_mtu($net->{bridge}); + + if ($host_mtu_migration) { + print "netdev $netid: using 'host_mtu=$host_mtu_migration' for migration compat\n"; + $mtu = $host_mtu_migration; + } + if ($mtu == 1) { $mtu = $bridge_mtu; } elsif ($mtu < 576) { die "netdev $netid: MTU '$mtu' is smaller than the IP minimum MTU '576'\n"; } elsif ($mtu > $bridge_mtu) { - die "netdev $netid: MTU '$mtu' is bigger than the bridge MTU '$bridge_mtu'\n"; + die "netdev $netid: MTU '$mtu' is bigger than the bridge MTU '$bridge_mtu'" + . " - adjust the MTU for the network device in the VM configuration, while ensuring" + . " that the bridge is configured as desired.\n"; } $tmpstr .= ",host_mtu=$mtu"; } else { - warn - "WARN: netdev $netid: ignoring MTU '$mtu', not using VirtIO or no bridge configured.\n"; + my $msg_prefix = "netdev $netid: ignoring MTU '$mtu'"; + if ($migration_skip_host_mtu) { + log_warn("$msg_prefix, not used on the source side according to migration parameters"); + } elsif (!$net->{bridge}) { + log_warn("$msg_prefix, no bridge configured"); + } else { + log_warn("$msg_prefix, not using VirtIO"); + } } } @@ -3557,7 +3585,16 @@ my sub get_vga_properties { } sub config_to_command { - my ($storecfg, $vmid, $conf, $defaults, $forcemachine, $forcecpu, $live_restore_backing) = @_; + my ( + $storecfg, + $vmid, + $conf, + $defaults, + $forcemachine, + $forcecpu, + $live_restore_backing, + $nets_host_mtu, + ) = @_; # minimize config for templates, they can only start for backup, # so most options besides the disks are irrelevant @@ -4127,6 +4164,7 @@ sub config_to_command { }, ); + my $nets_host_mtu_hash = { map { split('=', $_) } PVE::Tools::split_list($nets_host_mtu) }; for (my $i = 0; $i < $MAX_NETS; $i++) { my $netname = "net$i"; @@ -4151,6 +4189,7 @@ sub config_to_command { $use_old_bios_files, $arch, $machine_version, + $nets_host_mtu_hash->{$netname}, ); push @$devices, '-device', $netdevicefull; @@ -5929,6 +5968,8 @@ sub vm_start { # }, # virtio2 => ... # } +# nets-host-mtu => Used for migration compat. List of VirtIO network devices and their effective +# host_mtu setting according to the QEMU object model on the source side of the migration. # migrate_opts: # nbd => volumes for NBD exports (vm_migrate_alloc_nbd_disks) # migratedfrom => source node @@ -6008,6 +6049,7 @@ sub vm_start_nolock { $forcemachine, $forcecpu, $params->{'live-restore-backing'}, + $params->{'nets-host-mtu'}, ); my $migration_ip; -- 2.39.5 _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel