From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37659) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7bp0-0006gr-9p for qemu-devel@nongnu.org; Tue, 13 Mar 2012 20:12:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S7bot-0000i7-Vv for qemu-devel@nongnu.org; Tue, 13 Mar 2012 20:12:05 -0400 Received: from mx3-phx2.redhat.com ([209.132.183.24]:43645) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S7bot-0000hk-Ny for qemu-devel@nongnu.org; Tue, 13 Mar 2012 20:11:59 -0400 Date: Tue, 13 Mar 2012 20:11:56 -0400 (EDT) From: Ayal Baron Message-ID: In-Reply-To: <4F5F0620.6020004@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit MIME-Version: 1.0 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: Itamar Heim Cc: Anthony Liguori , libvir-list@redhat.com, qemu-devel@nongnu.org, Avi Kivity , Jiri Denemark , arch@ovirt.org ----- Original Message ----- > 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. > assumption... :) I'd try changing twice in a row (run VM, stop, change family, restart VM, stop, change family restart VM).