On Thu, 2018-10-04 at 14:13 +0100, Daniel P. Berrangé wrote: > On Tue, Oct 02, 2018 at 06:26:12PM +0200, Andrea Bolognani wrote: > > 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! > > That's not correct actually. If rtl8139 is missing in QEMU, libvirt > will try e1000, and if that's missing it'll try virtio-net. Welp, you're right. Quite embarrassing that I got it wrong, too, considering that I am the one who implemented this behavior in the first place O:-) The larger point still stands, though: you pretty much never want to see an rtl8139 device popping up in your guest these days, and yet it's awfully easy for that to happen which, in my opinion, is a problem we should address. > > > 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. > > The problem with saying applications were doing it "wrong" is that > this definition of "wrong" changes. Applications were perfectly > justified in not providing a machine type, because the concept > didn't even exist in earlier libvirt. Once it did exist, we still > only supported x86, and there was no q35, so it was still valid to > not specify it. Sure, that design decision made complete sense in the context it was made in. But the context has changed in a way that turned it from an asset into a liability, and pretending that's not the case will certainly not solve the issue. > Our view of "best" way to configure a guest is changing and in many > cases it is becoming increasingly clear that there's no single > "best" way, or no single perfect default. I completely agree here. > Taking something that's historically optional and saying it should > be mandatory is a defacto API breakage. Deprecating it doesn't > magically stop it being an API breakage. It is just giving apps > a warning that we're about to hurt them, and I don't consider that > a good thing. I disagree: for better or worse, features being deprecated and ultimately removed is one of the realities of software development, and I see very little motivation for libvirt to try and play by different rules. > I think we're largely missing the bigger picture here. Configuring > guests, and using libvirt APIs in general, can be very complicated. > > We provide basic API contract docs, and a crude XML schema reference, > but this is woefully insufficient. There's very little telling apps > about the big picture way to configure things / implement tasks. > > We're missing a good developer guide where you'd give info to apps > devs about how to effectively use libvirt, so it is no surprise that > apps do things that are sub-optimal. Providing better docs to app > devs would be far more useful than deprecation warnings which have > minimal contextual guidance. I agree that having better documentation would help, and we should definitely work towards that goal. However, I'm fairly confident trying to address issues through documentation only will not be enough to get applications off problematic API usage: people mentioned several times elsewhere in the thread how they think *emitting warnings* itself wouldn't be enough, and developers would only take notice once the application breaks for good! How is documentation going to be effective? Who would look at documentation periodically just to make sure they're not using features that have since been deprecated? I know I don't do that for any of libvirt's dependencies, but if I started getting warnings I'd certainly take notice. Unless users are nagged about it during usage and developers are nagged about it during development, usage of problematic APIs will never go away. -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
