I thought I’d try to shed some light on the VS Hub and what it’s intended for. I work for Microsoft.
As sraboy mentions, the VS Hub is an out-of-proc services host that Visual Studio (and other VS shell-based products such as Blend) use in order to support multi-tool communication, better responsiveness within devenv (VS), and enable certain services to extend past the lifetime of the spawning process. The set of services currently hosted in the VS Hub includes many of the items called out in the other answers, such as roaming settings, processing of large swaths of ETL data that is rendered in the diagnostics tooling, some telemetry reporting, and extension auto update and notifications. That set of services is very likely to grow in the future though, so even if none of those services seem necessary at the moment, additional services will be hosted there in the future (i.e. it’s a pretty big hammer to disable the vshub.exe through the renaming recommendation :-).
In terms of lifetime, the vshub and host processes (i.e. Microsoft.VsHub.Server.HttpHost(64).exe) can stay running after devenv.exe closes. However, they should not keep running indefinitely. In most cases these processes will terminate within ~5 minutes of the last instance of a VS-based shell closing. So if you have an instance of VS running (devenv.exe) and an instance of Blend running (blend.exe), and you shut down devenv.exe, vshub and the associated host processes will keep running. If you then shut down blend.exe, vshub and the associated host process will still be running. After about 5 minutes from then, however, those additional processes will shut down. If you start another instance of devenv.exe within that 5 minute window, then vshub and the associated host processes will not terminate, and will keep running (basically the host processes terminate whenever they don’t receive any requests within 5 minutes, and after all of the host processes terminate, the vshub.exe process itself terminates).
Resource-wise, the vshub.exe process itself should always be relatively lithe. If it ever gets large, then that’s a bug and I’d love to know about it so we can fix it :-) The host processes, on the other hand, may get very large depending on the service that is being hosted. In particular, the diagnostics tooling works by processing ETL. ETL can be very, very, large, and as such, the host may use a lot of resources. The diagnostics team is looking at ways to reduce that, but for the moment, closing the diagnostics tool window when you don’t need it should help mitigate the problem.
In terms of online connectivity, there are three main sources in the current set of hosted services at the moment (note, this will change over time). First, as user3345048 mentions, the service that detects and auto-updates extensions runs in that process. The options that control that communication are in Tools | Options | Environment | Extensions and Updates (see the first two checkboxes). Second, roaming settings runs as a service in the VS Hub. The setting that controls this behavior is in Tools | Options | Environment | Synchronized settings (or more holistically, if you do not sign into the personalization account in the upper right hand corner of VS). Finally, the VS Hub does report telemetry. The volume of this data can be significantly reduced via the Help | Customer Feedback Options | Settings… menu item. You can also read about the kind of telemetry that Microsoft collects and how it’s used in that location.
