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

Gleb Natapov gleb at redhat.com
Mon Mar 26 12:03:21 UTC 2012


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

--
			Gleb.




More information about the libvir-list mailing list