On Thu, Nov 15, 2012 at 02:55:00 +0000, Kaneshige, Kenji wrote:
> -----Original Message-----
> From: Daniel P. Berrange [mailto:berrange@redhat.com]
> Sent: Wednesday, November 14, 2012 6:45 PM
> To: Ichikawa, Ken/市川 顕
> Cc: libvir-list(a)redhat.com; eblake(a)redhat.com; gaofeng(a)cn.fujitsu.com; Kaneshige,
Kenji/金重 憲治
> Subject: Re: [PATCH] qemu conf: Use host-model for cpu mode by default
>
> On Wed, Nov 14, 2012 at 03:10:48AM +0000, Ichikawa, Ken wrote:
> > Now, qemu guest's default cpu model is qemu32/64 and it can be
> > configured per domain. In some case, host-model mode is suitable for
> > getting enough performance in the guest because of features from cpu
> > spec.
> >
> > This patch adds a config option to qemu.conf to use 'host-model' mode
> > as default and allow users to use host-model mode in domains on a host.
> > This is useful because
> > - Guest owners don't need to touch their domain's config.
> > - An administrator can reduce an item in their checklist for VM
> > performance and guarantee all guests should run in the best performance.
>
> While I understand the benefits, I'm afraid I have to NACK this
> at this time because using host-model doesn't really work when
> trying to use nested-KVM. Until we have a solution for that, we
> neeed to stick with a CPU model that works everywhere, since
> users like OpenStack do actually use nested-KVM for testing work
> and already complained about this when I made OpenStack set the
> host-model by default.
Ken's patch is not just to change the default cpu mode to host-model.
Cpu mode is set to host-model only when user specifies
"make_default_cpu_host_model = 1" in qemu.conf. So I don't think it
cause the problem.
In current state of CPU probing, host-model is quite likely to request
something that QEMU will not be able to provide (but we wouldn't notice it
happened) or something that won't even work. I think we should not encourage
people to use host-model until we make it better in cooperation with QEMU
folks.
Not to mention that having this kind of default configuration in libvirt seems
pretty strange. This option cannot affect existing domains as it would change
their ABI and libvirt cannot guess if this is acceptable or not. And applying
such default when creating new domains looks like something that should rather
be done by clients.
Jirka