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?