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

From: Avi Kivity <avi@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Gleb Natapov <gleb@redhat.com>,
	libvir-list@redhat.com, qemu-devel@nongnu.org,
	Jiri Denemark <jdenemar@redhat.com>,
	"arch@ovirt.org" <arch@ovirt.org>
Subject: Re: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt
Date: Sun, 25 Mar 2012 15:21:38 +0200	[thread overview]
Message-ID: <4F6F1BE2.6040002@redhat.com> (raw)
In-Reply-To: <4F5CB2EA.10000@codemonkey.ws>

On 03/11/2012 04:12 PM, Anthony Liguori wrote:
>> Let me elaborate about the later. Suppose host CPU has kill_guest
>> feature and at the time a guest was installed it was not implemented by
>> kvm. Since it was not implemented by kvm it was not present in vcpu
>> during installation and the guest didn't install "workaround kill_guest"
>> module. Now unsuspecting user upgrades the kernel and tries to restart
>> the guest and fails. He writes angry letter to qemu-devel and is
>> asked to
>> reinstall his guest and move along.
>
>
> -cpu best wouldn't solve this.  You need a read/write configuration
> file where QEMU probes the available CPU and records it to be used for
> the lifetime of the VM.

This doesn't work with live migration, and makes templating harder.  The
only persistent storage we can count on are disk images.

The current approach is simple.  The management tool determines the
configuration, qemu applies it.  Unidirectional information flow.  This
also lends itself to the management tool scanning a cluster and
determining a GCD.

> This discussion isn't about whether QEMU should have a Westmere
> processor definition.  In fact, I think I already applied that patch.
>
> It's a discussion about how we handle this up and down the stack.
>
> The question is who should define and manage CPU compatibility.  Right
> now QEMU does to a certain degree, libvirt discards this and does it's
> own thing, and VDSM/ovirt-engine assume that we're providing something
> and has built a UI around it.
>
> What I'm proposing we consider: have VDSM manage CPU definitions in
> order to provide a specific user experience in ovirt-engine.
>
> We would continue to have Westmere/etc in QEMU exposed as part of the
> user configuration.  But I don't think it makes a lot of sense to have
> to modify QEMU any time a new CPU comes out.

We have to.  New features often come with new MSRs which need to be live
migrated, and of course the cpu flags as well.  We may push all these to
qemu data files, but this is still qemu.  We can't let a management tool
decide that cpu feature X is safe to use on qemu version Y.

-- 
error compiling committee.c: too many arguments to function