Happy to share that our popular USB Network Native Driver for ESXi Fling has now been updated to v1.8 which primarily adds support for ESXi 7.0 Update 2!
This release also resolves a recent PSOD issue that a few folks in the community were hitting when using multiple USB NICs. For more details, please see the change log for more information.
A simple question with a simple answer, yes! I have seen this question get asked in various internal Slack channels on whether you can deploy both Tanzu Kubernetes Grid (TKG) and vSphere with Tanzu (formally Project Pacific) on the same vSphere Cluster? If you were an early user of TKG, you may recall that if you attempted to deploy TKG to a vSphere Cluster which already had vSphere with Tanzu enabled, it would prevent you from proceeding. Instead of having to deploy another Kubernetes management control plane, you could simply leverage and connect to the Supervisor Cluster control plane using the TKG CLI and start deploying TKG Workload Clusters.
From a technical standpoint, there is no reason that TKG and vSphere with Tanzu could not co-exist on the same vSphere Cluster. In fact, this request has come up a number of times that the original TKG behavior has been recently updated to now allow for this co-existence. From an exploratory and learning point of view, this is quite useful to be able to try out both solution and not have to dedicate a specific vSphere Cluster for each of the Tanzu Kubernetes (K8s) offerings. A more practical use case that came up recently from a customer was being able to use both solution as a way to consolidate their workloads using a specific Tanzu K8s solution, which makes total sense. Today, there are still some differences in terms of the features and capabilities between TKG and vSphere with Tanzu and depending on your needs, you may have a use case for both in your environment.
Although I come across a fair amount of interesting and challenging questions posed by our customers, I have to say this is certainly one of the more stranger question that continues to surface every so often. The question itself is fairly straight forward, but what I find strange is the reasoning and justifications for needing such a solution.
In case the title was not a give away, the question is having the ability to restrict a set of user(s) from the vSphere UI while still allowing access to the vSphere API for these same user(s). To be clear, the behavior of vSphere is that if you have vSphere UI access, then you also have vSphere API access which is all based on the permissions a user or group has been granted. There is no way to distinguish or limit access between these interfaces including any vSphere SDK or PowerCLI usage which also relies on vSphere API access.
There may be valid use cases for needing such a capability, however from my experience in talking with our customers and field, it feels like this is an attempt to solve organizational and/or process issues. Let give you a few examples that I have come across over the years: