Migration MTU Problems with fixed MTU 1500 with machine version <10.1

fstrankowski

fstrankowski

Famous Member
Proxmox Subscriber
Nov 28, 2016
408
182
108
Hamburg
uniquoo.com
I recently came across the following warning while migrating a few VMs within our cluster.

Code: 
netdev net0: not adding 'host_mtu' parameter for migration compat
WARN: netdev net0: ignoring MTU '1500', not used on the source side according to migration parameters
/dev/rbd1
migration listens on unix:/run/qemu-server/3006.migrate

TASK WARNINGS: 1

Upon reviewing qemu-server.pm in combination with this commit it came to my attention that this warning is yield when the following parameters are met:
  • VM with VirtIO networking driver
  • $migration_skip_host_mtu is true which is $nets_host_mtu->{$netname}
This happens if a VM with defined MTU of 1500 is migrated - with a running machine version < 10.1.

E.g.:

Code: 
pvesh get nodes/HOST-NAME-123/qemu/4010/status/current

┌────────────────────┬─────────────────────────────────┐
│ key                │ value                           │
╞════════════════════╪═════════════════════════════════╡
│[...]
├────────────────────┼─────────────────────────────────┤
│ running-machine    │ pc-q35-9.1+pve0                 │
├────────────────────┼─────────────────────────────────┤
│[...]

It seems that net0=0 is wrongly assumed when an MTU of 1500 is set.
Any ideas?
 
Last edited:
Hi,
this is expected. If the machine was originally started with an older qemu-server version, the mtu parameter was not actually set on the commandline configuration for the vNIC if it matched the default 1500. QEMU needs to be started with the very same commandline configuration on the source and target node for a migration to work, because only then the device state can be preserved exactly. The message tells you that it's also not setting the mtu parameter for vNIC for the new instance to ensure migration compatibility.
 
  • Like
Reactions: shanreich
Appreciate fiona but could you please explain the following scenario: While in the cluster the qemu-server is the same version on every node. Means that no matter of the machine-version the commandline config and parameters should still be the same, no matter of node A or node B. Otherwise this warning should yield even when starting on a node without migrating the VM. The cmdline behaviour wont change during migration, right? On both sides the mtu parameter wont be passed to cmdline if machine-version < 10.1.

Our "workaround" now is to move all VMs to the current 10.1 machine version. Is that the correct approach to circumvent that notification?
 
Last edited:
Your workaround (moving VMs to machine version 10.1) is the correct approach.

To answer your follow-up: the warning appears even with the same qemu-server on both nodes because the target doesn't just regenerate the QEMU command line from config — it's constrained to replicate the exact state of the running source QEMU process.

Before machine version 10.0+pve1, host_mtu was only added to the command line when the MTU differed from the default 1500. So your VMs were started without host_mtu in their QEMU command line at all. During live migration, qemu-server queries the live source QEMU via QMP to find out what host_mtu value is actually active. For these older-started VMs it gets back 0 — meaning "not set". That value is forwarded to the target node, which then also omits host_mtu to ensure the QEMU device model state is identical on both sides. That's what triggers the warning.

The warning itself is harmless — the migration completes correctly. It's the compat mechanism working as intended, just with a message that could be clearer about what it means.

There are two ways to resolve this:
  1. Upgrade the machine version (your current approach) — after a stop/start with machine version ≥ 10.0+pve1 (or 10.1), host_mtu=1500 is always included in the QEMU command line. Future migrations will see 1500 via QMP and pass it through normally.
  2. Remove the explicit mtu=1500 from the VM config — the warning only fires when mtu is explicitly set in the VM config and the source QEMU reports it as absent. If mtu is not set at all (relying on the bridge default), there's nothing to warn about. This suppresses the warning without a stop/start cycle, though the machine version stays old. Only do this if 1500 really is your intended MTU and you're happy leaving the machine version as-is.
For most cases the machine version upgrade is the cleaner fix — it also brings the hardware emulation improvements that came with 10.1.
 
Bullshit AI answer. Not that i could have gotten that myself. Absolutely waste of forum resources. Reported. All your other posts are pure AI slop aswell.
 
Last edited:
It seems like an LLM-assisted answer, but it is mostly correct. I'm pretty sure it was not just dumped directly, but @tchaikov actually looked over it.
tchaikov said:
To answer your follow-up: the warning appears even with the same qemu-server on both nodes because the target doesn't just regenerate the QEMU command line from config — it's constrained to replicate the exact state of the running source QEMU process.
Click to expand...
This is not true in general. For almost everything, the configuration is used, which is why you must not manually modify it. Only certain properties are queried from the currently running state. The mtu setting for vNICs is one of those properties.
tchaikov said:
Before machine version 10.0+pve1, host_mtu was only added to the command line when the MTU differed from the default 1500. So your VMs were started without host_mtu in their QEMU command line at all. During live migration, qemu-server queries the live source QEMU via QMP to find out what host_mtu value is actually active. For these older-started VMs it gets back 0 — meaning "not set". That value is forwarded to the target node, which then also omits host_mtu to ensure the QEMU device model state is identical on both sides. That's what triggers the warning.
Click to expand...
Correct.
tchaikov said:
The warning itself is harmless — the migration completes correctly. It's the compat mechanism working as intended, just with a message that could be clearer about what it means.
Click to expand...
Yes, I also wonder if we should even keep it as a warning. I'll try to reformulate it a bit and maybe just have it be a normal print, rather than a warning.
 
  • Like
Reactions: Johannes S
Thanks! IMHO the notice could be supressed because in the end the MTU of 1500 is kept either way. Appreciate your help!
 
Last edited:
  • Like
Reactions: Johannes S
You must log in or register to reply here.
Top Bottom
Back