Hacker News Reader

Comment by rconti | Hacker News Reader

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?

View on HN

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.

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.

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?

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.

Reply on news.ycombinator.com