[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]