On Fri, Oct 20, 2017 at 13:09:26 +0200, Marc Hartmayer wrote: > we recently encountered the problem that the 'host-model' [1] has to be > related to the machine type of a domain. We have following problem: > > Let's assume we've a z13 system with a QEMU 2.9 and we define a > domain using the default s390-virtio-ccw machine together with the > host-model CPU mode [1]. The definition will have the machine > expanded to s390-virtio-ccw-2.9 but retain the host-model CPU mode > in the domain definition. In a next step we upgrade to QEMU 2.10 > (first version to recognize z14). Everything is still fine, even > though the machine runs in 2.9 compatibility mode. Finally we > upgrade to a z14. As a consequence it is not possible to start the > domain anymore as the machine type doesn't support our CPU host > model (which is expanded at start time of the domain). > > For determining the actual host-model the QMP command > 'query-cpu-model-expansion' is used. This is done once per QEMU binary > and the result of it is cached by libvirt. The problem with that is > that libvirt queries with the newest machine type of the QEMU binary > for the host CPU model. No, libvirt probes QEMU with -machine none. > We could now either probe the host CPU model for each QEMU binary + > machine type combination and for this we've to start a new QEMU > process each time. This is not really a viable solution. Jirka -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
