Stay out of udev if you can. It's often overwritten by component addition and manipulation MTU is parsed, and overridden, by options in /etc/sysconfig/network-scripts/ifcfg-[device]. I find it much safer to read and manage there, and if new devices are added or replaced, the behavior is dominated by the "HWADDR" associated config files there, no matter what "udev" thinks the device number or name should be.. On Wed, Nov 20, 2013 at 11:32 PM, Digimer <lists@xxxxxxxxxx> wrote: > On 20/11/13 23:03, Digimer wrote: >> On 20/11/13 20:49, aurfalien wrote: >>> >>> On Nov 20, 2013, at 4:47 PM, Digimer wrote: >>> >>>> On 20/11/13 19:47, aurfalien wrote: >>>>> >>>>> On Nov 20, 2013, at 4:44 PM, Digimer wrote: >>>>> >>>>>> On 20/11/13 19:25, aurfalien wrote: >>>>>>> >>>>>>> On Nov 20, 2013, at 4:13 PM, Digimer wrote: >>>>>>> >>>>>>>> On 20/11/13 19:04, aurfalien wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Wondering if this is the proper bridging technique to use for Centos6+KVM; >>>>>>>>> >>>>>>>>> http://wiki.centos.org/HowTos/KVM >>>>>>>>> >>>>>>>>> Before I embark on this again, I would like to do it by the book. >>>>>>>>> >>>>>>>>> Thanks in advance, >>>>>>>>> >>>>>>>>> - aurf >>>>>>>> >>>>>>>> Personally, I do this: >>>>>>>> >>>>>>>> https://alteeve.ca/w/2-Node_Red_Hat_KVM_Cluster_Tutorial#Configuring_The_Bridge >>>>>>>> >>>>>>>> It gives the VMs direct access to the outside network, as if they were >>>>>>>> normal servers. I've used this setup for years without issue under many >>>>>>>> different VMs with various OSes. >>>>>>>> >>>>>>>> cheers >>>>>>> >>>>>>> Many many thanks, will use it. >>>>>>> >>>>>>> Sounds like it will bode well concerning jumbo frames. >>>>>>> >>>>>>> - aurf >>>>>> >>>>>> Jumbo frames should be fine. I don't generally use it myself, but I have >>>>>> tested it with success. Just be sure to enable it on the bridge and >>>>>> slaved devices. Simply adding 'MTU="xxxx"' to each ifcfg-x file should >>>>>> be sufficient. >>>>>> >>>>>> -- >>>>>> Digimer >>> >>> Man, really sorry to bug as this seems begnin as I've done this numerous time but on non bridged ints. >>> >>> When I add MTU=9000 to the bridged int, I get; >>> >>> RNETLINK answers invalid argument >>> >>> My phys int is showing jumbo but the bridged int is showing standard. >> >> No bother at all. It has been a bit since I tested it though, so I will >> have to experiment a bit myself.... >> >> Done! >> >> I remember the trick now; The bridge will take the MTU of the _lowest_ >> MTU device connected to it. So in my case here, I up'ed the MTU of the >> backing ethX and bondY devices, but the bridge stayed at 1500. >> >> Trying to adjust it failed with 'SIOCSIFMTU: Invalid argument', which is >> the kernel's way of saying that the MTU is too large for the device >> (usually hit when surpassing the hardwares real MTU). Being a bridge >> though, this didn't make sense. When I up'ed the MTU of the vnetX >> devices though, the bridge jumped up on its own. >> >> So I suspect that if you do 'brctl show' and then check the MTU of the >> connected devices, one of them will still have a low MTU. Push it up and >> then do a non-fragmenting ping 28 bytes smaller than your MTU size. If >> the ping works, you know the MTU is increased. >> >> All this said, my experience with realtek NICs left me detesting them. >> I've seen cards advertised as supporting "jumbo frames" going up to >> silly sizes like 7200 only. Further, in benchmarks, the performance >> dropped over something like an MTU of 4000. >> >> If you want to determine the actual maximum MTU of a given interface, >> this might help; >> >> https://github.com/digimer/network_profiler/blob/master/network_profiler >> >> It's a little script that uses passwordless SSH between two nodes and >> automatically determines the maximum MTU between the two machines and >> then benchmarks at 100 byte intervals. When it's done, it spits out a >> graph showing the full and half-duplex results so you can see which MTU >> was the best to use. >> >> Once you've profiled the real devices, you can then work on the MTU of >> the higher-layer devices like bonds, bridges and virtual interfaces. >> >> hth > > Another update; > > To make sure the VMs' vnetX devices are created with a larger MTU, you > *sill* need to update udev[1]. > > Append to /etc/udev/rules.d/70-persistent-net.rules; > > ==== > # Make all VMs' vnetX devices come up with an MTU of 9000. > SUBSYSTEM=="net", ACTION=="add", KERNEL=="vnet*", ATTR{mtu}="9000" > ==== > > Assuming you find that you can use an MTU of '9000', of course. No > need to reboot or even restart networking. Just add that line and then > provision/boot your VMs. If the VMs are already running, you can adjust > the MTU of the existing 'vnetX' devices with: > > ifconfig vnetX mtu 9000 > > Cheers! > > PS - Credit for the udev rule: > > http://linuxaleph.blogspot.ca/2013/01/how-to-network-jumbo-frames-to-kvm-guest.html > > -- > Digimer > Papers and Projects: https://alteeve.ca/w/ > What if the cure for cancer is trapped in the mind of a person without > access to education? > _______________________________________________ > CentOS-virt mailing list > CentOS-virt@xxxxxxxxxx > http://lists.centos.org/mailman/listinfo/centos-virt _______________________________________________ CentOS-virt mailing list CentOS-virt@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos-virt
