Bug 733416 - netfront MTU drops to 1500 after domain migration
Summary: netfront MTU drops to 1500 after domain migration
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel-xen
Version: 5.6
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Paolo Bonzini
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On: 697021 720347
Blocks: 514489 738392
TreeView+ depends on / blocked
 
Reported: 2011-08-25 16:27 UTC by Paolo Bonzini
Modified: 2013-01-11 04:02 UTC (History)
13 users (show)

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.
Clone Of: 697021
: 733651 (view as bug list)
Environment:
Last Closed: 2012-02-21 03:53:40 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2012:0150 normal SHIPPED_LIVE Moderate: Red Hat Enterprise Linux 5.8 kernel update 2012-02-21 07:35:24 UTC

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 Product and 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


Note You need to log in before you can comment on or make changes to this bug.