With Xen dom0 physical, bridge and vif interface all set to 9000-byte MTUs, I expect to be able to set the domU eth0 MTU to 9000-bytes and enjoy a happy jumbo-frame life. This works on the old-style Xen kernels (CentOS 5.2 and Fedora 8). I don't know about F9, but the pv_ops unified F10 kernel will work if I configure the MTU on eth0 <= 4064 bytes, but at >= 4065 bytes large packets seem to be silently dropped somewhere. "yum clean all; yum upgrade" just stiffs until I lower the MTU. Only tried on x86_64.
F9 has the same problem.
I noticed that the number changed from 4064 to 4048 (another 32 bytes below 4K), on a domU kernel upgrade / xen dom0 upgrade and it looks like the problem is dom0-specific rather than domU-specific. It's 4064 bytes for dom0 2.6.18-92.1.18.el5xen / xen-3.0.3-73. It's 4048 bytes for dom0 2.6.18-92.1.22.el5xen / xen-3.0.3-80.el5. Both are CentOS 5.2 kernels (5.3 crashes, but that's a different issue, I think); the first xen is a backport from RHEL5.3 beta, the second xen a plain CentOS 5.3. So, I don't know if this is a hypervisor kernel or Xen bug (or neither, given it only appears to affect pv_ops domU kernels), so I thought I'd change the component to Xen in case it's interesting to different pairs of eyes.
Please let us know if it fails on RHEL 5.3.
OK, I can report success on dom0 CentOS 5.3 kernel-xen-2.6.18-128.1.6.el5 / xen-3.0.3-80.el5_3.2 / domU Fedora 10 2.6.29.1-15.fc10.x86_64 / 9000-byte frames. So I still don't know what the bug was, but am happy RHEL5.3 fixes it. Thanks; as far as I'm concerned you can close this bug.
Thanks for the testing.