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