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

On 03/12/2012 02:12 PM, Itamar Heim wrote: > On 03/12/2012 09:01 PM, Anthony Liguori wrote: >> >> It's a trade off. From a RAS perspective, it's helpful to have >> information about the host available in the guest. >> >> If you're already exposing a compatible family, exposing the actual >> processor seems to be worth the extra effort. > > only if the entire cluster is (and will be?) identical cpu. At least in my experience, this isn't unusual. > or if you don't care about live migration i guess, which could be hte > case for > clouds, then again, not sure a cloud provider would want to expose the > physical > cpu to the tenant. Depends on the type of cloud you're building, I guess. >>> ovirt allows to set "cpu family" per cluster. assume tomorrow it could >>> do it an >>> even more granular way. >>> it could also do it automatically based on subset of flags on all >>> hosts - but >>> would it really make sense to expose a set of capabilities which >>> doesn't exist >>> in the real world (which iiuc, is pretty much aligned with the cpu >>> families?), >>> that users understand? >> >> No, I think the lesson we've learned in QEMU (the hard way) is that >> exposing a CPU that never existed will cause something to break. Often >> times, that something is glibc or GCC which tends to be rather epic in >> terms of failure. > > good to hear - I think this is the important part. > so from that perspective, cpu families sounds the right abstraction > for general > use case to me. > for ovirt, could improve on smaller/dynamic subsets of migration > domains rather > than current clusters > and sounds like you would want to see "expose host cpu for non migratable > guests, or for identical clusters". Would it be possible to have a "best available" option in oVirt-engine that would assume that all processors are of the same class and fail an attempt to add something that's an older class? I think that most people probably would start with "best available" and then after adding a node fails, revisit the decision and start lowering the minimum CPU family (I'm assuming that it's possible to modify the CPU family over time).

From a QEMU perspective, I think that means having per-family CPU options and then Alex's '-cpu best'. But presumably it's also necessary to be able to figure out in virsh capabilities what '-cpu best' would be.

Regards, Anthony Liguori > _______________________________________________ > Arch mailing list > Arch(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch >