QEMU CPU Type (kvm64 vs qemu64)

[NoLine]

Which CPU model should I choose for a VM?
Do you use the default kvm64 or do you switch to another model?

Unfortunately my cluster has different CPU models.

Intel (R) Xeon (R) CPU E3-1230 V2 @ 3.30GHz
Intel(R) Xeon(R) CPU E3-1270 v6 @ 3.80GHz
Intel (R) Xeon (R) CPU E5-2620 0 @ 2.00GHz
Intel (R) Xeon (R) CPU E5-2630 0 @ 2.30GHz

and unfortunately
AMD Opteron (tm) Processor 6164 HE

I know, a live migration between Intel and AMD is not recommended.


The default is kvm64, should I leave it or maybe change it to e.g. qemu64?
https://qemu-project.gitlab.io/qemu/system/qemu-cpu-models.html
kvm64 is non-recommended cpu model.

I can set "SandyBridge" for AMD "Opteron_G3".
but during the migration, I will have to change, but I would prefer not to

 

[VictorSTS]

The CPU model will allow some CPU instruction sets to be used in that VM, as long as the hardware supports them.

For the Intel parts, the obvious setting would be "Sandy Bridge", as that's the series for the older E3-12xx chips. But for the Opteron one I can't really say as I no longer have any and never mixed Intel/AMD in the same cluster.

I would leave the least CPU intensive VMs in that Opteron server and set their CPU model to kvm64, to allow them to be migrated to any Intel node. The rest of the VMs will only run on Intel nodes and I would set CPU to "Sandy Bridge".

Be careful not to migrate a "Sandy Bridge" VM from an Intel node to the AMD one either manually or by HA and you will get both flexibility and reliability for all VMs. Also, plan your capacity to allow all "Intel" VMs to fit in just 4 servers, to allow downtime for at least one Intel server. AMD server downtime is not an issue as their VMs can be migrated to an Intel node anytime as their model is kvm64.

 

[hvisage]

Well, I have the same "problem", as using hosting providers I am limited in my choices and thus the mixing of AMD and Intel is becoming a reality for various configurations and price points

Thus the question for me is also which is the beterer performance wise: QEMU64 or KVM64 ? (Yes yes, I known, not all, not as fast) but the performances is such that when I need the real performances, I'll use LXCs and then just don't do live-migrations, but the VM instances live migrations is much more important than performance, but still needing to understand which is the beter option(s)

Perhaps the question otherwise: is there a mechanism to find the common feature sets on all the hosts to define a "shared" CPU model, and which CPU flags can be added and will be emulated on a host (even when migrated from a host not having it in CPU/native) ?

 

[VictorSTS]

As stated here, kvm32/kvm64 are non-recomended x86 CPU, listed "just for historical compatibility with ancient QEMU versions", so the way to go is either:

- Use qemu32/qemu64 CPU (lower performance and increased security risks as such QEMU cpu has no patches for spectre/meltdown/etc).
- Create "availability groups" in your cluster/s in a way that VM's will only be moved/live migrated among servers with similar CPUs, so you can set the QEMU cpu model acondingly. You'll end up having unsued, spare, resources if you try to cover every failure that might happend when any server goes down, as VM's can only move to a specific node(s) instead of to any.
- Spend a little more and get hosts as similar as possible. The flexibility and peace of mind will pay by itself.

Thus the question for me is also which is the beterer performance wise: QEMU64 or KVM64 ?

Regarding performance, it will depend on your workload. Run a benchmarks using each QEMU cpu model so you will get a non-guessed estimation on how much performance you will get using the proper CPU model.

 

[VictorSTS]

Perhaps the question otherwise: is there a mechanism to find the common feature sets on all the hosts to define a "shared" CPU model, and which CPU flags can be added and will be emulated on a host (even when migrated from a host not having it in CPU/native) ?

Sorry, forgot this question. You can get information about your hosts CPU using cat /proc/cpuinfo | grep flags | uniq. Then, there is a list of the features exposed by QEMU for each CPU model:

https://github.com/libvirt/libvirt/tree/master/src/cpu_map

You can then compare your hosts CPU features with those of each QEMU cpu model and maybe get a lowest common denominator. Even then, test everything before going into production.

 

[hvisage]

- Use qemu32/qemu64 CPU (lower performance and increased security risks as such QEMU cpu has no patches for spectre/meltdown/etc).

Yeah, that is a risk I'm willing to take in my environment given I'm the sysadmin for all of them, so if somebody/code other than what I need/want to execute in the VMs, then I have other/bigger security problems =)

- Create "availability groups" in your cluster/s in a way that VM's will only be moved/live migrated among servers with similar CPUs, so you can set the QEMU cpu model acondingly. You'll end up having unsued, spare, resources if you try to cover every failure that might happend when any server goes down, as VM's can only move to a specific node(s) instead of to any.

Great idea, was thinking about that, but currently the cost/expense not worth it.

- Spend a little more and get hosts as similar as possible. The flexibility and peace of mind will pay by itself.

In this specific case, it's actually economically unfeasible, though will be in that state after a couple of months or year as we grow and migrate, the issue that is hitting me today. is that we have the old servers in place and as we phase in the new servers, and we get issues with them (yeah, I yet have to get a bunch of servers at the same time that doesn't have some servers having some device/cpu/ram issue in the first month ;( ) I need to migrate back and worth.

Regarding performance, it will depend on your workload. Run a benchmarks using each QEMU cpu model so you will get a non-guessed estimation on how much performance you will get using the proper CPU model.

Sorry, forgot this question. You can get information about your hosts CPU using cat /proc/cpuinfo | grep flags | uniq. Then, there is a list of the features exposed by QEMU for each CPU model:

https://github.com/libvirt/libvirt/tree/master/src/cpu_map

You can then compare your hosts CPU features with those of each QEMU cpu model and maybe get a lowest common denominator. Even then, test everything before going into production.

Yeah, was hoping for a tool/something that is able to grab the cpuinfo from a cluster's nodes and provide the list of common flags for a cluster/similar common CPU... the type of job for a student/intern....