>>> From what I understand: >>> >>> QEMU >>> - add a "deprecated-features" feature group (more-or-less David's code) >>> >>> libvirt >>> - recognize a new model name "host-recommended" >>> - query QEMU for host-model + deprecated-features and cache it in caps >>> file (something like <hostRecCpu>) >>> - when guest is defined with "host-recommended", pull <hostRecCPU> from >>> caps when guest is started (similar to how host-model works today) >>> >>> If this is sufficient, then I can then get to work on this. >>> >>> My question is what would be the best way to include the deprecated >>> features when calculating a baseline or comparison. Both work with the >>> host-model and may no longer present an accurate result. Say, for >>> example, we baseline a z15 with a gen17 (which will outright not support >>> CSSKE). With today's implementation, this might result in a ridiculously >>> old CPU model which also does not support CSSKE. The ideal response >>> would be a z15 - deprecated features (i.e. host-recommended on a z15), >>> but we'd need a way to flag to QEMU that we want to exclude the >>> deprecated features. Or am I totally wrong about this? >> >> For baselining, it would be reasonable to always disable deprecated >> features, and to ignore them during the model selection. Should be >> fairly easy to implement, let me know if you need any pointers. >> > > Thanks David. I'll take a look when I can. I may not be very active this > week due to personal items, but intend to knock this out as soon as > things settle down on my end. No need to rush :) > >> I *assume* that for comparison there is nothing to do. >> > > I think you're right, at least on QEMU's end. > > For libvirt, IIRC, comparison will compare the CPU model cached under > the hostCPU tag to whatever is in the XML. If comparing, say, a gen17 > host (no csske support) with a gen15 XML, the result should come up as > "incompatible". To a user, they may think "what the heck, shouldn't old > gen run on new gen?" I assume you mean an expanded host model on a z15 that still shows "csske=true". And it would be correct: the deprecated feature still around on the older machine (indicated in the host model) is not around on the newer machine (not indicated in the host model). So starting a VM with the "host-model" on the old machine cannot be migrated to the new machine. You'd need to start the VM with the new host-TOBENAMED CPU model. Comparing with that would work as expected, as the deprecated features would not be included. > > Doesn't the comparison QAPI report which features cause the result of > "incompatible"? Would it make sense to amend the libvirt API to report > features causing this issue? I believe this is what the --error flag is > meant to do, but as far as I know, nothing useful is currently reported. Most probably it was never implemented on s390x. Makes sense to me. > > Something like this (assume we're a gen17 host, and cpu.xml contains a > gen15 host-model) > > # virsh hypervisor-cpu-compare cpu.xml --error > error: Failed to compare hypervisor CPU with cpu.xml > error: the CPU is incompatible with host CPU > error: host CPU does not support: csske I guess instead of "host CPU" you'd want to indicate one of the two CPU models provided. Not sure how to differentiate them from the XML. -- Thanks, David / dhildenb
