From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:60055) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7N9z-0000c8-6h for qemu-devel@nongnu.org; Tue, 13 Mar 2012 04:32:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S7N9x-000127-78 for qemu-devel@nongnu.org; Tue, 13 Mar 2012 04:32:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:64568) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7N9w-00011v-VV for qemu-devel@nongnu.org; Tue, 13 Mar 2012 04:32:45 -0400 Message-ID: <4F5F0620.6020004@redhat.com> Date: Tue, 13 Mar 2012 10:32:32 +0200 From: Itamar Heim MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ayal Baron Cc: Anthony Liguori , libvir-list@redhat.com, qemu-devel@nongnu.org, Avi Kivity , Jiri Denemark , arch@ovirt.org On 03/12/2012 10:19 PM, Ayal Baron wrote: > > > ----- Original Message ----- >> On 03/12/2012 02:12 PM, Itamar Heim wrote: >>> On 03/12/2012 09:01 PM, Anthony Liguori wrote: >>>> >>>> It's a trade off. From a RAS perspective, it's helpful to have >>>> information about the host available in the guest. >>>> >>>> If you're already exposing a compatible family, exposing the >>>> actual >>>> processor seems to be worth the extra effort. >>> >>> only if the entire cluster is (and will be?) identical cpu. >> >> At least in my experience, this isn't unusual. > > I can definitely see places choosing homogeneous hardware and upgrading every few years. > Giving them max capabilities for their cluster sounds logical to me. > Esp. cloud providers. they would get same performance as from the matching "cpu family". only difference would be if the guest known the name of the host cpu. > >> >>> or if you don't care about live migration i guess, which could be >>> hte case for >>> clouds, then again, not sure a cloud provider would want to expose >>> the physical >>> cpu to the tenant. >> >> Depends on the type of cloud you're building, I guess. >> > > Wouldn't this affect a simple startup of a VM with a different CPU (if motherboard changed as well cause reactivation issues in windows and fun things like that)? that's an interesting question, I have to assume this works though, since we didn't see issues with changing the cpu family for guests so far.