Daniel Micanek virtual Blog – Like normal Dan, but virtual.
I am delighted to announce an updated version of the vSAN Deep Dive book. It’s been a while since we did an update to this book. The most recent version was for vSAN 6.7 U1. A lot has changed since then. We’ve seen the arrival of some significant features such as vSAN File Service and HCI-Mesh.
Discover the center of the multi-cloud universe. Don’t delay. Early-bird pricing ends June 13.
The data center landscape has radically evolved over the last decade thanks to virtualization. Before Network Virtualization Overlay (NVO), data centers were limited to 4096 broadcast domains which could be problematic for large data centers to support a multi-tenancy architecture. Virtual […]
This lightening lab will enable you to explore the NSX-T Federation feature through an interactive simulation.
VMware Tanzu Community Edition now includes advanced software supply chain tooling that helps application teams deliver software more rapidly, securely, and efficiently at scale. The 0.11 release of Tanzu Community Edition, available today, introduces new supply chain choreography capabilities […]
According Release Notes for Cisco UCS Manager, Release 4.2(1l) We have a fix for CSCvz43359 Traffic using GENEVE overlay sometimes leaves wrong VNIC when GENEVE Offload is enabled on VIC14xx:
| Defect ID | Symptom | First Bundle Affected | Resolved in Release |
|---|
| CSCvz43359 | On a Cisco UCS server using an NSX-T topology, data traffic using a GENEVE overlay sometimes left the wrong vNIC when GENEVE Offload was enabled on a VIC 1400 series Fabric Interconnect. This issue is resolved. | 4.2(1d)C | 4.2(1l)C |
Symptom: Rapid mac moves observed on Fabric Interconnect and northbound switches where mac address belongs to device using GENEVE overlay. pkcatp-uw in ESXi kernel was not able to observe this phenomenon. This was only observable via tcpdump on the physical VIC adapter in the debug shell.
Conditions: This was specifically seen in an NSX-T topology though more general use of GENEVE offloading in the hardware would likely show same behavior. The NSX-T TEP mac addresses should be ‘bound’ to a physical interface unless there is a topology change. In this circumstance, we observed the TEP macs rapidly moving from Fabric A to Fabric B and vice versa while the teaming/load balancing policy was set to Active/Active in ESXi and NSX. NSX-T uses BFD Control frames between hosts and BFD leverages GENEVE. When GENEVE Offloading is enabled in the VIC adapter policy, this causes some small number of these BFD frames to egress the wrong physical link which causes the unexpected mac move behavior on northbound devices.
Links:
Be aware of the issues below found in NSX-t 3.1.3 and 3.1.3.x. If you are considering moving to NSX-T 3.1.3.x, please upgrade directly to 3.1.3.6.1.
This issue is observed when bulk vMotions occur in the NSX-T environment, following are some of the probable scenarios:
Fixed in NSX-T 3.1.3.6, but recommended to upgrade directly to 3.1.3.6.1 due to the issue below.
NSX-T 3.1.3.6 Edge configured with an L4 LB stops passing all traffic (87627)
This issue is fixed in NSX-T 3.1.3.6.1. Also, NSX-T 3.2 is not impacted by this.
vExpert 2022 Awards Announcement
Tweet Thank you to everyone who applied for vExpert and to the vExpert PROs for managing the voting process, it’s a lot of work! We are pleased to announce the list of 2022 vExperts. You can visit the vExpert Directory to see the list and profiles of each vExpert. All of the new and returning … Continued The post vExpert 2022 Awards Announcement appeared first on VMware vExpert Blog.
Potentially interesting VMware Homelab Kits for 2022
I am always on the lookout for new and interesting hardware platforms that can benefit the VMware Homelab Community. In the month of January, there were a number of new announcements that I had been following including news from the Computer Electronic Show (CES) but also a couple of product releases from vendors that I […]
SD cards can continue to be used for the bootbank partition provided that a separate persistent local device to store the OSDATA partition (32GB min., 128GB recommended) is available in the host.
Preferably, the SD cards should be replaced with an M.2 or another local persistent device as the standalone boot option.
Please refer to the following blog:
https://core.vmware.com/resource/esxi-system-storage-changes
