Optimisation Type [explain] : user experience (-) / resource optimisation (-) / functionality (-) / administration (↑)
I have seen situations where virtual desktops oddly lose network connectivity. After some investigation, it was found that the NIC for the virtual desktop had disappeared. The root cause was determined to be an accidental eject of the virtual NIC by the user.
See the image capture from a Windows 7 virtual desktop, there are several virtual hardware that can be “safely removed”. As you can imagine, removing any of these will likely have an undesirable effect. If it so happens, the recovery is not as simple as a linked clone refresh nor recompose. You can either manually add the device back by editing the virtual machine, or for stateless desktops, easily delete the virtual desktop and let View recreate a new one.
Now, rather than leave it to chance and having to recover later, what we can do is to proactively disable these hardware to be “removable”. This is done by manually adding a VMX entry for the virtual desktop devices.hotplug=false. More details can be found at this VMware KB article, http://kb.vmware.com/kb/1026230. This will disable virtual hardware to be hot pluggable to the virtual machine; such as vCPU/RAM hot add. The VMX entry can be applied to the parent virtual machine, and then the linked clones be created or recomposed. Once in place, Windows will not show these devices to be removable.
You may wonder, now what happens to USB redirection? How does it affect USB devices that are redirected from a View client? Do those devices also become non-removable? The answer is that they remain unaffected by the VMX change. Redirected USB devices continue to be hot pluggable and removable.
In conclusion, unless there is a real need to support live hot add of vCPU or RAM to a virtual desktop, the feature can be disabled for deployments. It completely eliminates any user accidents which can result in unnecessary waste of time to troubleshoot and recover.
[update 16 Jun 2014] after updating the VMX entry, ensure to boot up the VM once to ensure all changes are registered in the OS level; and I would do one more after to make sure there is no more “restart windows to apply changes” dialog box that appears. Once verified, take a snapshot. If the OS is not given a chance to recognise changes and a snapshot is captured, then all linked clones will have an annoying dialog to reboot once user logs in.
Pingback: Jason's Windows 7 Optimisation Guide for Virtual Desktops