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 :|
