Xen drops the MTU of a guest's netfront interface to 1500 after migration.
For now I'm attaching the bug to kernel-xen, but I am still not really sure whether this is the right component.
Test info for QE:
- connect two machines with a crossover cable so that eth0 is the crossover cable and eth1 is the public network
- configure Xen so that you'll be able to migrate between the machines (shared storage, relocation server, etc.)
- configure the cross link on one machine like
# Intel Corporation 82574L Gigabit Network Connection
and similarly on the other machine
- on both machines, ensure the Xen bridge connects the right devices, for example by changing the network-script line in /etc/xen/xend-config.sxp to this:
(network-script 'network-bridge netdev=eth0 bridge=xenbr0')
- on both machines, ensure the Xen bridge has its MTU set to 9000, for example by adding this (huge hack) to /etc/init.d/xend at the end of function await_daemons_up
ip link set mtu 9000 dev vif0.1
ip link set mtu 9000 dev peth0
ip link set mtu 9000 dev xenbr0
- install a guest in one of the machines. ensure the guest has also a static IP configuration in the same subnet, and also has MTU=9000 in its /etc/sysconfig/network-scripts/ifcfg-eth0. Also, ensure that the guest is using xenbr0 and not virbr0.
- run ifconfig around "xm create"
ifconfig > before
xm create test1
# wait a few seconds
ifconfig | diff before -
The diff should show that the new vif interface has MTU=9000. Similarly, "ifconfig" in the guest should show MTU=9000.
- ensure that you can ping the guest from both hosts.
- migrate the guest from one host to the other. before migrating, run
ifconfig > before
on the guest and *destination* host and after migration run
ifconfig | diff before -
For both the guest and the destination host, the diff should show that the virtual network interface (vifN.0 on the host, eth0 on the guest) has MTU=9000.
- ensure that you can ping the guest from both hosts
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
> - on both machines, ensure the Xen bridge has its MTU set to 9000, for example
> by adding this (huge hack) to /etc/init.d/xend at the end of function
> sleep 5
> ip link set mtu 9000 dev vif0.1
> ip link set mtu 9000 dev peth0
> ip link set mtu 9000 dev xenbr0
This is not necessary if you have the patch for bug 733417.
Patch(es) available in kernel-2.6.18-284.el5
You can download this test kernel (or newer) from http://people.redhat.com/jwilson/el5
Detailed testing feedback is always welcomed.
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
This update introduces support for jumbo frames in the Xen networking backend. However, old guests will still revert to a 1500-byte MTU after migration. This update also changes how the guest will probe the backend's Scatter/Gather I/O functionality. As long as a recent enough kernel is installed in the destination host, this will ensure that the guest will keep a large MTU even after migration.
Tested with the same steps as bug 738608 comment 6, host is kernel-xen-2.6.18-297.el5 x86_64. Guest is RHEL5.8 20111030.0 i386 and x86_64 PV DomU (kernel-xen-2.6.18-294.el5), the netfront device keeps the MTU=9000 configuration after guest migration, so the fix works well. Change this bug to VERIFIED.
(In reply to comment #11)
> Tested with the same steps as bug 738608 comment 6, host is
> kernel-xen-2.6.18-297.el5 x86_64. Guest is RHEL5.8 20111030.0 i386 and x86_64
> PV DomU (kernel-xen-2.6.18-294.el5), the netfront device keeps the MTU=9000
> configuration after guest migration, so the fix works well. Change this bug to
Xen userspace is xen-3.0.3-135.el5 which has the userspace fix (bug 733417) included.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.