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.
When an ESXi host crashes, the generated core dump can be sent over the network to a remote core dump server. The vCenter Server Appliance (VCSA) can be configured as a destination by enabling the built-in vSphere Dump Collector service. By default, the storage repository for the vSphere Dump Collector service is configured to 2GB and can be increased up to 10GB, which is the supported maximum.
In earlier vSphere releases, configuring the vSphere Dump Collector repository size could be done using the vSphere Web (Flash) Client as shown in the screenshot below.
However, as part of the vSphere (HTML5) UI Client transition, it looks like all general VCSA service configurations including the vSphere Dump Collector was not ported over. I can only assume the reasoning for this was due to the infrequency configuring or updating these settings. This has been a question that has come up a few times across both VCSA 6.7 and 7.0 environments and I was recently reminded of the solution and I realized I had not blogged about the solution.