public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Fiona Ebner <f.ebner@proxmox.com>
To: pve-devel@lists.proxmox.com
Subject: [pve-devel] [PATCH-SERIES qemu-server v3 0/8] virtio-net: fix migration between default/non-default MTUs
Date: Thu,  4 Sep 2025 14:40:44 +0200	[thread overview]
Message-ID: <20250904124113.81772-1-f.ebner@proxmox.com> (raw)

Changes in v3:
* add part three - snapshot handling
* backport full migration+start handling
* schema description: explicitly mention that a value of 0 means to
  not use host_mtu
* die when host_mtu > bridge MTU also upon migration and expand error
  message
* less bloaty code by always mentioning migrated host_mtu value
* move get_nets_host_mtu to network module for re-use with snapshots
* avoid overly long line in tests

Changes in v2:
* push make tidy change already to master
* add part two - migration
* move version_guard() call to outside of print_netdevice_full() call
* add comment about why host_mtu is always set in source code

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].

Always set the host_mtu parameter starting with machine version
10.0+pve1 to avoid this issue going forward. For snapshots, the
nets-host-mtu information is recorded in the snapshot config. When the
information is not present, this series keeps the behavior on Proxmox
VE 8 and Proxmox VE 9 as-is, i.e. loading a Proxmox VE 8 snapshot on
Proxmox VE 9 when the bridge MTU has a mismatch can still be
problematic. Loading snapshots made on the same major version works.
The VM start parameter already provides an escape hatch. We could also
think about doing a follow-up and automatically try to fallback to
Proxmox VE 8 default behavior when loading the snapshot fails (for
machine verison < 10.0+pve1).

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.

Add the necessary parameter for VM start and pass the values along for
migration to preserve the values going forward.

For Proxmox VE 8, the migration handling fixes are backported.

stable-bookworm

Fiona Ebner (2):
  api: vm start: introduce nets-host-mtu parameter for migration compat
  migration: preserve host_mtu for virtio-net devices


master:

Fiona Ebner (6):
  virtio-net: fix migration between default/non-default MTUs starting
    with machine version 10.0+pve1
  api: vm start: introduce nets-host-mtu parameter for migration compat
  migration: preserve host_mtu for virtio-net devices
  snapshot: save vmstate: avoid using deprecated check_running()
    function
  snapshot: save vmstate: die when PID cannot be obtained
  snapshot: introduce running-nets-host-mtu property

 src/PVE/API2/Qemu.pm                          | 13 ++++
 src/PVE/QemuConfig.pm                         | 13 ++--
 src/PVE/QemuMigrate.pm                        |  8 +++
 src/PVE/QemuServer.pm                         | 62 +++++++++++++++++--
 src/PVE/QemuServer/Machine.pm                 |  6 ++
 src/PVE/QemuServer/Network.pm                 | 29 +++++++++
 src/PVE/QemuServer/RunState.pm                |  3 +-
 src/test/MigrationTest/QemuMigrateMock.pm     | 15 +++++
 src/test/cfg2cmd/bootorder-empty.conf.cmd     |  4 +-
 src/test/cfg2cmd/bootorder-legacy.conf.cmd    |  4 +-
 src/test/cfg2cmd/bootorder.conf.cmd           |  4 +-
 src/test/cfg2cmd/efidisk-on-rbd.conf.cmd      |  4 +-
 src/test/cfg2cmd/ide.conf.cmd                 |  4 +-
 .../cfg2cmd/netdev-7.1-multiqueues.conf.cmd   |  2 +-
 src/test/cfg2cmd/netdev-7.1.conf.cmd          |  2 +-
 src/test/cfg2cmd/netdev_vxlan.conf.cmd        |  2 +-
 src/test/cfg2cmd/q35-ide.conf.cmd             |  4 +-
 .../q35-linux-hostpci-mapping.conf.cmd        |  4 +-
 .../q35-linux-hostpci-multifunction.conf.cmd  |  4 +-
 ...q35-linux-hostpci-x-pci-overrides.conf.cmd |  4 +-
 src/test/cfg2cmd/q35-linux-hostpci.conf.cmd   |  4 +-
 src/test/cfg2cmd/q35-simple.conf.cmd          |  4 +-
 src/test/cfg2cmd/seabios_serial.conf.cmd      |  4 +-
 src/test/cfg2cmd/simple-btrfs.conf.cmd        |  4 +-
 .../cfg2cmd/simple-disk-passthrough.conf.cmd  |  4 +-
 src/test/cfg2cmd/simple-rbd.conf.cmd          |  4 +-
 src/test/cfg2cmd/simple-virtio-blk.conf.cmd   |  4 +-
 .../cfg2cmd/simple-zfs-over-iscsi.conf.cmd    |  4 +-
 src/test/cfg2cmd/simple1.conf.cmd             |  4 +-
 29 files changed, 177 insertions(+), 50 deletions(-)

-- 
2.47.2



_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel


             reply	other threads:[~2025-09-04 12:41 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-04 12:40 Fiona Ebner [this message]
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 ` [pve-devel] [PATCH qemu-server v3 stable-bookworm 7/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 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-1-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
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal