Page History

...

The configuration uses cpu_mode=custom in nova.conf.  When cpu_mode is set to custom, then cpu_model must also be defined.  On our ZH cluster, we set it to SandyBridge.  The model must be known to libvirt; these models are defined in /usr/share/libvirt/cpu_map.xml.  On the somewhat ancient libvirt version we use, this file knows about SandyBridge and Haswell, but not about IvyBridge or Broadwell.  In our other production cluster, LS, we could use IvyBridge, but then we'd have to define that ourselves.  But we find it too cumbersome/risky to override this system file, so we just use SandyBridge as well.  Anyway, there aren't that many differences between SandyBridge and IvyBridge.

Instances that were created before we made that change to nova.conf still use all native features; therefore we must be careful when migrating those.  We had hoped that they will die out over time, but people tend to leave their VMs up for a very long time, so we'll probably just live with them.  Maybe one day we'll find a way to "cheat" Nova/libvirt into making them more easily migratable.  This can probably be done by hacking the (XML) definitions of their corresponding libvirt domains somehow.  The trick is to do this without having to reboot the VMs...