On Thu, Nov 15, 2012 at 02:55:00 +0000, Kaneshige, Kenji wrote: > > -----Original Message----- > > From: Daniel P. Berrange [mailto:berrange@xxxxxxxxxx] > > Sent: Wednesday, November 14, 2012 6:45 PM > > To: Ichikawa, Ken/市川 顕 > > Cc: libvir-list@xxxxxxxxxx; eblake@xxxxxxxxxx; gaofeng@xxxxxxxxxxxxxx; 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list