On Thu, Dec 11, 2025 at 10:09:16AM -0500, Peter Xu wrote: > On Thu, Dec 11, 2025 at 09:48:32AM +0000, Daniel P. Berrangé wrote: > > The appealing thing about machine types is that it is an opaque > > collection of properties. The mgmt app does not need to know about > > any of the properties being set, it can just let the machine type > > do its magic. > > > > Probing values for individual features which are supported on a host > > means mgmt apps need to be made aware of all the properties that are > > affected, and keep track of them for the life of the VM. This is a > > significantly higher burden for the mgmt app to deal with that the > > opaque collection machine types define, especially because apps won't > > know ahead of time which objects/properties might need this facility > > in future. > > Yes, exactly. > > IMHO we may still need "probing" of host features at some point, but we do > have two completely different way to stable the guest ABI: > > (a) Machine types (like now) > (b) "probing" + "QMP set()s" > > Here "QMP set()s" can be QMP updating a property of an object, or something > like what Vladimir proposed in the other virtio-net/tap series, via a > separate new QMP command. > > Solution (b) has a major benefit of high flexibility - we do not need > machine type versioning anymore (hence, we still need "q35", but not > "q35-X.Y" etc.), because any QEMU can likely migrate to almost any QEMU: > mgmt will probe both sides and apply mini subset for both sides, no matter > how old it was. > > To pay that off, mgmt needs to know every single trivial detail of QEMU > change on every single device to make migration work. When new things > introduced to QEMU, it must be OFF, then mgmt turns it on until probing > both sides have it. > > That makes solution (b) less appealing. > > The other thing is, since we stick with solution (a) for all these years, > IMHO we should either stick with it, or if we really think (b) is better we > should gradually obsolete (a) and use (b) all over. I just don't see it > coming, though.. as (a) is still working almost perfect - it enables > feature slower only until a new machine type used (normally means a VM cold > reboot), but it hides too many trivial details mgmt doesn't need to care, > hence much less work needed. > > IMHO we should be careful on making both (a)+(b) available (again, for (b) > the probing is still fine, it's about offloading things to mgmt to set() > via QMPs). If so, it likely implies we didn't think all things through.
I don't believe that probing could ever be a placement for (a). Determining what you want to use is not a decision that can be made in isolation of the current host. You need to know the capabilities of hosts that you intend to be able to migrate to. Machine type versions facilitate this as an admin can express the compatibility constraint in terms of this high level opaque definition, and not have to understand 100's of properties and their supportability across many hosts. The same applies to non-guest host compatibility settings. I might be runing on a RHEL-9.6 host, but I want to have compatibility with any RHEL-9.2 host or newer. I can't probe QEMU on the 9.6 host to determine what is acceptable for 9.2. We need to be able to express that cross host compatibility as an admin, without having to list a huge set of individual properties. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
