(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). > People not using libvirt use some or all of this > and other such functionality, > and changing the default might break things for them. -- Eduardo -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
