[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] CPU model versioning separate from machine type version

From: Eduardo Habkost
Subject: Re: [Qemu-devel] CPU model versioning separate from machine type versioning ?
Date: Thu, 28 Jun 2018 16:23:53 -0300
User-agent: Mutt/1.9.2 (2017-12-15)

On Thu, Jun 28, 2018 at 07:59:38PM +0100, Dr. David Alan Gilbert wrote:
> > An application like virt-manager which wants a simple UI can forever be
> > happy simply giving users a list of bare CPU model names, and allowing
> > libvirt / QEMU to automatically expand to the best versioned model for
> > their host.
> > 
> > An application like oVirt/OpenStack which wants direct control can allow
> > the admin to choice if a bare name, or explicitly picking a versioned name
> > if they need to cope with possibility of outdated hosts.
> I fear people are going to find this out the hard way, when they add
> a new system into their cluster, a little bit later it gets a VM started
> on it, and then they try and migrate it to one of the older machines.
> Now if there was something that could take the CPU defintions from all
> the machines in the cluster and tell it which to use/which problems
> they had then that might make sense.  It would be best for each
> higher level not to reinvent that.

I think QEMU already provides enough info to allow that to be
implemented.  I'm not sure sure if the libvirt API already
provides all the info needed for this (I think it does).

> Would you restrict the combinations to cut down the test matrix - e.g.
> not allow Haswell-3.0.0 on anything prior to a 2.12 machine type?

Not sure if it would be worth the extra complexity: we would need
an interface to tell libvirt which CPU models are usable on which

But a generic mechanism to tell libvirt which devices are allowed
on each machine-type would very interesting to have, anyway.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]