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

[Anthony Liguori <anthony@codemonkey.ws>]

On 03/25/2012 04:49 AM, Gleb Natapov wrote:
> On Thu, Mar 22, 2012 at 03:01:17PM -0500, Anthony Liguori wrote:
>> So let's avoid that and start by having a positive configuration
>> mechanism that the user can use to change the path and exclude it.
>> My suggestion eliminate the need for two future command line
>> options.
>>
> If cpu models are not part of configuration they should not be affected
> by configuration mechanism. You are just avoiding addressing the real
> question that if asked above.

I think you're just refusing to listen.

The stated direction of QEMU, for literally years now, is that we want to arrive 
at the following:

QEMU is composed of a series of objects who's relationships can be fully 
described by an external configuration file.  Much of the current baked in 
concepts (like machines) would then become configuration files.

qemu -M pc

Would effectively be short hand for -readconfig /usr/share/qemu/machines/pc.cfg

There are some valid points that were raised in this thread, namely that the 
user needs to have a file that acts as strictly config (stored in /etc).  I'm 
totally happy moving the CPU configuration to /usr/share in order to address this.

I think the thread has reduced to: should /usr/share configuration files be read 
by default or just treated as additional configuration files.  It seems pretty 
obvious to me that they should be treated as normal configuration files.  This 
gives you the user the ability to have fine grain control over which files are 
used including the ability to change the location for each file.

Maybe RHEL only wants to expose supported CPUs and supported machines, wouldn't 
it be better to not have to patch QEMU to do that?

Wouldn't it be even better if you could drop in a separate CPU configuration 
file with the supported CPU types and then change the default /etc config to use 
that instead?

Regards,

Anthony Liguori