Bug 733416

Summary: netfront MTU drops to 1500 after domain migration
Product: Red Hat Enterprise Linux 5 Reporter: Paolo Bonzini <pbonzini>
Component: kernel-xenAssignee: Paolo Bonzini <pbonzini>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: high Docs Contact:
Priority: high    
Version: 5.6CC: dhoward, drjones, jzheng, leiwang, lersek, mrezanin, pasik, pbonzini, plyons, qguan, qwan, xen-maint, yuzhang
Target Milestone: rcKeywords: ZStream
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: kernel-2.6.18-284.el5 Doc Type: Bug Fix
Doc Text:
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.
Story Points: ---
Clone Of: 697021
: 733651 (view as bug list) Environment:
Last Closed: 2012-02-21 03:53:40 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 697021, 720347    
Bug Blocks: 514489, 738392    

Description Paolo Bonzini 2011-08-25 16:27:01 UTC
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
DEVICE=eth0
HWADDR=00:21:5E:6E:F0:29
ONBOOT=yes
HOTPLUG=no
IPADDR=169.254.100.200
NETMASK=255.255.0.0
NETWORK=169.254.0.0
MTU=9000

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

sleep 5
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

Comment 1 RHEL Program Management 2011-08-26 08:49:40 UTC
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
release.

Comment 3 Paolo Bonzini 2011-08-31 08:38:16 UTC
> - 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
> 
> 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.

Comment 5 Jarod Wilson 2011-09-02 15:41:48 UTC
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.

Comment 6 Jarod Wilson 2011-09-02 17:43:30 UTC
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.

Comment 10 Martin Prpič 2011-10-27 09:26:20 UTC
    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.
    
    New Contents:
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.

Comment 11 Qixiang Wan 2011-11-15 08:47:52 UTC
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.

Comment 12 Qixiang Wan 2011-11-15 08:57:43 UTC
(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
> VERIFIED.

Xen userspace is xen-3.0.3-135.el5 which has the userspace fix (bug 733417) included.

Comment 13 errata-xmlrpc 2012-02-21 03:53:40 UTC
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.

http://rhn.redhat.com/errata/RHSA-2012-0150.html