qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Anthony Liguori
Subject: Re: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt
Date: Mon, 26 Mar 2012 14:04:53 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]