----- 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). -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list