On 20.10.2017 14:50, Jiri Denemark wrote: > On Fri, Oct 20, 2017 at 13:37:42 +0200, David Hildenbrand wrote: >> On 20.10.2017 13:09, 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). >> >> Yes, the host model may vary depending on QEMU version and to some >> degree also on compatibility machines (although I always try to push >> people to not introduce any new such stuff). >> >> Quoting for the libvirt documentation: https://libvirt.org/formatdomain.html >> >> "host-model >> The host-model mode is essentially a shortcut to copying host CPU >> definition from capabilities XML into domain XML. Since the CPU >> definition is copied just before starting a domain, exactly the same XML >> can be used on different hosts while still providing the best guest CPU >> each host supports." >> >> You're telling me that that copying does not happen, which seems to be >> the problematic part about this in my opinion. >> >> So I am not sure if probing anything else (as you noted below) is the >> correct thing to do. Copy it and you have a migration_safe and even >> static version of the _current_ host CPU. > > The thing is libvirt calls query-cpu-model-expansion to check what the > host CPU is. This 'host-model' CPU is replaced with the probed CPU model > when a domain starts. The problem described by Marc is that the probed > CPU model cannot be used universally with all machine types. So starting > a domain on such host with machine type s390-virtio-ccw-2.10 works, but > a domain with machine type s390-virtio-ccw-2.9 fails to start with the > same probed CPU model. > My assumption would be that the CPU model is copied into the XML when the domain fist starts. This is what the documentation describes. So when upgrading QEMU, the CPU model in the XML is still the same (z13), even though something different is now reported in the host info after upgrading QEMU (z14). In this case it would continue to work. The problem is that the CPU model is not copied into the XML doesn't remain there, right? It is suddenly replaced with a z14 host model. > Jirka > -- Thanks, David -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
