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

[Ayal Baron]

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

> 
> > 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)?
Even if the cloud doesn't support live migration, they don't pin VMs to a host. User could shut it down and start it up again and it might run on a different node.  Your ephemeral storage would be lost, but persistent image storage could still contain os info pertinent to cpu type.
Btw, I don't see why internally they would not support live migration even for when they need to put a host in maintenance etc. live storage migration could take care of the ephemeral storage if that's the issue (albeit take a million years to finish).

> >>> ovirt allows to set "cpu family" per cluster. assume tomorrow it
> >>> could
> >>> do it an
> >>> even more granular way.
> >>> it could also do it automatically based on subset of flags on all
> >>> hosts - but
> >>> would it really make sense to expose a set of capabilities which
> >>> doesn't exist
> >>> in the real world (which iiuc, is pretty much aligned with the
> >>> cpu
> >>> families?),
> >>> that users understand?
> >>
> >> No, I think the lesson we've learned in QEMU (the hard way) is
> >> that
> >> exposing a CPU that never existed will cause something to break.
> >> Often
> >> times, that something is glibc or GCC which tends to be rather
> >> epic in
> >> terms of failure.
> >
> > good to hear - I think this is the important part.
> > so from that perspective, cpu families sounds the right abstraction
> > for general
> > use case to me.
> > for ovirt, could improve on smaller/dynamic subsets of migration
> > domains rather
> > than current clusters
> > and sounds like you would want to see "expose host cpu for non
> > migratable
> > guests, or for identical clusters".
> 
> Would it be possible to have a "best available" option in
> oVirt-engine that
> would assume that all processors are of the same class and fail an
> attempt to
> add something that's an older class?
> 
> I think that most people probably would start with "best available"
> and then
> after adding a node fails, revisit the decision and start lowering
> the minimum
> CPU family (I'm assuming that it's possible to modify the CPU family
> over time).

But then they'd already have VMs that were started with the better CPU and now it'd change under their feet? or would we start them up with the best and fail to start these VMs on the newly added hosts which have the lower cpu family/type?

> 
>  From a QEMU perspective, I think that means having per-family CPU
>  options and
> then Alex's '-cpu best'.  But presumably it's also necessary to be
> able to
> figure out in virsh capabilities what '-cpu best' would be.
> 
> Regards,
> 
> Anthony Liguori
> 
> > _______________________________________________
> > Arch mailing list
> > Arch at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/arch
> >
> 
> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
>