On 03/22/2012 04:32 AM, Gleb Natapov wrote:
On Tue, Mar 13, 2012 at 11:53:19AM -0300, Eduardo Habkost wrote:
So, trying to summarize what was discussed in the call:
On Mon, Mar 12, 2012 at 10:08:10AM -0300, Eduardo Habkost wrote:
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.
The statement above is the one not fulfilled by the compromise solution:
-nodefconfig would really disable the loading of files on /usr/share.
What does this mean? Will -nodefconfig disable loading of bios.bin,
option roms, keymaps?
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.
The statement above is only partly true. The default configuration file
would be still needed, but if defaults are stored on /usr/share, I will
be happy with it.
My main problem was with the need to _copy_ or edit a non-trivial
default config file. If the not-often-edited defaults/templates are
easily found on /usr/share to be used with -readconfig, I will be happy
with this solution, even if -nodefconfig disable the files on
/usr/share.
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?
The answer to this is: if the broken templates/defaults are on
/usr/share, it would be easy to deploy the fix.
So, the compromise solution is:
- We can move some configuration data (especially defaults/templates)
to /usr/share (machine-types and CPU models could go there). This
way we can easily deploy fixes to the defaults, if necessary.
- To reuse Qemu models, or machine-types, and not define everything from
scratch, libvirt will have to use something like:
"-nodefconfig -readconfig /usr/share/qemu/cpu-models-x86.conf"
cpu-models-x86.conf is not a configuration file. It is hardware
description file. QEMU should not lose capability just because you run
it with -nodefconfig. -nodefconfig means that QEMU does not create
machine for you, but all parts needed to create a machine that would have
been created without -nodefconfig are still present. Not been able to
create Nehalem CPU after specifying -nodefconfig is the same as not been
able to create virtio-net i.e the bug.
(the item below is not something discussed on the call, just something I
want to add)
To make this work better, we can allow users (humans or machines) to
"extend" CPU models on the config file, instead of having to define
everything from scratch. So, on /etc (or on a libvirt-generated config)
we could have something like:
=============
[cpu]
base_cpudef = Nehalem
add_features = "vmx"
=============
Then, as long as /usr/share/cpu-models-x86.conf is loaded, the user will
be able to reuse the Nehalem CPU model provided by Qemu.
And if it will not be loaded?
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.
So, this problem is solved if the defaults are easily found on
/usr/share.
What problem is solved and why are we mixing machine configuration files
and cpu configuration files? They are different and should be treated
differently. -nodefconfig exists only because there is not machine
configuration files currently. With machine configuration files
libvirt does not need -nodefconfig because it can create its own machine
file and make QEMU use it. So specifying machine file on QEMU's command
line implies -nodefconfig. The option itself loses its meaning and can be
dropped.
No, -nodefconfig means "no default config".
As with many projects, we can have *some* configuration required.
The default configure should have a:
[system]
readconfig=@SYSCONFDIR@/cpu-models-x86_64.cfg
Stanza by default. If libvirt wants to reuse this, they can use -readconfig if
they use -nodefconfig.
Regards,
Anthony Liguori
We still have the backwards compatibility problem for pc-1.0, pc-1.1,
and so on. But that can be discussed later, when we actually move
machine-types to somewhere outside .c files.
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.
This problem is also solved if the defaults are deployed on /usr/share
and just reused/included by the config files on /etc.
--
Gleb.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list