Hi David,
I’ve asked around if we have any documentation.. documentation will be added for 5.8 and there will also be a talk at next UnrealFest (by Ryan Hummer) meanwhile maybe I can give you some answers 
As you have figured out you can submit a BuildConfiguration that has some of the settings in there. It is also possible to set these things up in BaseEngine.ini etc since UBT parse both and the .ini path is the one Epic uses. If using horde there is also functionality to be able to have secure/encrypted cache on public internet (horde logic in UBT ask horde for cache server, which creates a secure key, register the key with the cache server and send it to the client together with ip to connect)
But if you are on a LAN and don’t need the security you can just modify the BuildConfiguration. These are the ones I have myself in my BuildConfiguration.xml:
<UnrealBuildAccelerator>
<Cache>127.0.0.1</Cache>
<WriteCache>true</WriteCache>
<CacheDesiredConnectionCount>1</CacheDesiredConnectionCount>
</UnrealBuildAccelerator>
This way I can run my own local cache service (readwrite). The upside with this is that I can change core code, revert, build again and my compile times are within the couple seconds… fact is I actually use a cache server from horde (readonly) as well (which is configured in the .ini)
If you want to share a cache server with the team you will run into the problem of different devs have different paths to sdks, ue etc.. which will prevent cache hits. This is where the vfs feature come in…
The vfs in ubt/uba work this way: Since everything is detoured in uba we can ask uba to convert paths under the hood without the detoured application knowing. With vfs UBT will create virtualized paths (like Z:\UEVFS\Engine\.. etc), and then UBT will tell UBA that Z:\UEVFS\Engine is actually d:\dev\foo\Engine on disk… this means that cl.exe, link.exe etc only see z:\uevfs paths and will output environment-independent paths.
If everyone has vfs enabled, then caches will automatically work and will also work with pch etc which is awesome. We have lots of engineers at epic having vfs enabled and our entire build farm has vfs enabled. We haven’t enabled it by default at Epic yet because there are a few things not working. Lldb debugging on linux does not work properly and Android debugger breakpoints also does not work.
I’ve had vfs on for over a year and it works fine for me. In msvc debugger it will ask for the path to source files first time but then it will just work. This is the setting I have
<BuildConfiguration>
<bUseVFS>true</bUseVFS>
</BuildConfiguration>
And yes, it can coexist with drives as long as you don’t actually use exactly “z:\uevfs\”
[Attachment Removed]