Re: [libvirt] [RFC] qemu: Redesigning guest CPU configuration
On Mon, Jun 22, 2015 at 05:58:46PM +0200, Jiri Denemark wrote:
However, knowing all the details about a guest CPU used by QEMU for
a
given CPU model on a specific machine type is not enough to enforce ABI
stability. Without using -cpu Model,enforce (or an equivalent of
checking filtered-features via QMP) QEMU may silently filter features it
cannot provide on the current host. Even in case of TCG some features
are not supported, e.g., -cpu SandyBridge will always fail to start in
enforcing mode. Even doing something ugly and using the enforce mode
only for new machine types is not going to work because after a QEMU
upgrade new libvirt would be incompatible with older libvirt.
I'm not sure I follow the scenario you're concerned with.
Lets, say we have guest XML <cpu><model>SandyBridge</model></cpu>
and
so we're using the new "custom" -cpu arg that QEMU supports. Are you
saying that we won't be able to live migrate from the "-cpu custom"
with new QEMU, to "-cpu SandyBridge" with old QEMU, even if the CPU
seen by the guest is identical ?
That said, I don't really see a way to do all this automatically
without
an explicit switch in a domain XML. Be it a new CPU mode or an attribute
which would request enforcing ABI stability.
I don't like the idea of adding more to the mode=custom|host-model|passthroug
options, but perhaps we could signify this in a differnet way.
For example, what we're really doing here is switching between use of libvirt
and use of QEMU for CPU emulation. In similar cases, for other device types
we use the <driver> element to identify the backend impl. So perhaps we
could do a
<cpu>
...
<driver name="libvirt|qemu"/>
</cpu>
To distinguish between use of libvirt and use of QEMU for the CPU model/feature
handling ? Ideally if not specified, then we'd magically choose the "best"
approach given the QEMU we have available
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 :|