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

[Ayal Baron <abaron@redhat.com>]

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