Re: [libvirt] [Qemu-devel] change x86 default machine type to Q35?

(CCing libvir-list) On Mon, Jul 10, 2017 at 07:45:54PM +0300, Michael S. Tsirkin wrote: > On Mon, Jul 10, 2017 at 10:59:43AM -0300, Eduardo Habkost wrote: >> On Mon, Jul 10, 2017 at 10:42:26AM +0300, Marcel Apfelbaum wrote: >>> On 07/07/2017 21:03, Eduardo Habkost wrote: >>>> On Fri, Jul 07, 2017 at 06:17:57PM +0300, Michael S. Tsirkin wrote: >>>>> On Fri, Jul 07, 2017 at 10:39:49AM -0300, Eduardo Habkost wrote: >>>>>> On Wed, Jul 05, 2017 at 12:32:10PM +0300, Marcel Apfelbaum wrote: >> [...] >>>>>>> >>>>>>> The upper layers should manage the defaults by themselves so >>>>>>> are not supposed to be affected. >>>>>> >>>>>> But they would be. libvirt uses the default machine-type from >>>>>> QEMU. >>>>> >>>>> How about extending the command for supported machines with a >>>>> recommended machine type, and teaching libvirt to use that? >>>> >>>> I don't think QEMU has enough information to decide if it should >>>> recommend "q35" or "pc". >>> >>> We don't really need a complicated rule set, we would just recommend q35 >>> by default. Libvirt will try to create the default machine and if fails >>> for some reason (what would it be?) it can switch to PC. >>> >>> The advanced logic would be "old systems should use PC", where old >>> means Windows XP and before and so on. But this logic should appear >>> in management layers above. >> >> In this case, is there any difference between "changing the >> default to q35" and "recommending q35", for libvirt users? >> >> -- >> Eduardo > > No but libvirt users do not manage e.g. pci slots manually. > They do not use the -cdrom flag. > Etc. > So changing the default is unlikely to break things for them. > I see. If this part is really true (can libvirt developers confirm that?), then the proposed end result makes sense (not having a default for running QEMU directly, but changing default to "q35" for people using libvirt). But I don't see why we would need a new mechanism to make QEMU recommend a machine-type for libvirt, if libvirt could simply choose its own default (or maybe also refuse to pick a default, if libvirt developers decide that's the best solution).