WilliamLam.com

Quick demo videos of new VMware Cloud with Tanzu services

by // Leave a Comment

VMware Cloud with Tanzu services is VMware's new managed Kubernetes offering that incorporates the vSphere with Tanzu technology delivered as a managed service as part of our VMware Cloud service offering. The initial release of Tanzu services is currently available on VMware Cloud on AWS, which will require SDDC version 1.16 and a request for enablement (contact your VMware account team) prior to deploying a new SDDC and enabling Tanzu services.

Note: In future, Tanzu services will also be enabled for existing SDDC (brownfield) as well as for other VMware Cloud Infrastructure Services, stay tuned!

Using Tanzu services with VMware Cloud is literally night and day when compared to installing and configuring vSphere with Tanzu yourself, which includes a number of other components to setup! As you would expect, as a service, it is simply a click of a button or API call and users only have to provide four basic input (technically three if you leave one of the recommended defaults) 🙂


Rather than talk about how the new Tanzu service works and some of the things you can do with the service right now, I figured I would record a few quick demo videos. You can find the Youtube playlist below if you wish to watch them all and I have also included a link to a Github repo for the demo examples that were used. Hope you enjoy!

[Read more...]

Automating the new VMware Cloud Notification Gateway (NGW) User Notification Preferences

by // 2 Comments

Last week the VMware Cloud team released one of the highly requested feature which is the ability to control notification preferences for an individual user, which is provided as part of the VMware Cloud Notification Gateway (NGW) service. Users can now login to the VMware Cloud Console (VMC UI) and on left hand side, you should now see a new Notification Preferences tab which will allow you to specify which notifications you wish to receive via the Email channel.


As of writing this blog post, there is currently over 200+ notifications that can be configured which are broken up across the following four categories:

  • Elastic DRS (7)
  • Organization General (128)
  • SDDC Maintenance (61)
  • VMware Site Recovery Service (23)

Today, the notification preferences is configured on a per-use basis and by default, users are automatically subscribed to all notifications. The ability to customize is great but with over 200+ notifications to select or de-select from, this could be a difficult task, especially with a large number of users who may or may not understand each and ever single notification type. This is certainly an area the VMware Cloud team will be looking to enhance in the future to make it even easier to consume and customize.

In the mean time, to help with making this customization change easier within your organization, we can also take advantage of the new NGW Notification Preferences API. What better way to demonstrate this than incorporating this into my VMware Cloud Notification Gateway Community PowerShell Module, which is also available for consumption within the PowerShell Gallery.

[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...]