On Tue, Oct 13, 2009 at 02:56:41AM -0400, john cooper wrote:
Dor Laor wrote:
> What about another approach for the cpuid issue:
> I think that dealing with specific flags is pretty error prone on all
> levels - virt-mgr, libvirt, qemu, migration, and even the guest.
..and performance verification, QA, and the average end user.
Unless we reduce all possible combinations of knob settings
into a few well thought out lumped models the complexity can
be overwhelming.
That is a policy decision for applications to make. libvirt should expose
the fine grained named CPU models + arbitrary flags, and other bits of
info as appropriate (eg formal model for core/socket topology). Apps can
decide whether they want to turn that into a higher level concept where
admins pick one of a handful of common setups, or expose the full level
of control
Daniel
--
|: Red Hat, Engineering, London -o-
http://people.redhat.com/berrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org -o-
http://ovirt.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|