Dear Maintainer,
* What led up to the problem?
Tests on identical installs of Debian across multiple virtual servers showed some were running slower than others at file intensive operations. Ping tests ended up showing that virtuals which ran on hardware with a
07:00.0 Ethernet controller: NetXen Incorporated NX3031 Multifunction 1/10-Gigabit Server Adapter (rev 42)
Subsystem: Hewlett-Packard Company NC522SFP Dual Port 10GbE Server Adapter
Physical Slot: 1
Flags: bus master, fast devsel, latency 0, IRQ 35, IOMMU group 31
Memory at fbe00000 (64-bit, non-prefetchable) [size=2M]
Memory at f8000000 (64-bit, non-prefetchable) [size=32M]
Expansion ROM at f6000000 [virtual] [disabled] [size=64K]
Capabilities: [40] MSI-X: Enable+ Count=64 Masked-
Capabilities: [80] Power Management version 3
Capabilities: [a0] MSI: Enable- Count=1/32 Maskable- 64bit+
Capabilities: [c0] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number 59-69-46-61-6e-48-73-75
Kernel driver in use: netxen_nic
Kernel modules: netxen_nic
controller had the problem, but those running on Intel 10Gigabit fiber server adapters were fine.
All MTUs are configured to 9188 and display as that via ifconfig for all host and macvtap interfaces. The underlying fiber connections are also set to 9188.
bond0.nnnn: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9188
macvtap6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9188
bond0: flags=5187<UP,BROADCAST,RUNNING,MASTER,MULTICAST> mtu 9188
ens1f0: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST> mtu 9188
ens1f1: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST> mtu 9188
and the ifconfig in the virtual also shows an mtu of 9188
enp1s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9188
but pings fail above 4051
root@proxy2-d:~# ping -s 4051 -c 1 10.64.0.1
PING 10.64.0.1 (10.64.0.1) 4051(4079) bytes of data.
4059 bytes from 10.64.0.1: icmp_seq=1 ttl=64 time=0.359 ms
--- 10.64.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.359/0.359/0.359/0.000 ms
root@proxy2-d:~# ping -s 4052 -c 1 10.64.0.1
PING 10.64.0.1 (10.64.0.1) 4052(4080) bytes of data.
--- 10.64.0.1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
From the host, they succeed
root@vancouver-kvm:~# ping -s 9188 -c 1 10.64.0.1
PING 10.64.0.1 (10.64.0.1) 9188(9216) bytes of data.
9196 bytes from 10.64.0.1: icmp_seq=1 ttl=64 time=0.303 ms
--- 10.64.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.303/0.303/0.303/0.000 ms
Not sure what is going on, but virtuals running on the hosts using the card should be able to utilize the native MTU settings that the host can use.
I reported it here, because hosts running on Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01) work as expected, so it is card related, although it could be some interaction with qemu. All virtuals are
running virtio for their network stack on Macvtap or default virtual network NAT connections. The majority are Macvtap with one NAT connection for anything that needs to reach the native host.
I see the same characteristics whether there is a single virtual running on the host or multiple virtuals. All virtuals have multiple network connections, but doesn't seem to be a RAM expenditure issue.