allow specifying CPU model for performance and live-migration

[fholzer]

System Information

Linux distribution

Host: Fedora 40
Guest: Rocky 9

Checklist

• Is your issue/contribution related with enabling some setting/option exposed by libvirt that the plugin does not yet support, or requires changing/extending the provider terraform schema?

• Make sure you explain why this option is important to you, why it should be important to everyone. Describe your use-case with detail and provide examples where possible.

Description of Issue/Question

I am somewhat new to qemu, so I hope I didn't misunderstand any of this during my research.

This provider currently doesn't support specifying a CPU model. Doing so would be important if you want to perform VM live migrations between hosts. My understanding the CPU model used for creating VMs depends on the CPU mode (which is supported) provided by users, which can be one of the following:

• custom: This defaults to "qemu64" for me, which results in a CPU that barely has any modern instruction sets enabled. More on this below.
• host-model: Uses same CPU model as host. Might work for live migrations if all hosts are of the same CPU model.
• host-passthrough: Will break live migration
• maximum: Also breaks live migration

Based on above, my understanding is that the only way to allow live migration at the moment is to use CPU mode custom, which isn't a good choice to begin with. In addition to bad performance, this qemu64 model CPU that is used for CPU mode custom doesn't have CPU features enabled that are needed for modern OS's that require x86_64-v2, like RHEL9 (and its forks). Unfortunately it's also not possible to specify CPU features using this provider, which could potentially provide a workaround to the lack of options for setting the CPU model diretly.

Providing users the option to set the CPU model, they can then freely pick either the oldest CPU model for their CPU vendor that supports x86-64-v2 (ie. Nehalem for Intel, Bulldozer for AMD) or the newest possible, which is still older then any of their VM hosts, to benefit from other instructions e.g. aes hardware acceleration.

Because I was curious about how terraform providers work, I added support for specifying a CPU model in my fork. I am aware that you generally don't accept PRs for new features, though in case you are interested in adding this, please let me know. Feedback is appreciated. https://github.com/fholzer/terraform-provider-libvirt/tree/feat/cpu-model

Additional information: I am using this provider because it is used in https://github.com/MusicDin/kubitect which is a project that allows you to quickly provision VM based Kubernetes cluster. I also created a fork of that project to incorporate changes needed to make use of the CPU model I introduced here.

Resources

• details on instruction sets provided by x86-64-v2: https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels
• x86-64 ABI compatibility levels for different CPU models: https://qemu-project.gitlab.io/qemu/system/qemu-cpu-models.html#id1
• qemu defaulting to CPU model qemu64 when not setting CPU tag, or setting CPU mode custom without setting a model: https://qemu-project.gitlab.io/qemu/system/qemu-cpu-models.html#default-x86-cpu-models
• RHEL9 x86-64-v2 requirement:
  • https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/considerations_in_adopting_rhel_9/ref_architectures_considerations-in-adopting-rhel-9
  • https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-linux-9-for-the-x86-64-v2-microarchitecture-level