Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt
On Sun, Mar 11, 2012 at 10:41:32AM -0500, Anthony Liguori wrote:
On 03/11/2012 10:12 AM, Gleb Natapov wrote:
>On Sun, Mar 11, 2012 at 09:16:49AM -0500, Anthony Liguori wrote:
>>>If libvirt assumes anything about what kvm actually supports it is
>>>working only by sheer luck.
>>
>>Well the simple answer for libvirt is don't use -nodefconfig and
>>then it can reuse the CPU definitions (including any that the user
>>adds).
>CPU models should be usable even with -nodefconfig. CPU model is more
>like device. By -cpu Nehalem I am saying I want Nehalem device in my
>machine.
Let's say we moved CPU definitions to /usr/share/qemu/cpu-models.xml.
Obviously, we'd want a command line option to be able to change that
location so we'd introduce -cpu-models PATH.
But we want all of our command line options to be settable by the
global configuration file so we would have a cpu-model=PATH to the
configuration file.
But why hard code a path when we can just set the default path in the
configuration file so let's avoid hard coding and just put
cpu-models=/usr/share/qemu/cpu-models.xml in the default
configuration file.
We wouldn't do the above.
-nodefconfig should disable the loading of files on /etc, but it
shouldn't disable loading internal non-configurable data that we just
happened to choose to store outside the qemu binary because it makes
development easier.
Really, the requirement of a "default configuration file" is a problem
by itself. Qemu should not require a default configuration file to work,
and it shouldn't require users to copy the default configuration file to
change options from the default.
Doing this would make it impossible to deploy fixes to users if we evern
find out that the default configuration file had a serious bug. What if
a bug in our default configuration file has a serious security
implication?
But now when libvirt uses -nodefconfig, those models go away.
-nodefconfig means start QEMU in the most minimal state possible.
You get what you pay for if you use it.
We'll have the same problem with machine configuration files. At
some point in time, -nodefconfig will make machine models disappear.
It shouldn't. Machine-types are defaults to be used as base, they are
not user-provided configuration. And the fact that we decided to store
some data outside of the Qemu binary is orthogonal the design decisions
in the Qemu command-line and configuration interface.
As I said previously, requiring generation of opaque config files (and
"copy the default config file and change it" is included on my
definition of "generation of opaque config files") is poor design, IMO.
I bet this even has an entry in some design anti-pattern catalog
somewhere.
--
Eduardo