[libvirt] Question about the host-model CPU mode
David Hildenbrand
david at redhat.com
Fri Oct 20 13:43:21 UTC 2017
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
More information about the libvir-list
mailing list