On Tue, Jun 23, 2015 at 02:24:16PM -0300, Eduardo Habkost wrote: > On Tue, Jun 23, 2015 at 07:10:11PM +0200, Andreas Färber wrote: > > Am 23.06.2015 um 18:53 schrieb Daniel P. Berrange: > > > On Tue, Jun 23, 2015 at 06:40:19PM +0200, Andreas Färber wrote: > > >> Am 23.06.2015 um 18:25 schrieb Daniel P. Berrange: > > >>> Whether QEMU changed the CPU for existing machines, or only for new > > >>> machines is actually not the core problem. Even if we only changed > > >>> the CPU in new machines that would still be an unsatisfactory situation > > >>> because we want to be able to be able to access different versions of > > >>> the CPU without the machine type changing, and access different versions > > >>> of the machine type, without the CPU changing. IOW it is the fact that > > >>> the > > >>> changes in CPU are tied to changes in machine type that is the core > > >>> problem. > > >> > > >> This coupling is by design and we expect all KVM/QEMU users to adhere to > > >> it, including those that use the libvirt tool (which I assume is going > > >> to be the majority of KVM users). Either you want a certain > > >> backwards-compatible machine and CPU, or you want the latest and > > >> greatest - why in the world mix and match?! > > > > > > As mentioned, changes/fixes to the CPU model can affect the ability to > > > launch the guest on a particular host, so we need the ability to control > > > when those CPU changes are activated for a guest, separately from the > > > machine type. > > > > Why? Today's libvirt with QEMU 2.3 resolves "pc" machine to > > "pc-i440fx-2.3" and the guest XML stays that way. When we add new > > features for 2.4, 2.3 is guaranteed to stay compatible. Any change would > > involve the libvirt user actively switching from pc-i440fx-2.3 to a > > different machine such as upcoming pc-i440fx-2.4. Why do you need to > > change the CPU separately? Why would a user want to run 2.2's CPU with a > > 2.3 machine? Or a 2.3 machine with a 2.4 CPU? That's nonsense. If you > > want to tweak features, you already have command line options available > > to do so on the basis of what the selected machine provides. > > Because pure guest-side ABI changes are different from changes that also > have additional host-side requirements, so we want to untie both things. > > About being able to tweak features today, that's true: we have > command-line options for most stuff and that's _almost_ enough for what > libvirt needs. What's missing is something to avoid silently getting new > features that libvirt aren't aware of (but may make the VM unrunnable). > The purpose of "-cpu custom" is to ensure no new host side feature > requirement will be introduced silently, even if choosing a different > machine.
It also has a positive impact on maintenance. By allowing libvirt to control the CPU definitions, in cases where there is a need to push out a CPU model bugfix, libvirt will often be able to make the update available to users via a new CPU model version, without them having to do a lock-step upgrade to QEMU at the same time. 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 :|