I recently posted an article on how specific actions during the upgrade of a VMware Virtual Machine’s hardware from v4 to v7 can cause problems with certain services, including DNS, DHCP, and WINS. In that case, the problem was related to Microsoft Windows leaving non-present devices with networking configurations and the failure of the VMware Upgrade Helper service to copy WINS settings when updating the NIC. As my fellow blogger and VMUG leader, Jason Boche, responded on Twitter: “Same gotchas, different version.” And right he is – anyone with experience in P2V or V2V, or who has been working with VMware long enough to have done a 2.5 to 3.0 upgrade experienced the same gotchas.
There are other issues with VMware virtual hardware upgrades, however, that you may not have experienced. One such issue that I have experienced is highlighted in VMware Knowledge Base article 1013109: “Upgrading virtual hardware in ESX 4 may cause Windows 2008 disks to go offline“. The problems described in the article are unique to Windows 2008 Enterprise and Datacenter editions only. The problem is pretty well described in the title of the article – Upgrading virtual hardware in ESX 4 may cause Windows 2008 disks to go offline. In this case, like with the ghost NIC’s I described last week, is more of a Microsoft issue, but it will rear its head when a VMware Administrator least desires it. With this particular problem, the Windows Virtual Disk Service (part of the native Storage Management suite) is set to not auto-mount newly discovered disks that do reside on a shared bus. Microsoft has a MSDN article on the VDS SANS policy here. Upgrading the virtual hardware version causes the disks to be re-discovered and not auto-mounted. This can potentially impact all non-system disks on a VM.
You may also experience similar issues when upgrading the vSCSI adapter in a VM from a standard LSI Logic Parallel SCSI adapter to a (new in vSphere 4.0) paravirtualized SCSI (pvSCSI) adapter, move virtual disks to new vSCSI adapters to increase the number of concurrent disk IO operations, or when you change the SCSI node ID of a virtual disk. These may all trigger a re-discovery of the disks by the Windows Virtual Disk Service, leaving data disks offline on Windows 2008 Enterprise and Datacenter Edition guests.
In my opinion, these issues are not reasons to forgo upgrading your virtual hardware version. However, when your upgrade/migration plans call for upgrading the virtual hardware version of your guests you should be prepared to resolve any issues caused by ‘ghost hardware’, offline disks, and the like. Both the MSDN and VMware articles I cited above offer workarounds for the offline disk issue. Here are the links again:
Thank you for pointing these out. With over 4,000 VMs, I’m a little nervous about the tools and hardware upgrade. From a scheduling and risk standpoint, I think this is by far the most difficult part of the vSphere upgrade.
Jas
Hi, I am working on this project and few issues that I’ve encountered are.
1. Before vm hardware upgrade, we need to update the vm tools.If you current version is 3.5 and you have sql installed, then updating to v4 will cause issues with sql.
Refer https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1012259
2.If you are upgrading vm hardware version,if you want to add a high performance network adaptor(vmxnet3)windows will not allow to apply the settings since the old network card prior to the update have the configuration.Follow https://support.microsoft.com/kb/315539 to delete hidden adaptors and do the task.
3.Better to disconnect the network and do the changes and add new adaptors and once its configured, delete the old and make new online.
Always be careful with the Domain controllers because snapshots cannot be trusted to work perfectly if you go wrong.