I have physical host which has cpu model ‘Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz’ and it has ‘avx2’ flag in cpuinfo. The host has kvm/qemu hypervisor and libvirt configured. I set cpu mode as host-model in domain XML. Guest vm can be created on the host. When I check cpu model of guest vm, it shows as ‘SandyBridge’ and it also has ‘avx2’ flag in cpuinfo. But ‘SandyBridge’ does not support ‘avx2’ flag but ‘Haswell’ model does support. It is just due to host-model mode, libvirt finds nearest cpu model to ‘Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz’ as ‘SandyBridge’ but it should show ‘Haswell’ instead. Does that mean libvirt have a bug or it is valid representation in this scenario? I am using libvirt version 1.2.2
What I think is going on here is that your older version of libvirt is not aware of the fact that Intel disabled TSX in Haswell chips in a microcode update which your processor has almost certainly received by now. Libvirt only became aware of and advertised a Haswell-noTSX CPU model in version 1.2.14. Because your CPU has had some features disabled that libvirt uses for CPU type detection, it mistakenly thinks it is a SandyBridge. On a current version of libvirt, it should be correctly detected as Haswell-noTSX.
In practice, this should not really affect you at all, except for VMs being unable to use the other features introduced in Haswell and not present in SandyBridge, but you can manually add these to your VM definition XML if you can’t upgrade libvirt and really want them. Keep in mind that you probably will also need to upgrade qemu. And at that point you should probably just use a more current hypervisor. Whatever you’re running now is older than the hardware on which it’s running, which is always a questionable idea…
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.