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'/>
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.
If libvirt could get information from QEMU depending on the machine version, this would
make it work. But of course this has other issues.
Christian
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
