On 20.10.2017 15:36, Christian Borntraeger wrote:
On 10/20/2017 03:16 PM, David Hildenbrand wrote:
Hi all,
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).
Actually, what is the cause of that problem? I assume it is the gs feature (gs_allowed)?
We should really avoid such things (..._allowed) for CPU model features in the future and clue all new such stuff to cpumodel_allowed.
Yes, starting a guest with <os> <type arch='s390x' machine='s390-ccw-virtio-2.9'>hvm</type> </os> <cpu mode='host-model'/>
results in
qemu-system-s390x: Some features requested in the CPU model are not available in the configuration: gs
Tying it to cpumodel_allowed would not help, migration-wise though. libvirt would still transform
<os> <type arch='s390x' machine='s390-ccw-virtio-2.9'>hvm</type> </os> <cpu mode='host-model'/>
My point was, that the host model would have to be copied and _remain_ there when s390-ccw-virtio was expanded to s390-ccw-virtio-2.9. So really replacing <cpu mode='host-model'/> by the model z13-base.... This would at least fix this issue. Just like s390-ccw-virtio get's replaced and remains thats way. But this might for sure have other problems.
into -cpu z14-base,aen=on,cmmnt=on,aefsi=on,mepoch=on,msa8=on,msa7=on,msa6=on,msa5=on,msa4=on, \ msa3=on,msa2=on,msa1=on,sthyi=on,edat=on,ri=on,edat2=on,vx=on,ipter=on,vxeh=on,vxpd=on, \ esop=on,iep=on,cte=on,ais=on,gs=on,zpci=on,sea_esop2=on,te=on,cmm=on ^^^^^ because cpu model is certainly there. Now the guest would start but migration would later fail because what we create now would never have been possible with 2.9.
Migration is a totally different story, as tooling has to make sure to find a CPU model that is compatible over all host models. So cpumodel_allowed would indeed work. (at least in my theory ;) )
If libvirt could get information from QEMU depending on the machine version, this would make it work. But of course this has other issues.
I am not sure if that is the right thing to do. The documentation states clearly that the host model is copied. If that is not runnable, fix the setup.
Christian
-- Thanks, David