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

[Anthony Liguori <anthony@codemonkey.ws>]

On 03/26/2012 11:14 AM, Eduardo Habkost wrote:
> On Mon, Mar 26, 2012 at 02:03:21PM +0200, Gleb Natapov wrote:
>> On Mon, Mar 26, 2012 at 01:59:05PM +0200, Avi Kivity wrote:
>>> On 03/26/2012 01:24 PM, Jiri Denemark wrote:
>>>> ...
>>>>>> The command line becomes unstable if you use -nodefconfig.
>>>>>
>>>>> -no-user-config solves this but I fully expect libvirt would continue to use
>>>>> -nodefconfig.
>>>>
>>>> Libvirt uses -nodefaults -nodefconfig because it wants to fully control how
>>>> the virtual machine will look like (mainly in terms of devices). In other
>>>> words, we don't want any devices to just magically appear without libvirt
>>>> knowing about them. -nodefaults gets rid of default devices that are built
>>>> directly in qemu. Since users can set any devices or command line options
>>>> (such as enable-kvm) into qemu configuration files in @SYSCONFDIR@, we need to
>>>> avoid reading those files as well. Hence we use -nodefconfig. However, we
>>>> would still like qemu to read CPU definitions, machine types, etc. once they
>>>> become externally loaded configuration (or however we decide to call it). That
>>>> said, when CPU definitions are moved into @DATADIR@, and -no-user-config is
>>>> introduced, I don't see any reason for libvirt to keep using -nodefconfig.
>
> ACK.
>
>>>>
>>>> I actually like
>>>> -no-user-config
>>>> more than
>>>> -nodefconfig -readconfig @DATADIR@/...
>>>> since it would avoid additional magic to detect what files libvirt should
>>>> explicitly pass to -readconfig but basically any approach that would allow us
>>>> to do read files only from @DATADIR@ is much better than what we have with
>>>> -nodefconfig now.
>>>
>>> That's how I see it as well.
>>>
>> +1
>>
>> except that instead of -no-user-config we can do what most other
>> programs do. If config file is specified during invocation default one
>> is not used. After implementing -no-user-config (or similar) we can drop
>> -nodefconfig entirely since its only user will be gone it its semantics
>> is not clear.
>
> Awesome. It looks like we have a solution now? Anthony, do you agree
> with that? Daniel, it looks good for you?

We cannot and should not drop -nodefconfig.  But yes, I agree that we should 
introduce -no-user-config and use the semantics I specified earlier in the thread.

Regards,

Anthony Liguori