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. > 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