This is a known issue in vCenter Server 5.0, vCenter Server 5.0 Update 1, ESXi 5.0, and ESXi 5.0 Update 1.
This issue is resolved with vCenter Server 5.0 Update 1b.
Notes:
- Upgrading to vCenter Server 5.0 Update 1b prevents the issue from affecting virtual machines in future.
- If there are virtual machines that are already affected, you need to apply the below workarounds to identify and remediate these virtual machines.
- If you have applied the hot patch, engage VMware Support before applying the vCenter Server 5.0 Update 1b.
To work around this issue, perform one of these options:
Manually identifying and remediating affected virtual machines
To manually identify and remediate affected virtual machines:
- When a virtual machine is using a vDS, its .vmx file has an entry similar to:
ethernet0.dvs.switchId = "8d 7e 0b 50 67 e4 0b 46-3f 30 0b f8 d5 6a 58 f3"
This information is also stored in .dvsData , a hidden folder in the base or root of the VMFS volume where the virtual machine is registered. Run the command:
ls -la /vmfs/volumes/mydatastore/.dvsData
drwxr-xr-x 1 root root 700 Feb 28 14:30 .
drwxr-xr-t 1 root root 14280 May 10 10:56 ..
drwxr-xr-x 1 root root 840 May 10 11:01 8d 7e 0b 50 67 e4 0b 46-3f 30 0b f8 d5 6a 58 f3
If the directory that correlates with the .vmx file entry is not present on the same datastore, the virtual machine may be experiencing this issue.
- Connect the affected virtual machines to a different dvPortgroup temporarily, then reconnect them back to the original portgroup. When you reconnect them, the correct information is populated to the datastore.
Using an automated Perl script to identify and remediate affected virtual machines
The perl SDK script querySvMotionVDSIssue.pl , attached to this article, lists all affected virtual machines. The --fix true parameter remediates all affected virtual machines.
Note: To use the script, you need a system with
vSphere CLI 5.x installed. Alternatively, you can use the
vMA 5.x appliance.
To run the script:
- Download 2013639_script.zip (attached to this article) and unzip querySvMotionVDSIssue.pl .
- To list affected virtual machines, run:
./querySvMotionVDSIssue.pl --server vc-server-address --username vc-admin-user
Where: - server is the vCenter Server
- username is the vCenter Server admin user name
- To remediate all affected virtual machines, run:
./querySvMotionVDSIssue.pl --server vc-server-address --username vc-admin-user --fix true
Where: - server is the vCenter Server
- username is the vCenter Server admin user name
Note: The optional parameter --fix can be set to true or false. Set the parameter to true to remediate the affected virtual machines.
Using an automated PowerShell script to identify and remediate affected virtual machines
As an alternative to the perl SDK script, you can use a PowerShell script to list and fix all the affected virtual machines.
To run the script:
- Download 2013639_PowerShell_script.zip (attached to this article) and unzip CheckForDVSIssueWithNoVDSSnapin.ps1 .
- Launch vSphere PowerCLI 5.x.
- To manually import the function Test-VMVDSIssue defined in the PowerShell script, run the command:
C:\vSphere PowerCLI> Import-Module <full-path-to-script.ps1>
For example:
C:\vSphere PowerCLI> Import-Module C:\scripts\Check for DVS Issue with no VDS Snapin.ps1
- To connect to vCenter Server, run the command:
C:\vSphere PowerCLI> connect-VIserver -Server xxx.xxx.xxx.xxx -User user -Pass password
- To identify for affected virtual machines, run the command:
C:\vSphere PowerCLI> Get-VM | Sort Name | Test-VDSVMIssue
Note: Affected virtual machines are highlighted in red.
- To remediate any impacted virtual machines, run the command:
C:\vSphere PowerCLI> Get-VM | Sort Name | Test-VDSVMIssue -Fix
You see output similar to:
Problem found with VM1 Network adapter 1
Fixing issue...
..Finding free port on ESX
..Moving Network adapter 1 to another free port on ESX
..Moving Network adapter 1 back to port 1443
..Checking changes were completed
VM1 Network adapter 1 is now fixed and OK