[pve-devel] [PATCH docs/manager/qemu-server v2 0/3] Make VirtIO network devices always inherit MTU from bridge

[pve-devel] [PATCH docs/manager/qemu-server v2 0/3] Make VirtIO network devices always inherit MTU from bridge

[Stefan Hanreich]

The current default behavior for VirtIO network devices is to default to 1500
MTU, unless otherwise specified. This is inconvenient in cases where the MTU is
not the default value (e.g. for VXLAN VNets or bridges with jumbo frames).
Containers already inherit the MTU of the bridge, if not set, so change the
behavior of VMs to be more in line with containers. This also makes using
non-standard MTUs more convenient and less error-prone since users do not have
to remember setting the MTU everytime they configure a network device on such a
brige.

Changes from v1:
* better document this behavior
* show better hints in the UI
* improve test case

qemu-server:

Stefan Hanreich (1):
  net: pass host_mtu parameter when mtu is unset in netdev config

 PVE/QemuServer.pm                  | 30 ++++++++++++++++--------------
 test/cfg2cmd/netdev_vxlan.conf     |  7 +++++++
 test/cfg2cmd/netdev_vxlan.conf.cmd | 28 ++++++++++++++++++++++++++++
 test/run_config2command_tests.pl   |  6 ++++++
 4 files changed, 57 insertions(+), 14 deletions(-)
 create mode 100644 test/cfg2cmd/netdev_vxlan.conf
 create mode 100644 test/cfg2cmd/netdev_vxlan.conf.cmd


pve-manager:

Stefan Hanreich (1):
  qemu: network: adjust MTU emptyText to match new default behavior

 www/manager6/qemu/NetworkEdit.js | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


pve-docs:

Stefan Hanreich (1):
  qm: document new default behavior for mtu setting

 qm.adoc | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)


Summary over all repositories:
  6 files changed, 61 insertions(+), 19 deletions(-)

-- 
Generated by git-murpp 0.8.0

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

[pve-devel] [PATCH qemu-server v2 1/1] net: pass host_mtu parameter when mtu is unset in netdev config

[Stefan Hanreich]

When creating a new network device from the UI and leaving the MTU
field empty, it defaults to 1500. This is inconvenient in cases where
the MTU of the bridge is not 1500 and lead to some confusion of users
[1]. Containers already inherit the bridge MTU when the field is left
empty, so align the behavior of VMs to be more in line with the more
convenient behavior of containers.

The common case where this was encountered was with creating network
devices on SDN VXLAN vnets. There the default MTU for bridges is 1450,
since VXLAN adds some overhead and we automatically subtract that
overhead from the default bridge MTU (1500) if no MTU is explicitly
set in the zone configuration. Before that users always had to
explicitly set the MTU to 1450 or 1 for every network device created,
which is error-prone.

[1] https://forum.proxmox.com/threads/bug-vxlan-and-mtu.161412

Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
---
 PVE/QemuServer.pm                  | 30 ++++++++++++++++--------------
 test/cfg2cmd/netdev_vxlan.conf     |  7 +++++++
 test/cfg2cmd/netdev_vxlan.conf.cmd | 28 ++++++++++++++++++++++++++++
 test/run_config2command_tests.pl   |  6 ++++++
 4 files changed, 57 insertions(+), 14 deletions(-)
 create mode 100644 test/cfg2cmd/netdev_vxlan.conf
 create mode 100644 test/cfg2cmd/netdev_vxlan.conf.cmd

diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
index ccdceedc..ad1716d7 100644
--- a/PVE/QemuServer.pm
+++ b/PVE/QemuServer.pm
@@ -912,7 +912,7 @@ my $net_fmt = {
     mtu => {
 	type => 'integer',
 	minimum => 1, maximum => 65520,
-	description => "Force MTU, for VirtIO only. Set to '1' to use the bridge MTU",
+	description => "Force MTU, for VirtIO only. Setting to '1' or leaving it empty will use the bridge MTU.",
 	optional => 1,
     },
 };
