Re: [libvirt] [RFC 0/7] Warn at runtime when deprecated features are used
On Tue, Oct 02, 2018 at 16:14:39 +0200, Andrea Bolognani wrote:
Background
==========
[...]
Two concrete examples are considered here: one is the
virConnectNumOfDomains() API which, while known to be racy and having
non-racy alternatives, can still be used by developers without
getting any kind of warning in the process; the other one is the
ability to define a domain without specifying the machine type, which
Okay, but for these particular ones we could do a compile time warning.
Not that we ever can remove them though.
is becoming increasingly problematic now with some x86_64 features
being limited to q35 and downstreams looking to push for its
Well so I presume the issue is that we can't change to q35 as the
default which was vigorously discussed.
IMHO the current approach still allows users shoot themselves into the
foot (usually with less spectacular results than when the drivers for
devices don't work anymore) but still:
If you use a libvirt XML without a machine type but with features which
require a certain machine type (e.g. cpu and memory hotplug) and define
it on a host with new-enough qemu everything will work. If you do the
same on a host with older qemu your VM will not start at all (granted,
here you get a libvirt error as this will mostly result into missing
capabilities.
Our documentation states in multiple places that fields not populated by
the user are mostly hypervisor dependant what the default will become.
In my opinion the machine type is similarly hypervisor dependant, and in
this case the "hypervisor" for the libvirt-qemu infrastructure also
involves libvirt's qemu driver.
adoption, as well as being a manifestation of the more general
problem of libvirt's default being sometimes too conservative and at
odds with the existence of slimmed-down QEMU binaries being built
with reducing the total attack surface in mind.
If your qemu binary does not support certain feature, libvirt will know
it. We have capability detection and for that matter we also have
machine type detection (we fill in the default according to the
canonical name). In such case we are very welcome to choose anything
which will satisfy the default.
I'm afraid though that the downstreams you are mentioning can't in fact
fully drop i440fx for some reason and thus are trying to weasel around
by attempting to make us change the default. This I don't support as a
worthy goal. If they want to slim down qemu, they are welcome and we can
pick a suitable different default.
We can also consider using what qemu provides as a default. Users will
get the default they asked for. They always can specify their specific
type if their software is not happy with it. That is in the end the
reason for libvirt recording the machine type in the XML for it's use as
we don't want it to change. Not specifying it is a invitation to change
it.