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).
People not using libvirt use some or all of this
and other such functionality,
and changing the default might break things for them.
--
Eduardo