From: Fiona Ebner <f.ebner@proxmox.com>
To: pve-devel@lists.proxmox.com
Subject: [pve-devel] [PATCH qemu-server v3 stable-bookworm 7/8] api: vm start: introduce nets-host-mtu parameter for migration compat
Date: Thu, 4 Sep 2025 14:40:51 +0200 [thread overview]
Message-ID: <20250904124113.81772-8-f.ebner@proxmox.com> (raw)
In-Reply-To: <20250904124113.81772-1-f.ebner@proxmox.com>
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 <f.ebner@proxmox.com>
---
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
next prev parent reply other threads:[~2025-09-04 12:42 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-04 12:40 [pve-devel] [PATCH-SERIES qemu-server v3 0/8] virtio-net: fix migration between default/non-default MTUs Fiona Ebner
2025-09-04 12:40 ` [pve-devel] [PATCH qemu-server v3 1/8] virtio-net: fix migration between default/non-default MTUs starting with machine version 10.0+pve1 Fiona Ebner
2025-09-04 12:40 ` [pve-devel] [PATCH qemu-server v3 2/8] api: vm start: introduce nets-host-mtu parameter for migration compat Fiona Ebner
2025-09-04 12:40 ` [pve-devel] [PATCH qemu-server v3 3/8] migration: preserve host_mtu for virtio-net devices Fiona Ebner
2025-09-04 12:40 ` [pve-devel] [PATCH qemu-server v3 4/8] snapshot: save vmstate: avoid using deprecated check_running() function Fiona Ebner
2025-09-04 12:40 ` [pve-devel] [PATCH qemu-server v3 5/8] snapshot: save vmstate: die when PID cannot be obtained Fiona Ebner
2025-09-04 12:40 ` [pve-devel] [PATCH qemu-server v3 6/8] snapshot: introduce running-nets-host-mtu property Fiona Ebner
2025-09-04 12:40 ` Fiona Ebner [this message]
2025-09-04 12:40 ` [pve-devel] [PATCH qemu-server v3 stable-bookworm 8/8] migration: preserve host_mtu for virtio-net devices Fiona Ebner
2025-09-04 18:11 ` Thomas Lamprecht
2025-09-05 8:54 ` Fiona Ebner
2025-09-05 9:09 ` Thomas Lamprecht
2025-09-05 9:17 ` Fiona Ebner
2025-09-04 13:06 ` [pve-devel] [PATCH-SERIES qemu-server v3 0/8] virtio-net: fix migration between default/non-default MTUs Fabian Grünbichler
2025-09-04 18:16 ` [pve-devel] applied: " Thomas Lamprecht
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=20250904124113.81772-8-f.ebner@proxmox.com \
--to=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox