On Tue, 2018-10-02 at 17:19 +0200, Peter Krempa wrote:
> On Tue, Oct 02, 2018 at 16:14:39 +0200, Andrea Bolognani wrote:
[...]
> > 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.
I believe we should really have both, to address both applications
being rebuilt against newer libvirt all the time, such as open source
projects that are included in our CI or in any Linux distro, and
those that aren't and just get a new libvirt version from time to
time due to OS updates, such as home-grown management tools.
> Not that we ever can remove them though.
True, that has been our policy so far. Doesn't mean it cannot ever
change :)
[...]
> 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.
I don't necessarily disagree with you, but it should be noted that
attempts to change libvirt's own defaults have been rejected times
and times again on the basis that existing applications were, despite
that being a very bad idea, relying on them.
> > 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.
q35 is what sparked the discussion, but it's far from the only
offender. For example, if I create a guest using
$ virt-install \
--os-variant fedora28 \
...
then libosinfo will be queried for information about supported
network cards, and the resulting XML will look like
<interface type='network'>
<model type='virtio'/>
...
However, libvirt's own default for x86_64 guests' network devices is
rtl8139, which means that if I later 'virsh edit' the guest or 'virsh
attach-device' a new network interface I will get that model instead
of virtio; to add insult to injury, the above will happen even if my
QEMU binary has rtl8139 compiled out and virtio-net-pci compiled in!
The only way to avoid such issues is to require the user / management
application to provide the model name themselves.
> 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.
Using QEMU's default machine type is exactly what we were doing until
very recently, but we changed that because QEMU's default has been
i440fx for so long that applications have come to rely on it and
would break if q35 suddenly started showing up instead, which goes to
show that they should not have been relying on either QEMU's or
libvirt's default, and they should have been providing the machine
type explicitly, possibly as obtained by querying libosinfo, instead.
Or, looking at it from the other side, that libvirt should have
required them to provide the machine type instead of trying to be
helpful and filling it in if absent. We can't retroactively mandate
applications do that, but we can deprecate such behavior and thus
steer them firmly towards the proper solution.
--
Andrea Bolognani / Red Hat / Virtualization
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
