On Tue, Jun 23, 2015 at 04:51:00PM +0100, Daniel P. Berrange wrote: > On Tue, Jun 23, 2015 at 12:08:28PM -0300, Eduardo Habkost wrote: > > On Tue, Jun 23, 2015 at 02:32:00PM +0200, Andreas Färber wrote: > > > Am 08.06.2015 um 22:18 schrieb Jiri Denemark: > > > >> To help libvirt in the transition, a x86-cpu-model-dump script is > > > >> provided, > > > >> that will generate a config file that can be loaded using -readconfig, > > > >> based on > > > >> the -cpu and -machine options provided in the command-line. > > > > > > > > Thanks Eduardo, I never was a big fan of moving (or copying) all the CPU > > > > configuration data to libvirt, but now I think it actually makes sense. > > > > We already have a partial copy of CPU model definitions in libvirt > > > > anyway, but as QEMU changes some CPU models in some machine types (and > > > > libvirt does not do that) we have no real control over the guest CPU > > > > configuration. While what we really want is full control to enforce > > > > stable guest ABI. > > > > > > That sounds like FUD to me. Any concrete data points where QEMU does not > > > have a stable ABI for x86 CPUs? That's what we have the pc*-x.y machines > > > for. > > > > What Jiri is saying that the CPUs change depending on -mmachine, not > > that the ABI is broken by a given machine. > > > > The problem here is that libvirt needs to provide CPU models whose > > runnability does not depend on the machine-type. If users have a VM that > > is running in a host and the VM machine-type changes, the VM should be > > still runnable in that host. QEMU doesn't provide that, our CPU models > > may change when we introduce new machine-types, so we are giving them a > > mechanism that allows libvirt to implement the policy they need. > > Expanding on that, but tieing the CPU model to the machine type, QEMU > has in turn effectively tied the machine type to the host hardware. > eg, switching to a newer machine type, may then prevent the guest > from being able to launch on the hardware that it was previously > able to run on, due to some new requirement of the CPU model associated > with the machine type.
So why not keep machine type stable? > Libvirt wants the CPU models to be independant of the machine type, > so in general only the CPU model is dependant on hardware capabilities > and machine type is isolated from hardware. > > Libvirt still intends to do versioning of the CPU models, but the > versioning will be separate from the versioning of the machine types, > and will be handled by libvirt itself. > > This also allows us to get further towards our goal which is to have a > consistent representation of CPU models across all libvirt hypervisors. > eg the same libvirt CPU model and versions can be made consistent across > kvm, xen, vmware, etc, as they're not longer changing behind our back > based on the qemu machine type. > > Regards, > Daniel > -- > |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| > |: http://libvirt.org -o- http://virt-manager.org :| > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| > |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|