Picking up the thread again from here because it looks like as
sensible a point as any.
On Tue, 2018-10-02 at 18:26 +0200, Andrea Bolognani wrote:
> 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; [...]
I'd say at this point it's fair to conclude that the consensus
among libvirt developers is to stick to the existing compatibility
promise and thus never deprecate, let alone drop, features; the
question of whether defaults could ever change hasn't been answered
in such a clear-cut manner, as far as I can tell, but it's also
somewhat less relevant because I think we can all agree that having
a single default value is simply not going to cut it these days.
So applications are supposed to provide explicit values, obtained
through libosinfo, so that they will keep working as other parts
of the stack change around them; this will, however, not be
enforced in any way but rather encouraged through documentation.
This is a sensible enough plan, but it fails to address one
important scenario: people using virsh directly to script changes
and other operations on their guests - see above for an example of
how that can end up not working as expected.
Since virsh itself is basically just exposing raw libvirt APIs,
it doesn't and shouldn't have much logic of its own, plus it falls
under the same stability guarantees as the library itself, so we
can't easily change it.
The obvious solution is to have a *different* command line client
that can alter guests the same way virsh can, but is not shipped
as part of libvirt and can thus link against libosinfo as well as
not having to follow the same strict stability guarantees.
Pavel helpfully pointed out that such a client already exists:
it's called virt-xml and it's part of virt-manager.
It needs a few tweaks before it can really fit the bill, but once
that's been taken care of you should be able to use something like
$ virt-xml \
myguest \
--os-variant fedora28 \
--add-device \
--network network=default
and get a virtio-net device, as you should, instead of rtl8139.
Actually accepting --os-variant is the missing bit, but it should
be fairly easy to do; not only that, but the existing proposal to
store libosinfo metadata in the guest XML during installation has
the potential to make even that entirely unnecessary!
For installation you'll obviously want to use virt-install, but
that's the case already since actually installing a guest from
scratch using 'virsh define' is just madness :) IIUC the use case
of importing an existing guest image without booting the guest at
the same time is not covered, but once again that's only a bugfix
away.
So once we have these changes in place, command line users can be
pretty much completely isolated from libvirt defaults, just like
virt-manager and oVirt and Nova users. Then it will be up to us
to actually advertise these alternatives and push users away from
virsh[1] and towards them.
I wonder if showing a message suggesting to use virt-xml instead
when 'virsh edit' or 'virsh attach-device' are called would be
considered acceptable at that point?
[1] Only where it makes sense, of course: 'virsh start' and
similar, for example, don't really need an alternative.
--
Andrea Bolognani / Red Hat / Virtualization
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
