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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
