13 ms·

FWIW, microcode is now included the patch that VMware released today. Gonna go test it out now... PSA: VMs have to be cold booted after patching and set to HW

FWIW, microcode is now included the patch that VMware released today. Gonna go test it out now... PSA: VMs have to be cold booted after patching and set to HW v11+ for PCID support EDIT: Just fired up my first Windows VM after patching ESXI and I'm now showing all green using the PowerShell script. Here's the link that I'm referring to: https://www.vmware.com/us/security/advisories/VMSA-2018-0004.html https://www.vmware.com/us/security/advisories/VMSA-2018-0004...

rconti 9y ago
Yikes. So they refuse to vMotion to a host that's on the new microcode? I'm not even clear on how that would be supported -- it should Just Work if the host is in the cluster. Are hosts unable to rejoin a cluster after rebootign with this new microcode because they're effectively part of a different processor compatibility now? Does EVC affect how this impacts the ability to vMotion?
- kijiki 9y ago
  The problem (requiring the cold reboot of the VM) is that they masked the PCID bit off in the CPUID, so the VM thinks it is running on a CPU that doesn't support PCID. Obviously they've stopped doing this with the new update, but you have to cold reboot (not warm) for the newly enabled feature to be visible. Presumably they did this to make it possible to hot migrate VMs between old hosts that don't support PCID, and new ones that do. Which, with hindsight, was not a good tradeoff.
  - derefr 9y ago
    Given that Linux (and most other VM guest OSes of note) support CPU hotplug, shouldn't vMotion have just given the VM a new, second CPU with PCID, and then removed the first one?
    - kijiki 9y ago
      Given the history of CPU hot plug, it has always been generally assumed that all the CPUs in an SMP are identical (hence the S in SMP). I'm not aware of any OS that supports differing feature sets, and if one exists, it almost certainly goes with the least common denominator feature set.
- benjarrell 9y ago
  In a cluster, all hosts must be updated for the flags to be exposed to the guests. That is why you must update vCenter first, which prevents the patched hosts from being rejected.

rconti 9y ago

Yikes. So they refuse to vMotion to a host that's on the new microcode? I'm not even clear on how that would be supported -- it should Just Work if the host is in the cluster. Are hosts unable to rejoin a cluster after rebootign with this new microcode because they're effectively part of a different processor compatibility now? Does EVC affect how this impacts the ability to vMotion?

kijiki 9y ago
The problem (requiring the cold reboot of the VM) is that they masked the PCID bit off in the CPUID, so the VM thinks it is running on a CPU that doesn't support PCID. Obviously they've stopped doing this with the new update, but you have to cold reboot (not warm) for the newly enabled feature to be visible. Presumably they did this to make it possible to hot migrate VMs between old hosts that don't support PCID, and new ones that do. Which, with hindsight, was not a good tradeoff.
- derefr 9y ago
  Given that Linux (and most other VM guest OSes of note) support CPU hotplug, shouldn't vMotion have just given the VM a new, second CPU with PCID, and then removed the first one?
  - kijiki 9y ago
    Given the history of CPU hot plug, it has always been generally assumed that all the CPUs in an SMP are identical (hence the S in SMP). I'm not aware of any OS that supports differing feature sets, and if one exists, it almost certainly goes with the least common denominator feature set.
benjarrell 9y ago
In a cluster, all hosts must be updated for the flags to be exposed to the guests. That is why you must update vCenter first, which prevents the patched hosts from being rejected.