VM /ETC

http://kb.vmware.com/kb/1010718 explains the normal way for disabling and removing a VMware ESX/ESXi vNetwork Distributed Switch (vDS or DVS or VDS – LOL), but when I recently tried to do so I received the following error:

“The resource ’1′ is in use. DVS [vDS Name] port 1 is reserved by to entity <not-found.> vnic 4000, type:vmVnic”

The screen shot shows the actual error I received.

After thinking about that message, I decided to check to see if any ports were in fact being used on the vDS. Although PortID 1 dvPortGroups did not show it being used as expected, other PortIDs were, in fact, in use. See image below.

I tried messing around with disabling the ports (blocking was the terminology in the vSphere Client, I believe) but I still could not delete the vDS. It was Saturday and I had family stuff to do so I reluctantly gave up at the time. However, 3 days later I was able to easily remove it via the Remove link on vDS Configuration screen just like I was supposed to be able to do all along. Needless to say I was a bit perplexed.

After researching I discovered that

there is a 24 hour time out on the previously mentioned ports in use that was preventing the vDS removal. This is a guess because I am drawing a conclusion between my error message and the information from the following VMware KB article Changing the default timeout for locked dvPorts. The resolution section of this KB explains:

“Before you can remove a vNetwork Distribued Switch or dvPort group, all unused dvPort reservations must time out. You can either wait for the default 24-hour timeout period before removing the vNetwork Distributed Switch or dvPort group, or temporarily change the default timeout for dvPorts to free the ports before the default 24-hour timeout period. If you change the default timeout, be sure to change it back after the ports have been freed.”

The details section of the KB  is not exactly a clear match to my specific scenario, but this seems to explain what actually was preventing me from deleting the vDS.

The locked port timeout can be changed by following the KB articles instructions for changing the setting to 10 minutes:

To remove a vNetwork Distributed Switch or dvPort group with locked dvPorts

1. In vpxd.cfg, add the line <vpxd><dvs><portReserveTimeout>10</portReserveTimeout></dvs></vpxd> and save the file.
2. Restart vCenter. The default timeout is now set to ten minutes.

3. After the port reservation has timed out, remove the vNetwork Distributed Switch or dvPort group.

4. Reset the default timeout by removing the line you previous added to vpxd.cfg.

5. Restart vCenter.

A vDS is created on the vCenter 4 server, so the vpxd.cfg file was in C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter on my vCenter 4. Although I used a custom install to change the default installation directory, I believe that is the default location for the vpxd.cfg file. If you have to search for it be sure to look for hidden files too.

You can see from the following screen shot I added the line in the already existing <vpxd> section just before the closing “</vpxd>” tag. Copy everything between the <vpxd></vpxd> tags in step 1 above. I’ll point out that I first placed the entire line as it’s own section just before the final </config> file, but that caused problems and the VMware VirtualCenter Service would not start. Don’t do that!

I tested the new config changes by creating a new vDS again, adding my hosts, migrating the VMs to use the vDS, powered on and off some VMs, performed a VMotion, migrated the VMs back to the standard vSwitch, removed the hosts from the vDS, and then deleted the vDS. Interestingly enough, I did not have to wait 10 minutes to delete it.

In the end this post may only be valuable for pointing out that a 24 hour period exists by default for locked portgroups on a vDS. I can’t say for sure that the vpxd.cfg change to 10 minutes means you can remove a stubborn vDS more quickly, but I’m drawing the conclusion that it helps. Let me know in the comments if you have a definitive explanation for this scenario!

Related Posts

• Design Challenges Of Virtualized vCenter With A vNetwork Distributed Switch (20)
• Don’t Hit Ctrl+Alt+Del On the ESX 4 Console (14)
• vCenter 4 and ESX 4 Now Use 10 Year Default SSL Certificate (7)
• MAC Address Identifies a Remote Server is a VMware VM (14)
• Use the VI Client to configure ESX NTP time sync (10)
• Restore Connectivity To ESXi 4 Management Network After Adding Second NIC (4)
• Simply Automating Virtual Machine IP Addressing For Disaster Recovery Sites (without scripting) (18)
• How To Add Sysprep to VMware vCenter for VM Customizations (VMware Converter also) (12)
• Recommended Reading (0)
• vSphere 4.0 Best Practices (9)