WilliamLam.com

Is the vCenter Server Unique ID still important today?

by // 4 Comments

When I was a customer back in the day, one of my operational checklist items for deploying a vCenter Server was to configure the vCenter Server ID and ensure that it was unique from other vCenter Servers within my environment.


The vCenter Server ID is a value between 0-63 that is randomly generated by default, but it can updated by a user after the vCenter Server has been deployed.

Why should you care about the vCenter Server ID? vCenter Server uses this ID to generate Virtual Machine MAC Addresses and if two vCenter Servers have the same ID, it can potentially generate duplicate VM MAC Addresses as explained in this VMware KB 1024025.

With this background in mind, is having a unique vCenter Server ID still relavent and applicable today in 2022?

[Read more...]

Does vCenter Server recycle VM MAC Addresses after Cross vCenter vMotion?

by // 7 Comments

I recently received a question from a customer who was concerned that after a VM has been migrated from one vCenter Server to another using Cross vCenter vMotion, that the original source VM MAC Address could potentially be recycled and re-used at a later point. Back in 2015, I actually wrote about this very topic and the concerns around VM MAC Address duplication after a Cross vCenter vMotion, which I highly encourage folks to check out if you have not seen this article already.

While re-reading the article, I realized that the article had primarily focused on vCenter Servers that were in Linked Mode or under the same vSphere Single Sign-On (SSO) domain and although I did mention the Cross vCenter vMotion across across different vSphere SSO domains scenario, it looks like the details were a tad bit light.

To quickly summarize, when a VM is migrated from a source vCenter Server to the designation vCenter Server, the VM's MAC Address is added to a MAC Address "block list" on the source vCenter Server. This ensures that the VM MAC Address will not be reallocated by the source vCenter Server which would cause a network conflict. This has been the default behavior since vSphere 6.0 and no additional configuration change is required by customers.

[Read more...]

Minimum vSphere edition & features for Tanzu Community Edition (TCE)

by // 7 Comments

There have been a number of questions that have been raised by the community regarding the specific vSphere features and/or editions that is needed to deploy Tanzu Community Edition (TCE). I honestly thought I knew the requirements quite well myself but when it came to specific vSphere Editions, it made me second guess on what features TCE actually required for functionality.

I decided to deploy a brand new setup using the latest vSphere 7.0 Update 3 (vCenter Server and ESXi) release, which was all deployed onto a single 11th Gen Intel NUC. Below are my findings which I will share back with TCE folks and enhance our documentation. Ultimately, you just need access to a vCenter Server that is managing an ESXi host which can be a standalone host or one that is within a vSphere Cluster. Hopefully this will be helpful for anyone that wishes to get started.

vSphere Version:

  • As the official TCE documentation states, vSphere 6.7 Update 3 or newer is needed and this is primarily because that is the initial release that incorporates our vSphere CSI driver

vSphere Edition (minimum):

  • vCenter Standard and vSphere Standard
  • vCenter Essentials and vSphere Essentials Plus

Note: I did not have access to a vSphere Essential license but I am pretty confident it should also work.

vSphere Features:

  • Both vSphere HA and DRS is NOT required