Audi RS4 (B7) 4.2L V8 FSI (BNS) Service Training Guide

This is sooooo cool! Looks like the Audi specialist service training manual – as in the manual they use to training the service technicians. It relates to the BAR(Q7) and the BNS(RS4) engine (below).

Screen Shot 2014-12-15 at 14.18.43

Has some very sweet info inside it; like publishing the connecting rods are made from 34CrNiMo8 as opposed to 6MnVS4 which is used to make the ones in the Q7. One thing made clear is the attention to detail in this motor.. I read someone stating “it’s the closest to a race-car engine that you’ll find in a production road car with four doors”. After reading this manual, I tend to agree!

As an example; this process documents how the connecting roads are actually a split causing a deliberately uneven break for better precision when bolting back together.

Screen Shot 2014-12-15 at 14.21.50

or how about dealing with the unbalance of a fast-spinning crank…

Screen Shot 2014-12-15 at 14.28.28 Screen Shot 2014-12-15 at 14.28.33




Totally insane. I must have read the PDF about four times now and I’m still soaking in how glorious this engine really is. No wonder it goes like it does!

Give it a read: RS4V8-StudyGuide

Newquay 2014

ESXi: vmknic MAC spoofing

Just hit this issue, although – not entirely un-triggered by myself.

My situation started with a vSphere HA of a v5.1.0 host and a v5.5 host. I removed the host from the vSphere not by feature but by function of the halt command ;-)

After powering off the host, reinstalling the OS drive with v5.5, rebuilding the RAID array and restoring to the network – I noticed I had a MAC collision taking place between the two IPs associated with the two hosts above.

Host #1 – – was the v5.1.0 host (now upgraded).
Host #2 – – is the v5.5 host.

The network was seeing a broadcast response for both IPs with the same MAC address. This was the MAC address of host #1! Not only did this confuse the hell out of the network causing disruption for anything management, it also confused the hell out of me!

Wasn’t until I started looking into the vSphere setup that I realised it does ARP takeover/spoofing in order to service requests from the network.

Quick look at the ‘esxcfg-vmknic -l’ showed my offending MAC address. Running ‘esxcfg-advcfg -s 1 /Net/FollowHardwareMac’ and rebooting fixes the issue and I’m back to one MAC per host.


Not exactly the same issue as yours but related none the less. Maybe this comes in useful for anyone else having a similar amount of fun ;-)

This was my comment on after resolving the issue on my system.