On Tue, Oct 02, 2018 at 05:19:30PM +0200, Peter Krempa wrote: > 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. Definitely agree with Peter, having a runtime warning for issue that you cannot change in runtime situation is IMHO wrong. Even though we cannot remove any API the deprecation warning can be still useful because it can suggest better API to use instead of the old one. > > 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. Again I have to agree here. I don't see any strong reason why we cannot change default machine type. As Peter wrote, if the only reason would be that downstream want's to remove it, well they should change it in downstream as well. But in this case I thing that it's time to move to Q35 as a default machine type, it's supported by majority of recent OSes and it would be sensible default. If some application/user depends on a specific machine type they should ask for it and most likely they are already doing it. We have a lot of attributes in our XML that are usually filled in by default and that default already depends on QEMU version or features that QEMU offers. Pavel
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
