There are several layers of networking on the virtualization infrastructure. Guest operating system, Virtual Machine, ESXi driver, physical network adapters, RJ45/SFP and network switches…etc. Sometimes it’s hard to say where exactly caused a problem. Especially hardware layer problems. Today I worked on a very interesting case, it may give some ideas to troubleshooting network performance issue which is caused by hardware layers.
A user told me he was bothered by network performance of a virtual machine. It’s slow to copy data to NFS share. But responding to “ping” command looked good. I didn’t see any issue on virtual machine layer. VMware Tools was up to date, Windows OS was patched, virtual network adapter type was VMXNET3 and VM version was also up to date.
When I tried to copy an image file to share folder of the virtual machine, I did see sometimes speed was fast, but sometimes not. Since I have two physical uplinks, it led me to guess it could be one of the uplinks.
After a lot of swapping and cable changing, we eventually figured out there was a bad SFP on network switch end. I was able to observe the issue by using “psping.exe” of Microsoft Sysinternals. I used the following command to send the different size of ping package to the virtual machine. Network drops were increasing when I increased package size.
psping.exe -l <size of package> <Destination>
Example: psping.exe -l 4k xxxx.contoso.com
The size could be 1k, 2m or even larger. I think this is a good way to identify problem outside of ESXi. Especially SFP problem as such kind of problem didn’t give any CRC or error count on network switch level.
You can also use Windows native command “ping.exe” as following. The size unit is “bytes”. For example, you need to input 4096 if you want to send 4kb.
ping.exe -l <size> <Destination>
Example: ping.exe -l 4096 xxx.contoso.com
Just a quick notes. If you use multiple monitors, some are 4K and some are regular resolution, you may see window display issue when move Internet Explorer between these monitors. Follow the KB below to change register to allow Internet Explorer 11 accommodates the monitor solutions.
Internet Explorer 11 window display changes between a built-in device monitor and an external monitor
When you upgrade or patch vCenter Server 6.0 for Windows, you may see following symptoms:
“The older version of cis-upgrade-runner cannot be removed. Contact your technical support group.”
Or error code 1063:
“Installation of component VMware CIS upgrade runner failed with error code ‘1063’”
That means the vCenter Server installer cannot find MSI files of existing vCenter Server services. It could be following reasons:
- You delete MSI files in “Temp” folder of the profile you used to install vCenter Server.
- The account you used to login and install vCenter Server was roaming profile. The profile’s “Temp” folder was automatically deleted when you reboot/logoff the server.
vCenter Server 6.0 for Windows is consist of lot of standalone package. The upgrading process usually uninstall old packages, and then install newer packages. So the failure doesn’t impact to database or inventory data. You can re-initiate the upgrading again.
But you cannot manually uninstall old package since upgrading process brings down vCenter services first then uninstall old packages. If you already uninstalled old packages, the upgrading process will be stuck on bring down vCenter Services stage since some processes may already be removed. For example “vmware-python” it maps to “VMware vCenter Configuration Service”. If you manually uninstalled it before launch upgrading. It removes the service. Upgrading is not able to check status of the service.
Easiest way to get ride of this problem is
- Open Registry Editor (regedit) and go to the path: “HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products”
You would see lot of keys are there.
- Search keyword “vmware-“. These keys store package info of vCenter Server.
- Expand one of the keys. Go to “SourceList”.
- The value of “LastUsedSource” is path of MSI file of old vCenter Server installer.
For example my value is “m;1;X:\vcenter-server\packages\”.
- Make sure your server has the path mentioned in previous step (My case it’s X:\vcenter-server\packages\) and old MSI files are available in the path. If it’s a CD-ROM letter, you just need mount old vCenter Server image to the drive.
- Copy new vCenter Server image to a local folder, uncompresse and launch installer locally.
- Now the upgrading process can read original packages on the mentioned path in step 4. It will automatically remove old packages by the old MSI files.
There are two other workarounds. One is modify the value of “LastUsedSource” to reflect a new location of packages. But you still need the old MSI files be there. Another way is delete the key after you find it in step 2. (I never tested this way but it should work as it let vCenter Server installer thinks the server is brand new so installer can override the existing folders)
I also wrote another article for upgrading error on vCenter Server 5.5 for your reference:
CustomAction VM_InstallJRE returned actual error code 1624
You may know there are 3 vulnerabilities recently noticed by industry. Long story to short, kernel address space exposed to hackers when processors running user space code. It’s not only impact to Intel processors but also AMD and ARM. CVE-2017-5715 is a hardware issues that only apply certain firmware can fix the vulnerabilities. CVE-2017-5754 and CVE-2017-5753 need to apply OS patches to change how codes access kernel address space. Following are some useful links just for your reference.
VMware: https://www.vmware.com/security/advisories/VMSA-2018-0002.html (For CVE-2017-5753 and CVE-2017-5715. VMware has not published anything for CVE-2017-5754 yet.)