@@ -1596,20 +1596,22 @@ sub print_netdevice_full {
 
     $tmpstr .= ",bootindex=$net->{bootindex}" if $net->{bootindex} ;
 
-    if (my $mtu = $net->{mtu}) {
-	if ($net->{model} eq 'virtio' && $net->{bridge}) {
-	    my $bridge_mtu = PVE::Network::read_bridge_mtu($net->{bridge});
-	    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";
-	    }
-	    $tmpstr .= ",host_mtu=$mtu";
-	} else {
-	    warn "WARN: netdev $netid: ignoring MTU '$mtu', not using VirtIO or no bridge configured.\n";
+    my $mtu = $net->{mtu};
+
+    if ($net->{model} eq 'virtio' && $net->{bridge}) {
+	my $bridge_mtu = PVE::Network::read_bridge_mtu($net->{bridge});
+
+	if (!defined($mtu) || $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";
 	}
+
+	$tmpstr .= ",host_mtu=$mtu" if $mtu != 1500;
+    } elsif (defined($mtu)) {
+	warn "WARN: netdev $netid: ignoring MTU '$mtu', not using VirtIO or no bridge configured.\n";
     }
 
     if ($use_old_bios_files) {
diff --git a/test/cfg2cmd/netdev_vxlan.conf b/test/cfg2cmd/netdev_vxlan.conf
new file mode 100644
index 00000000..af9e31c7
--- /dev/null
+++ b/test/cfg2cmd/netdev_vxlan.conf
@@ -0,0 +1,7 @@
+# TEST: Test inheriting the MTU from a bridge with MTU != 1500
+bootdisk: scsi0
+cores: 3
+memory: 768
+name: netdev
+net0: virtio=A2:C0:43:77:08:A0,bridge=vxlan_bridge
+ostype: l26
diff --git a/test/cfg2cmd/netdev_vxlan.conf.cmd b/test/cfg2cmd/netdev_vxlan.conf.cmd
new file mode 100644
index 00000000..7de574a7
--- /dev/null
+++ b/test/cfg2cmd/netdev_vxlan.conf.cmd
@@ -0,0 +1,28 @@
+/usr/bin/kvm \
+  -id 8006 \
+  -name 'netdev,debug-threads=on' \
+  -no-shutdown \
+  -chardev 'socket,id=qmp,path=/var/run/qemu-server/8006.qmp,server=on,wait=off' \
+  -mon 'chardev=qmp,mode=control' \
+  -chardev 'socket,id=qmp-event,path=/var/run/qmeventd.sock,reconnect-ms=5000' \
+  -mon 'chardev=qmp-event,mode=control' \
+  -pidfile /var/run/qemu-server/8006.pid \
+  -daemonize \
+  -smp '3,sockets=1,cores=3,maxcpus=3' \
+  -nodefaults \
+  -boot 'menu=on,strict=on,reboot-timeout=1000,splash=/usr/share/qemu-server/bootsplash.jpg' \
+  -vnc 'unix:/var/run/qemu-server/8006.vnc,password=on' \
+  -cpu kvm64,enforce,+kvm_pv_eoi,+kvm_pv_unhalt,+lahf_lm,+sep \
+  -m 768 \
+  -global 'PIIX4_PM.disable_s3=1' \
+  -global 'PIIX4_PM.disable_s4=1' \
+  -device 'pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1e' \
+  -device 'pci-bridge,id=pci.2,chassis_nr=2,bus=pci.0,addr=0x1f' \
+  -device 'piix3-usb-uhci,id=uhci,bus=pci.0,addr=0x1.0x2' \
+  -device 'usb-tablet,id=tablet,bus=uhci.0,port=1' \
+  -device 'VGA,id=vga,bus=pci.0,addr=0x2' \
+  -device 'virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3,free-page-reporting=on' \
+  -iscsi 'initiator-name=iqn.1993-08.org.debian:01:aabbccddeeff' \
+  -netdev 'type=tap,id=net0,ifname=tap8006i0,script=/usr/libexec/qemu-server/pve-bridge,downscript=/usr/libexec/qemu-server/pve-bridgedown,vhost=on' \
+  -device 'virtio-net-pci,mac=A2:C0:43:77:08:A0,netdev=net0,bus=pci.0,addr=0x12,id=net0,rx_queue_size=1024,tx_queue_size=256,bootindex=300,host_mtu=1450' \
+  -machine 'type=pc+pve1'
diff --git a/test/run_config2command_tests.pl b/test/run_config2command_tests.pl
index 209122c2..c2dfbd31 100755
--- a/test/run_config2command_tests.pl
+++ b/test/run_config2command_tests.pl
@@ -316,6 +316,12 @@ my $pve_common_network;
 $pve_common_network = Test::MockModule->new('PVE::Network');
 $pve_common_network->mock(
     read_bridge_mtu => sub {
+	my ($bridge_name) = @_;
+
+	if ($bridge_name eq 'vxlan_bridge') {
+	    return 1450;
+	}
+
 	return 1500;
     },
 );
-- 
2.39.5


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

[pve-devel] [PATCH pve-manager v2 1/1] qemu: network: adjust MTU emptyText to match new default behavior

[Stefan Hanreich]

Leaving the MTU field unset now defaults to the bridge MTU, rather
than 1500. Reflect this change by indicating the new behavior in the
emptyText of the MTU field. While we're at it, add a gettext call so
it can be translated. I've taken the same text as from the container
dialogue, so it should already use existing translations.

Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
---
 www/manager6/qemu/NetworkEdit.js | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/www/manager6/qemu/NetworkEdit.js b/www/manager6/qemu/NetworkEdit.js
index 4917eba5f..5e7ed22d1 100644
--- a/www/manager6/qemu/NetworkEdit.js
+++ b/www/manager6/qemu/NetworkEdit.js
@@ -113,7 +113,7 @@ Ext.define('PVE.qemu.NetworkInputPanel', {
 		    disabled: '{!isVirtio}',
 		    value: '{mtu}',
 		},
-		emptyText: '1500 (1 = bridge MTU)',
+		emptyText: gettext('Same as bridge'),
 		minValue: 1,
 		maxValue: 65520,
 		allowBlank: true,
-- 
2.39.5


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

[pve-devel] [PATCH pve-docs v2 1/1] qm: document new default behavior for mtu setting

[Stefan Hanreich]

The default behavior changed from setting 1500 MTU to inheriting the
bridge MTU, if the MTU key for network devices is unset.

Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
---
 qm.adoc | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/qm.adoc b/qm.adoc
index 44e2436..29cb26c 100644
--- a/qm.adoc
+++ b/qm.adoc
@@ -924,10 +924,9 @@ but not via the web UI.
 You can also skip adding a network device when creating a VM by selecting *No
 network device*.
 
-You can overwrite the *MTU* setting for each VM network device. The option
-`mtu=1` represents a special case, in which the MTU value will be inherited
-from the underlying bridge.
-This option is only available for *VirtIO* network devices.
+You can overwrite the *MTU* setting for each VM network device manually. Leaving
+the field empty or setting `mtu=1` will inherit the MTU from the underlying
+bridge. This option is only available for *VirtIO* network devices.
 
 .Multiqueue
 If you are using the VirtIO driver, you can optionally activate the
-- 
2.39.5


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

Re: [pve-devel] [PATCH docs/manager/qemu-server v2 0/3] Make VirtIO network devices always inherit MTU from bridge

[Thomas Lamprecht]

Am 17.04.25 um 12:48 schrieb Stefan Hanreich:
> The current default behavior for VirtIO network devices is to default to 1500
> MTU, unless otherwise specified. This is inconvenient in cases where the MTU is
> not the default value (e.g. for VXLAN VNets or bridges with jumbo frames).
> Containers already inherit the MTU of the bridge, if not set, so change the
> behavior of VMs to be more in line with containers. This also makes using
> non-standard MTUs more convenient and less error-prone since users do not have
> to remember setting the MTU everytime they configure a network device on such a
> brige.

Hmm, does this have regression potential for bridges with a too high MTU?
I.e., one where the MTU works for LAN but not for anything going beyond that,
which is odd but can be working fine I think? At least as long as no host and
no CT uses this bridge for communicating with endpoints outside the LAN.

FWIW, we could also tie this behavior to a machine version to avoid changing
the behavior for any existing VM. But I would be fine with applying this only
for PVE 9 then and add a notice to the pve8to9 checker script that lists all
VMs that will change their MTU including the respective value.


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

Re: [pve-devel] [PATCH docs/manager/qemu-server v2 0/3] Make VirtIO network devices always inherit MTU from bridge

[Stefan Hanreich]

On 4/18/25 09:46, Thomas Lamprecht wrote:
> Am 17.04.25 um 12:48 schrieb Stefan Hanreich:
>> The current default behavior for VirtIO network devices is to default to 1500
>> MTU, unless otherwise specified. This is inconvenient in cases where the MTU is
>> not the default value (e.g. for VXLAN VNets or bridges with jumbo frames).
>> Containers already inherit the MTU of the bridge, if not set, so change the
>> behavior of VMs to be more in line with containers. This also makes using
>> non-standard MTUs more convenient and less error-prone since users do not have
>> to remember setting the MTU everytime they configure a network device on such a
>> brige.
> 
> Hmm, does this have regression potential for bridges with a too high MTU?
> I.e., one where the MTU works for LAN but not for anything going beyond that,
> which is odd but can be working fine I think? At least as long as no host and
> no CT uses this bridge for communicating with endpoints outside the LAN.

In that case, traffic going outside the LAN has to go through a router,
which has to handle routing between networks with different MTU. Either
by fragmenting packets or dropping them and sending an ICMP
'fragmentation needed'. Of course that setup is far from optimal, but it
should work. Not 100% sure if that is what you meant, correct me if I
misunderstood something.


With this patch we're setting the MTU of the NIC to the MTU that is set
on the bridge already, so the bridge would have already dropped packets
that are too large.

If the MTU of the bridge was larger than 1500, but the NIC was set to
1500, then the VM was just sending packets that are too small, but the
setup would work, assuming the bridge MTU is the correct one for the
network.

A possible regression I can think of is: If the bridge was set to the
wrong MTU (e.g. 9000) at some point, but external devices in the same
LAN are still set to use a lower MTU (e.g. 1500). If users never
configured the larger MTU anywhere else besides the bridge, then this
would break.

If the MTU of the bridge was smaller than 1500, but the NIC is set to
1500 (which is the case with SDN VXLAN bridges), then this would be
discovered quite quickly in most cases since network packets would get
dropped. This change would fix such existing broken setups.


> FWIW, we could also tie this behavior to a machine version to avoid changing
> the behavior for any existing VM. But I would be fine with applying this only
> for PVE 9 then and add a notice to the pve8to9 checker script that lists all
> VMs that will change their MTU including the respective value.

I think it would be a good idea to include this in pve8to9 with warnings
at least and mention it in the release notes. It might make for some
noise and unsettle some users though. Since we cannot really tell what
MTU is set inside the VM, we'd have to show warnings for basically every
 network device on a bridge with MTU != 1500.

Would also be open to tie this to a new machine version if we want to be
really careful and avoid the unnecessary warnings.


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

Re: [pve-devel] [PATCH docs/manager/qemu-server v2 0/3] Make VirtIO network devices always inherit MTU from bridge

[Thomas Lamprecht]

Am 22.04.25 um 13:33 schrieb Stefan Hanreich:
> If the MTU of the bridge was larger than 1500, but the NIC was set to
> 1500, then the VM was just sending packets that are too small, but the
> setup would work, assuming the bridge MTU is the correct one for the
> network.
> 
> A possible regression I can think of is: If the bridge was set to the
> wrong MTU (e.g. 9000) at some point, but external devices in the same
> LAN are still set to use a lower MTU (e.g. 1500). If users never
> configured the larger MTU anywhere else besides the bridge, then this
> would break.

Above is basically what I meant.

>> FWIW, we could also tie this behavior to a machine version to avoid changing
>> the behavior for any existing VM. But I would be fine with applying this only
>> for PVE 9 then and add a notice to the pve8to9 checker script that lists all
>> VMs that will change their MTU including the respective value.
> 
> I think it would be a good idea to include this in pve8to9 with warnings
> at least and mention it in the release notes. It might make for some
> noise and unsettle some users though. Since we cannot really tell what
> MTU is set inside the VM, we'd have to show warnings for basically every
>  network device on a bridge with MTU != 1500.

Well, yes, but I used "notice" over "warning" for a reason, as we have
that level in the checker script, and it fits this change well IMO.

> Would also be open to tie this to a new machine version if we want to be
> really careful and avoid the unnecessary warnings.

After rethinking this it's IMO not worth it.


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

Re: [pve-devel] [PATCH docs/manager/qemu-server v2 0/3] Make VirtIO network devices always inherit MTU from bridge

[Stefan Hanreich]

On 4/22/25 16:48, Thomas Lamprecht wrote:
> Am 22.04.25 um 13:33 schrieb Stefan Hanreich:
>> A possible regression I can think of is: If the bridge was set to the
>> wrong MTU (e.g. 9000) at some point, but external devices in the same
>> LAN are still set to use a lower MTU (e.g. 1500). If users never
>> configured the larger MTU anywhere else besides the bridge, then this
>> would break.
> 
> Above is basically what I meant.

For that case I think just the notice in the check script is sufficient.
IMO this should be rather rare in practice.

But, thinking more about potential regressions / issues:

I'll double-check this series w.r.t the bridge inheriting MTU from
bridge ports just to make sure we won't run into any funky business
there. IIRC there is some unintuitive behavior on how the MTU on bridges
gets set, when adding ports with mismatched MTU. I'll try to torture
test this a bit more this or next week.


>>> FWIW, we could also tie this behavior to a machine version to avoid changing
>>> the behavior for any existing VM. But I would be fine with applying this only
>>> for PVE 9 then and add a notice to the pve8to9 checker script that lists all
>>> VMs that will change their MTU including the respective value.
>>
>> I think it would be a good idea to include this in pve8to9 with warnings
>> at least and mention it in the release notes. It might make for some
>> noise and unsettle some users though. Since we cannot really tell what
>> MTU is set inside the VM, we'd have to show warnings for basically every
>>  network device on a bridge with MTU != 1500.
> 
> Well, yes, but I used "notice" over "warning" for a reason, as we have
> that level in the checker script, and it fits this change well IMO.

I agree. Fits better than warning since it will usually work just fine.
I'll send a new version with an additional patch for pve8to9 as soon as
that's available in pve-manager.


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