WilliamLam.com

Managing VM snapshot retention policies using the VMware Event Broker Appliance (VEBA)

by // 2 Comments

vSphere Snapshots is an amazing technology that has enabled our customers to do so many amazing things from application lifecycle and testing to operating system updates and many other use cases. Like any technology, if it is miss-used, the benefits can quickly turn into challenge or nightmare.

As Peter Parker once said, "With great power comes great responsibility" which I think is one way to summarize VM snapshot usage 😆


I am pretty sure that every VI Admin out there has at least one story about vSphere snapshots gone wrong. Due to the convenience, ease of use and some times miss-understanding of how vSphere snapshot works, it can lead to a number of issues including filling up your storage and impacting other running workloads.

Now, imagine if you could implement a snapshot retention policy for your VM(s) based on the size of a given snapshot or maybe the number of days the snapshot has existed? Would that not be cool!?

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