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. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
