On Wed, Jun 20, 2018 at 02:28:24PM -0300, Eduardo Habkost wrote: > On Mon, Jun 18, 2018 at 08:18:16PM +0300, Michael S. Tsirkin wrote: > > On Mon, Jun 18, 2018 at 02:14:31PM -0300, Eduardo Habkost wrote: > > > > Sure if someone does that, we'll have no choice, but as long as 'pc' is > > > > shipped we shouldn't gratuitously break apps by changing the default. > > > > > > Right. I just want to make sure "omitting the machine-type may > > > stop working in the future" is documented somehow. > > > > I still think we should just add links to the qemu binary and > > use ARGV to detect the machine type. > > > > qemu-pc-i386 > > qemu-q35-x86_64 > > Why having separate QEMU binaries would help? We still need to > define and document what will happen when both the machine-type > and the QEMU binary are omitted in the domain XML. It would not help libvirt at all, and in fact it would cause extra pain for applications, because we don't have ability to associated separate QEMU binaries with machine types in our capabilities design. So not only would libvirt need changing, but apps using libvirt too. > Personally I prefer to document this as "we recommend you always > specify the machine-type" instead of "we recommend you always > specify the QEMU binary path". Indeed, the former is something apps already do in many cases. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
