Ghost port groups appear under Network section for VMs

While performing some VM migrations I encountered a strange anomaly – ghost port groups appearing under the Network section in the vSphere client. Below we can see 4 port groups but there should only be 2:


So what preceded this strange happening? Well, the VMs I was working on were being migrated from an older ESX 4.1 standalone host to a shiny new ESXi 5.1 standalone host. The important factor here is that I had to upgrade VMware Tools and the Virtual Hardware version to the latest versions once the VMs had been moved to the new ESXi 5.1 host. Being a good boy scout I followed the official process detailed here on VMware’s site, which recommended taking a snapshot of each VM prior to upgrading VMware Tools and the Virtual Hardware version. After the snapshot was taken I changed the port groups of each VM to match the new port groups. This was when I noticed this strange occurrence. A quick check of the virtual Network adapters confirmed that there were only 2 networks and not 4:


Once the upgrade work had been completed and we deleted the snapshots those ghost port groups disappeared:


The moral of the story is taking a snapshot of the VM and then changing the port groups while the snapshot is still active will show both the old and new port groups until the snapshot is removed.

Upgrading a virtual machine to the latest hardware version (multiple versions)(1010675)

Snapshot Server 2012 Domain Controllers

In a previous post I advised not taking snapshots of Server 2003/2008/R2 Domain Controllers. The reason was that reverting them to a previous snapshot could potentially corrupt AD.

With the launch of Server 2012 comes the ability to apply snapshots on Domain Controllers. This is made possible by VM Generation IDs.

The following video shows how snapshots are handled in Server 2012 Domain Controllers in Hyper-V. The video instructor is Paul Gregory, a Principal Technologist working for QA. I attended a Server 2012 training course he was instructing which was where I first learned about the VM Generation ID feature:

In a scenario whereby a reversion to a previously taken snapshot is initiated, Windows compares the VM Generation ID with the msDS-GenerationID attribute stored within the Domain Controller’s computer object in AD. If there are no differences between the two values the restore transactions proceed as normal. If they are different, the Domain Controller’s InvocationID is reset and RID pool is deleted to avoid creating objects with duplicate ID’s and it will enter recovery mode (just like a Non-Authoritative restore) and will receive replicated objects from other Domain Controllers to roll its database forward after which normal operation will resume.

This VM Generation ID feature helps to avoid AD problems such as replication failures and general corruption but is only possible when using Windows Server 2012 Hyper-V (see this link) or VMware ESXi version 5.0 build 821926 and above which is detailed here.