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