On Thu, Aug 01, 2024 at 11:50:40AM -0400, Michael S. Tsirkin wrote:
On Thu, Aug 01, 2024 at 04:45:17PM +0100, Daniel P. Berrangé wrote:
So to ensure a QEMU is started with migration compatible features will still require teaching libvirt about every single feature that has a host kernel dependancy, so libvirt (or the app using libvirt) knows to turn this off. This is alot more work for both libvirt & the mgmt app, than having QEMU provide the generic "platforms" concept which is extensible without needing further work outside QEMU.
I am just not sure it can all amount to selecting from a list. For example, some resource can be limited on one host or another. Thus we get a number. Or there could be a set of N flags, with 2^N combinations.
We don't have to support all possible combinations IMHO. If a user really does require precise control over every combination of some settings, then exposing those tunables in libvirt is inevitable. The platform concept only has to be able to express a "good enough" subset of combinations, such that it is unlikely users will need to have fine tuning for most of the tunables. We might end up exposing a handful of tunables in libvirt anyway, but as long as we get the common case satisifed, we'll eliminate most of the ongoing burden. 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 :|