Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt

> Let me elaborate about the later. Suppose host CPU has kill_guest > feature and at the time a guest was installed it was not implemented by > kvm. Since it was not implemented by kvm it was not present in vcpu > during installation and the guest didn't install "workaround kill_guest" > module. Now unsuspecting user upgrades the kernel and tries to restart > the guest and fails. He writes angry letter to qemu-devel and is > asked to > reinstall his guest and move along. -cpu best wouldn't solve this. You need a read/write configuration file where QEMU probes the available CPU and records it to be used for the lifetime of the VM.

This discussion isn't about whether QEMU should have a Westmere processor definition. In fact, I think I already applied that patch. It's a discussion about how we handle this up and down the stack. The question is who should define and manage CPU compatibility. Right now QEMU does to a certain degree, libvirt discards this and does it's own thing, and VDSM/ovirt-engine assume that we're providing something and has built a UI around it. What I'm proposing we consider: have VDSM manage CPU definitions in order to provide a specific user experience in ovirt-engine. We would continue to have Westmere/etc in QEMU exposed as part of the user configuration. But I don't think it makes a lot of sense to have to modify QEMU any time a new CPU comes out.