<p dir="ltr">> I think that this is impossible to implement, because users may have different hosts<br>
> inside one cluster. So It is hard to tell what selection we should allow.</p>
<p dir="ltr">We should have the info on the host they're creating it on, which is what I was thinking about, but it would certainly be tricky to do a lowest common denominator of the whole cluster.  Though since the CPU features aren't likely to change often, if at all, we *could* have each host report what it supports when it joins the cluster, and go from there.  That data could then be used to prevent creating a VM with a virtual CPU the selected host doesn't support, migrating a VM to a host that won't be able to run it, and anything else that might come up as useful to use such data for.</p>

<p dir="ltr">The information itself, namely which instruction set(s) and features a CPU supports (rather than the make/model of the CPU, which would be ridiculously overcomplicated to maintain a list for) is readily available through the proc filesystem (I'll have to look up exactly what the path is).  So getting that data will be pretty straightforward.  We'd then have to compile/acquire a list of features needed by each of the virtual CPU types KVM supports, and it would be a relatively simple matter, from there, to filter out the ones the current host isn't compatible with.  So long as it's kept on a strictly per-host basis, this approach should work fairly well.  Though cluster-wide statistics on what people are actually using might be nice to have available, too...</p>