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

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

[Chao Peng]

Hi,
 
Q35 has been in QEMU for quite a while. Compared to the current default
i440FX, Q35 is probably not that mature and not widely used, however in
some case, Q35 has advantages, for example, in supporting new features.
For instance, we have some features require PCI-e support which is only
available on Q35 and some others need it for EFI support. It is of
course not necessary to change it as the default but if more and more
features have dependencies on Q35 because of requiring much more modern
features then I think it may be worth to do so. In such case we can have
more people to use it and find problems we may know or not know. There
are certainly some drawbacks:
-        Compatibility: current code or script may need adjustment
-        Quality: we may suffer more bugs on Q35
 
Any thoughts?
 
Chao

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

[Thomas Huth]

 Hi,

On 05.07.2017 08:57, Chao Peng wrote:
> 
> Q35 has been in QEMU for quite a while. Compared to the current default
> i440FX, Q35 is probably not that mature and not widely used, however in
> some case, Q35 has advantages, for example, in supporting new features.
> For instance, we have some features require PCI-e support which is only
> available on Q35 and some others need it for EFI support. It is of
> course not necessary to change it as the default but if more and more
> features have dependencies on Q35 because of requiring much more modern
> features then I think it may be worth to do so. In such case we can have
> more people to use it and find problems we may know or not know.

Yes, IMHO at one point in time, we should switch the default machine
type to q35. The i440FX is really quite old...

> There are certainly some drawbacks:
> -        Compatibility: current code or script may need adjustment

That might be a real concern ... so I think a good point in time to
switch to the q35 machine type would be when we switch to the next major
version number of QEMU, i.e. when we switch to version 3.0. If the users
see a new major version number, they might be more willing to accept
such major changes (yeah, I know, we've discussed in the past that
version numbers are just numbers ... but still, there is some kind of
psychological aspect to this, too, I think)

> -        Quality: we may suffer more bugs on Q35

I hope that the q35 machine will become mature soon once it has been
made the default machine.

 Thomas

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

[Marcel Apfelbaum]

On 05/07/2017 11:14, Thomas Huth wrote:
>   Hi,
> 

Hi,

> On 05.07.2017 08:57, Chao Peng wrote:
>>
>> Q35 has been in QEMU for quite a while. Compared to the current default
>> i440FX, Q35 is probably not that mature and not widely used, however in
>> some case, Q35 has advantages, for example, in supporting new features.
>> For instance, we have some features require PCI-e support which is only
>> available on Q35 and some others need it for EFI support. It is of
>> course not necessary to change it as the default but if more and more
>> features have dependencies on Q35 because of requiring much more modern
>> features then I think it may be worth to do so. In such case we can have
>> more people to use it and find problems we may know or not know.
> 

Agreed

> Yes, IMHO at one point in time, we should switch the default machine
> type to q35.

+1

> The i440FX is really quite old...
> 
>> There are certainly some drawbacks:
>> -        Compatibility: current code or script may need adjustment
> 
> That might be a real concern ... 

I am not so sure about that. Developers working on upstream projects
should expect such changes and, for our case,
modifying the command line by adding "-M pc" should not be a big deal.

The upper layers should manage the defaults by themselves so
are not supposed to be affected.

> so I think a good point in time to
> switch to the q35 machine type would be when we switch to the next major
> version number of QEMU, i.e. when we switch to version 3.0.

It does seem a good opportunity.

  If the users
> see a new major version number, they might be more willing to accept
> such major changes (yeah, I know, we've discussed in the past that
> version numbers are just numbers ... but still, there is some kind of
> psychological aspect to this, too, I think)
> 
>> -        Quality: we may suffer more bugs on Q35
> > I hope that the q35 machine will become mature soon once it has been
> made the default machine.
>

It will certainly help, the question is the cost.
Exposing the bugs by having more developers working on Q35 looks
more like an opportunity then a "cost"  to me.

Thanks,
Marcel

>   Thomas
> 

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

[Eduardo Habkost]

On Wed, Jul 05, 2017 at 12:32:10PM +0300, Marcel Apfelbaum wrote:
> On 05/07/2017 11:14, Thomas Huth wrote:
> >   Hi,
> > 
> 
> Hi,
> 
> > On 05.07.2017 08:57, Chao Peng wrote:
> > > 
> > > Q35 has been in QEMU for quite a while. Compared to the current default
> > > i440FX, Q35 is probably not that mature and not widely used, however in
> > > some case, Q35 has advantages, for example, in supporting new features.
> > > For instance, we have some features require PCI-e support which is only
> > > available on Q35 and some others need it for EFI support. It is of
> > > course not necessary to change it as the default but if more and more
> > > features have dependencies on Q35 because of requiring much more modern
> > > features then I think it may be worth to do so. In such case we can have
> > > more people to use it and find problems we may know or not know.
> > 
> 
> Agreed
> 
> > Yes, IMHO at one point in time, we should switch the default machine
> > type to q35.
> 
> +1
> 
> > The i440FX is really quite old...
> > 
> > > There are certainly some drawbacks:
> > > -        Compatibility: current code or script may need adjustment
> > 
> > That might be a real concern ...
> 
> I am not so sure about that. Developers working on upstream projects
> should expect such changes and, for our case,
> modifying the command line by adding "-M pc" should not be a big deal.

We could print a warning for 1 or 2 releases when users don't add
a explicit "-M pc" or "-M q35" argument to qemu-system-x86_64,
but:

> 
> 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.


> [...]

-- 
Eduardo

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

[Michael S. Tsirkin]

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:
> > On 05/07/2017 11:14, Thomas Huth wrote:
> > >   Hi,
> > > 
> > 
> > Hi,
> > 
> > > On 05.07.2017 08:57, Chao Peng wrote:
> > > > 
> > > > Q35 has been in QEMU for quite a while. Compared to the current default
> > > > i440FX, Q35 is probably not that mature and not widely used, however in
> > > > some case, Q35 has advantages, for example, in supporting new features.
> > > > For instance, we have some features require PCI-e support which is only
> > > > available on Q35 and some others need it for EFI support. It is of
> > > > course not necessary to change it as the default but if more and more
> > > > features have dependencies on Q35 because of requiring much more modern
> > > > features then I think it may be worth to do so. In such case we can have
> > > > more people to use it and find problems we may know or not know.
> > > 
> > 
> > Agreed
> > 
> > > Yes, IMHO at one point in time, we should switch the default machine
> > > type to q35.
> > 
> > +1
> > 
> > > The i440FX is really quite old...
> > > 
> > > > There are certainly some drawbacks:
> > > > -        Compatibility: current code or script may need adjustment
> > > 
> > > That might be a real concern ...
> > 
> > I am not so sure about that. Developers working on upstream projects
> > should expect such changes and, for our case,
> > modifying the command line by adding "-M pc" should not be a big deal.
> 
> We could print a warning for 1 or 2 releases when users don't add
> a explicit "-M pc" or "-M q35" argument to qemu-system-x86_64,
> but:
> 
> > 
> > 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?

This way no existing users will be affected.

> 
> > [...]
> 
> -- 
> Eduardo

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

[Eduardo Habkost]

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:
> > > On 05/07/2017 11:14, Thomas Huth wrote:
> > > >   Hi,
> > > > 
> > > 
> > > Hi,
> > > 
> > > > On 05.07.2017 08:57, Chao Peng wrote:
> > > > > 
> > > > > Q35 has been in QEMU for quite a while. Compared to the current default
> > > > > i440FX, Q35 is probably not that mature and not widely used, however in
> > > > > some case, Q35 has advantages, for example, in supporting new features.
> > > > > For instance, we have some features require PCI-e support which is only
> > > > > available on Q35 and some others need it for EFI support. It is of
> > > > > course not necessary to change it as the default but if more and more
> > > > > features have dependencies on Q35 because of requiring much more modern
> > > > > features then I think it may be worth to do so. In such case we can have
> > > > > more people to use it and find problems we may know or not know.
> > > > 
> > > 
> > > Agreed
> > > 
> > > > Yes, IMHO at one point in time, we should switch the default machine
> > > > type to q35.
> > > 
> > > +1
> > > 
> > > > The i440FX is really quite old...
> > > > 
> > > > > There are certainly some drawbacks:
> > > > > -        Compatibility: current code or script may need adjustment
> > > > 
> > > > That might be a real concern ...
> > > 
> > > I am not so sure about that. Developers working on upstream projects
> > > should expect such changes and, for our case,
> > > modifying the command line by adding "-M pc" should not be a big deal.
> > 
> > We could print a warning for 1 or 2 releases when users don't add
> > a explicit "-M pc" or "-M q35" argument to qemu-system-x86_64,
> > but:
> > 
> > > 
> > > 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".

-- 
Eduardo

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

[Marcel Apfelbaum]

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:
>>>> On 05/07/2017 11:14, Thomas Huth wrote:
>>>>>    Hi,
>>>>>
>>>>
>>>> Hi,
>>>>
>>>>> On 05.07.2017 08:57, Chao Peng wrote:
>>>>>>
>>>>>> Q35 has been in QEMU for quite a while. Compared to the current default
>>>>>> i440FX, Q35 is probably not that mature and not widely used, however in
>>>>>> some case, Q35 has advantages, for example, in supporting new features.
>>>>>> For instance, we have some features require PCI-e support which is only
>>>>>> available on Q35 and some others need it for EFI support. It is of
>>>>>> course not necessary to change it as the default but if more and more
>>>>>> features have dependencies on Q35 because of requiring much more modern
>>>>>> features then I think it may be worth to do so. In such case we can have
>>>>>> more people to use it and find problems we may know or not know.
>>>>>
>>>>
>>>> Agreed
>>>>
>>>>> Yes, IMHO at one point in time, we should switch the default machine
>>>>> type to q35.
>>>>
>>>> +1
>>>>
>>>>> The i440FX is really quite old...
>>>>>
>>>>>> There are certainly some drawbacks:
>>>>>> -        Compatibility: current code or script may need adjustment
>>>>>
>>>>> That might be a real concern ...
>>>>
>>>> I am not so sure about that. Developers working on upstream projects
>>>> should expect such changes and, for our case,
>>>> modifying the command line by adding "-M pc" should not be a big deal.
>>>
>>> We could print a warning for 1 or 2 releases when users don't add
>>> a explicit "-M pc" or "-M q35" argument to qemu-system-x86_64,
>>> but:
>>>

Hi Eduardo,

>>>>
>>>> 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.

Thanks,
Marcel




> 

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

[Paolo Bonzini]

On 10/07/2017 09:42, Marcel Apfelbaum wrote:
>>>>
>>>
>>> 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.

That would be libosinfo.

Paolo

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

[Eduardo Habkost]

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

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

[Michael S. Tsirkin]

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.

People not using libvirt use some or all of this
and other such functionality,
and changing the default might break things for them.

-- 
MST

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

[Eduardo Habkost]

(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

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

[Thomas Huth]

On 10.07.2017 19:47, Eduardo Habkost wrote:
> (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).

Agreed, it does not make much sense to invent a new mechanism here. I
guess the default should rather be switched in the the tools that create
the XML for libvirt, i.e. virt-install and friends?

Concerning QEMU, could we maybe simply emit a warning a la

 "you did not specify a machine type with the -M option, so you are
  currently running the the 'pc' machine type. Please note that future
  versions of QEMU might use the 'q35' machine type instead. If you
  require the 'pc' machine type for your setting, then please specify
  it with the -M option."

for a couple of releases, so that other people have a chance to update
their scripts, and then finally switch to q35 ?

 Thomas

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

[Marcel Apfelbaum]

On 11/07/2017 10:48, Thomas Huth wrote:
> On 10.07.2017 19:47, Eduardo Habkost wrote:
>> (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).
>

Hi Thomas,

> Agreed, it does not make much sense to invent a new mechanism here. I
> guess the default should rather be switched in the the tools that create
> the XML for libvirt, i.e. virt-install and friends?
> 
> Concerning QEMU, could we maybe simply emit a warning a la
> 
>   "you did not specify a machine type with the -M option, so you are
>    currently running the the 'pc' machine type. Please note that future
>    versions of QEMU might use the 'q35' machine type instead. If you
>    require the 'pc' machine type for your setting, then please specify
>    it with the -M option."
> 
> for a couple of releases, so that other people have a chance to update
> their scripts, and then finally switch to q35 ?
> 

Sounds like a plan, adding Laine (libvirt) to confirm (or not)
if makes sense.

Is a pity to loose the "QEMU 3.0" release, but is nicer indeed
to let people know in advance.

Thanks,
Marcel

>   Thomas
> 

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

[Gerd Hoffmann]

  Hi,

> Concerning QEMU, could we maybe simply emit a warning a la
> 
>  "you did not specify a machine type with the -M option, so you are
>   currently running the the 'pc' machine type. Please note that
> future
>   versions of QEMU might use the 'q35' machine type instead. If you
>   require the 'pc' machine type for your setting, then please specify
>   it with the -M option."

Warnings tend to get ignored until things are actually break, so I
don't think this helps much.  I think simply not having a default
machine type (as already suggested elsewhere in this thread) is the
best way to deal with this.  That way we don't silently change
behavior.  It also is in line with what we have on arm where we already
require the user to explicitly pick a machine type.

We probably want a more verbose error message on x86 though, suggesting
to pick 'pc' for compatibility with old qemu versions and for old
guests, and q35 otherwise.

cheers,
  Gerd

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

[Kevin Wolf]

Am 11.07.2017 um 10:13 hat Gerd Hoffmann geschrieben:
>   Hi,
> 
> > Concerning QEMU, could we maybe simply emit a warning a la
> > 
> >  "you did not specify a machine type with the -M option, so you are
> >   currently running the the 'pc' machine type. Please note that
> > future
> >   versions of QEMU might use the 'q35' machine type instead. If you
> >   require the 'pc' machine type for your setting, then please specify
> >   it with the -M option."
> 
> Warnings tend to get ignored until things are actually break, so I
> don't think this helps much.  I think simply not having a default
> machine type (as already suggested elsewhere in this thread) is the
> best way to deal with this.

I would absolutely hate this. One of the nice things about qemu has
always been that 'qemu disk.img' is enough to start a simple VM. You
only need to touch any other options for things you care about. I
wouldn't want to give this up.

Kevin

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

[Paolo Bonzini]

On 11/07/2017 16:42, Kevin Wolf wrote:
>>>  Concerning QEMU, could we maybe simply emit a warning a la
>>>
>>>  "you did not specify a machine type with the -M option, so you are
>>>   currently running the the 'pc' machine type. Please note that
>>> future
>>>   versions of QEMU might use the 'q35' machine type instead. If you
>>>   require the 'pc' machine type for your setting, then please specify
>>>   it with the -M option."
>> Warnings tend to get ignored until things are actually break, so I
>> don't think this helps much.  I think simply not having a default
>> machine type (as already suggested elsewhere in this thread) is the
>> best way to deal with this.
> I would absolutely hate this. One of the nice things about qemu has
> always been that 'qemu disk.img' is enough to start a simple VM. You
> only need to touch any other options for things you care about. I
> wouldn't want to give this up.

I agree.  Don't change anything, leave "-M pc" aside, and let libosinfo
pick q35 for newer guests.

Paolo

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

[Marcel Apfelbaum]

On 11/07/2017 17:47, Paolo Bonzini wrote:
> On 11/07/2017 16:42, Kevin Wolf wrote:
>>>>   Concerning QEMU, could we maybe simply emit a warning a la
>>>>
>>>>   "you did not specify a machine type with the -M option, so you are
>>>>    currently running the the 'pc' machine type. Please note that
>>>> future
>>>>    versions of QEMU might use the 'q35' machine type instead. If you
>>>>    require the 'pc' machine type for your setting, then please specify
>>>>    it with the -M option."
>>> Warnings tend to get ignored until things are actually break, so I
>>> don't think this helps much.  I think simply not having a default
>>> machine type (as already suggested elsewhere in this thread) is the
>>> best way to deal with this.
>> I would absolutely hate this. One of the nice things about qemu has
>> always been that 'qemu disk.img' is enough to start a simple VM. You
>> only need to touch any other options for things you care about. I
>> wouldn't want to give this up.
> 
> I agree.  Don't change anything, leave "-M pc" aside, and let libosinfo
> pick q35 for newer guests.
> 

Hi Paolo,

While I do think it would be a good step moving forward, I am not
convinced is "enough" to get more users using it. More so, a low
level bug in upper layers (e.g. Open stack) will lead to difficulty
to debug and result in the same "The machine is not steady enough,
it doesn't worth the effort, let's move back to pc", or even
frustration of the people that really need Q35.

IMHO we need to find a way to let more users use Q35 by default
and make an effort to fix the possible issues before.


Thanks,
Marcel


> Paolo
> 

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

[Eduardo Habkost]

On Wed, Jul 12, 2017 at 09:39:39AM +0300, Marcel Apfelbaum wrote:
> On 11/07/2017 17:47, Paolo Bonzini wrote:
> > On 11/07/2017 16:42, Kevin Wolf wrote:
> > > > >   Concerning QEMU, could we maybe simply emit a warning a la
> > > > > 
> > > > >   "you did not specify a machine type with the -M option, so you are
> > > > >    currently running the the 'pc' machine type. Please note that
> > > > > future
> > > > >    versions of QEMU might use the 'q35' machine type instead. If you
> > > > >    require the 'pc' machine type for your setting, then please specify
> > > > >    it with the -M option."
> > > > Warnings tend to get ignored until things are actually break, so I
> > > > don't think this helps much.  I think simply not having a default
> > > > machine type (as already suggested elsewhere in this thread) is the
> > > > best way to deal with this.
> > > I would absolutely hate this. One of the nice things about qemu has
> > > always been that 'qemu disk.img' is enough to start a simple VM. You
> > > only need to touch any other options for things you care about. I
> > > wouldn't want to give this up.
> > 
> > I agree.  Don't change anything, leave "-M pc" aside, and let libosinfo
> > pick q35 for newer guests.
> > 
> 
> Hi Paolo,
> 
> While I do think it would be a good step moving forward, I am not
> convinced is "enough" to get more users using it. More so, a low
> level bug in upper layers (e.g. Open stack) will lead to difficulty
> to debug and result in the same "The machine is not steady enough,
> it doesn't worth the effort, let's move back to pc", or even
> frustration of the people that really need Q35.

I guess not being enough depends on which users we want to
affect.  People who run QEMU from the command-line don't get a
virtio drive or a modern CPU model chosen by default, either.  Is
the choice of machine-type different?  Why?

> [...]

-- 
Eduardo

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

[Gerd Hoffmann]

  Hi,

> > I think simply not having a default
> > machine type (as already suggested elsewhere in this thread) is the
> > best way to deal with this.
> 
> I would absolutely hate this. One of the nice things about qemu has
> always been that 'qemu disk.img' is enough to start a simple VM.

Well, not really.  There is no "qemu" any more, and there are other
defaults like default memory size which need tweaks, so the minimum
command line isn't that short any more and looks more like this:

    qemu-system-x86_64 -enable-kvm -m 1G disk.img

cheers,
  Gerd

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

[Marcel Apfelbaum]

On 12/07/2017 8:51, Gerd Hoffmann wrote:
>    Hi,
>

Hi,

>>> I think simply not having a default
>>> machine type (as already suggested elsewhere in this thread) is the
>>> best way to deal with this.
>>
>> I would absolutely hate this. One of the nice things about qemu has
>> always been that 'qemu disk.img' is enough to start a simple VM.
> 
> Well, not really.  There is no "qemu" any more, and there are other
> defaults like default memory size which need tweaks, so the minimum
> command line isn't that short any more and looks more like this:
> 
>      qemu-system-x86_64 -enable-kvm -m 1G disk.img
>

If the command line is the main concern, I don't think is
enough to be the reason not to switch the default.
We can work on achieving the same/close with Q35.

Thanks,
Marcel


> cheers,
>    Gerd
> 

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

[Kevin Wolf]

Am 12.07.2017 um 07:51 hat Gerd Hoffmann geschrieben:
> > > I think simply not having a default
> > > machine type (as already suggested elsewhere in this thread) is the
> > > best way to deal with this.
> > 
> > I would absolutely hate this. One of the nice things about qemu has
> > always been that 'qemu disk.img' is enough to start a simple VM.
> 
> Well, not really.  There is no "qemu" any more, and there are other
> defaults like default memory size which need tweaks, so the minimum
> command line isn't that short any more and looks more like this:
> 
>     qemu-system-x86_64 -enable-kvm -m 1G disk.img

Depends on what you want to do, but in the common case yes. So we have
already moved in the wrong direction. Not a good reason to do more of
it.

Actually, I think changing the defaults to -m 1G and -machine
accel=kvm:tcg would be much less problematic than -M q35, so maybe that
should be our first step towards better defaults. (Or at least something
to schedule for 3.0.)

And even changing the default to -M q35, however problematic, would
still be nicer than making -M non-optional.

Kevin

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

[Eduardo Habkost]

On Tue, Jul 11, 2017 at 10:13:05AM +0200, Gerd Hoffmann wrote:
>   Hi,
> 
> > Concerning QEMU, could we maybe simply emit a warning a la
> > 
> >  "you did not specify a machine type with the -M option, so you are
> >   currently running the the 'pc' machine type. Please note that
> > future
> >   versions of QEMU might use the 'q35' machine type instead. If you
> >   require the 'pc' machine type for your setting, then please specify
> >   it with the -M option."
> 
> Warnings tend to get ignored until things are actually break, so I
> don't think this helps much.  I think simply not having a default
> machine type (as already suggested elsewhere in this thread) is the
> best way to deal with this.  That way we don't silently change
> behavior.  It also is in line with what we have on arm where we already
> require the user to explicitly pick a machine type.

If we do that, we probably should wait for libvirt to adapt and
choose its own default.  Current libvirt would pick an arbitrary
machine-type (the first one in the query-machines list) as the
default.

-- 
Eduardo

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

[Daniel P. Berrange]

On Wed, Jul 05, 2017 at 10:14:23AM +0200, Thomas Huth wrote:
>  Hi,
> 
> On 05.07.2017 08:57, Chao Peng wrote:
> > 
> > Q35 has been in QEMU for quite a while. Compared to the current default
> > i440FX, Q35 is probably not that mature and not widely used, however in
> > some case, Q35 has advantages, for example, in supporting new features.
> > For instance, we have some features require PCI-e support which is only
> > available on Q35 and some others need it for EFI support. It is of
> > course not necessary to change it as the default but if more and more
> > features have dependencies on Q35 because of requiring much more modern
> > features then I think it may be worth to do so. In such case we can have
> > more people to use it and find problems we may know or not know.
> 
> Yes, IMHO at one point in time, we should switch the default machine
> type to q35. The i440FX is really quite old...
> 
> > There are certainly some drawbacks:
> > -        Compatibility: current code or script may need adjustment
> 
> That might be a real concern ... so I think a good point in time to
> switch to the q35 machine type would be when we switch to the next major
> version number of QEMU, i.e. when we switch to version 3.0. If the users
> see a new major version number, they might be more willing to accept
> such major changes (yeah, I know, we've discussed in the past that
> version numbers are just numbers ... but still, there is some kind of
> psychological aspect to this, too, I think)

Most users aren't even aware of version numbers of QEMU - they'll just
take whatever their distro has provided run it. The notion that their
latest distro version happened to pull in a "major" version instead of
previously pulling in a "minor" version is invisible to everyone,
except the minority of people who care about the low level details.

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 :|

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

[Thomas Huth]

On 05.07.2017 13:07, Daniel P. Berrange wrote:
> On Wed, Jul 05, 2017 at 10:14:23AM +0200, Thomas Huth wrote:
>>  Hi,
>>
>> On 05.07.2017 08:57, Chao Peng wrote:
>>>
>>> Q35 has been in QEMU for quite a while. Compared to the current default
>>> i440FX, Q35 is probably not that mature and not widely used, however in
>>> some case, Q35 has advantages, for example, in supporting new features.
>>> For instance, we have some features require PCI-e support which is only
>>> available on Q35 and some others need it for EFI support. It is of
>>> course not necessary to change it as the default but if more and more
>>> features have dependencies on Q35 because of requiring much more modern
>>> features then I think it may be worth to do so. In such case we can have
>>> more people to use it and find problems we may know or not know.
>>
>> Yes, IMHO at one point in time, we should switch the default machine
>> type to q35. The i440FX is really quite old...
>>
>>> There are certainly some drawbacks:
>>> -        Compatibility: current code or script may need adjustment
>>
>> That might be a real concern ... so I think a good point in time to
>> switch to the q35 machine type would be when we switch to the next major
>> version number of QEMU, i.e. when we switch to version 3.0. If the users
>> see a new major version number, they might be more willing to accept
>> such major changes (yeah, I know, we've discussed in the past that
>> version numbers are just numbers ... but still, there is some kind of
>> psychological aspect to this, too, I think)
> 
> Most users aren't even aware of version numbers of QEMU - they'll just
> take whatever their distro has provided run it. The notion that their
> latest distro version happened to pull in a "major" version instead of
> previously pulling in a "minor" version is invisible to everyone,
> except the minority of people who care about the low level details.

Well, but those users who do not care at all hopefully use libvirt,
GNOME boxes or a similar management layer to start their virtual
machines, so it should not matter for them at all.

 Thomas

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

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 2471 bytes --]

On Wed, Jul 05, 2017 at 12:07:57PM +0100, Daniel P. Berrange wrote:
> On Wed, Jul 05, 2017 at 10:14:23AM +0200, Thomas Huth wrote:
> >  Hi,
> > 
> > On 05.07.2017 08:57, Chao Peng wrote:
> > > 
> > > Q35 has been in QEMU for quite a while. Compared to the current default
> > > i440FX, Q35 is probably not that mature and not widely used, however in
> > > some case, Q35 has advantages, for example, in supporting new features.
> > > For instance, we have some features require PCI-e support which is only
> > > available on Q35 and some others need it for EFI support. It is of
> > > course not necessary to change it as the default but if more and more
> > > features have dependencies on Q35 because of requiring much more modern
> > > features then I think it may be worth to do so. In such case we can have
> > > more people to use it and find problems we may know or not know.
> > 
> > Yes, IMHO at one point in time, we should switch the default machine
> > type to q35. The i440FX is really quite old...
> > 
> > > There are certainly some drawbacks:
> > > -        Compatibility: current code or script may need adjustment
> > 
> > That might be a real concern ... so I think a good point in time to
> > switch to the q35 machine type would be when we switch to the next major
> > version number of QEMU, i.e. when we switch to version 3.0. If the users
> > see a new major version number, they might be more willing to accept
> > such major changes (yeah, I know, we've discussed in the past that
> > version numbers are just numbers ... but still, there is some kind of
> > psychological aspect to this, too, I think)
> 
> Most users aren't even aware of version numbers of QEMU - they'll just
> take whatever their distro has provided run it. The notion that their
> latest distro version happened to pull in a "major" version instead of
> previously pulling in a "minor" version is invisible to everyone,
> except the minority of people who care about the low level details.

When user-visible changes break existing setups it's common for
packagers to ship a new family of packages that includes the major
version number (e.g. apache2, postgresql-9.6).

The last QEMU 2.x version would be considered stable and still available
from package repos.  Only critical bug and security fixes could be
released for another, say, 2 years.

This way users don't have to migrate to QEMU 3.x until they are ready.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

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

[Daniel P. Berrange]

On Thu, Jul 06, 2017 at 11:30:43AM +0100, Stefan Hajnoczi wrote:
> On Wed, Jul 05, 2017 at 12:07:57PM +0100, Daniel P. Berrange wrote:
> > On Wed, Jul 05, 2017 at 10:14:23AM +0200, Thomas Huth wrote:
> > >  Hi,
> > > 
> > > On 05.07.2017 08:57, Chao Peng wrote:
> > > > 
> > > > Q35 has been in QEMU for quite a while. Compared to the current default
> > > > i440FX, Q35 is probably not that mature and not widely used, however in
> > > > some case, Q35 has advantages, for example, in supporting new features.
> > > > For instance, we have some features require PCI-e support which is only
> > > > available on Q35 and some others need it for EFI support. It is of
> > > > course not necessary to change it as the default but if more and more
> > > > features have dependencies on Q35 because of requiring much more modern
> > > > features then I think it may be worth to do so. In such case we can have
> > > > more people to use it and find problems we may know or not know.
> > > 
> > > Yes, IMHO at one point in time, we should switch the default machine
> > > type to q35. The i440FX is really quite old...
> > > 
> > > > There are certainly some drawbacks:
> > > > -        Compatibility: current code or script may need adjustment
> > > 
> > > That might be a real concern ... so I think a good point in time to
> > > switch to the q35 machine type would be when we switch to the next major
> > > version number of QEMU, i.e. when we switch to version 3.0. If the users
> > > see a new major version number, they might be more willing to accept
> > > such major changes (yeah, I know, we've discussed in the past that
> > > version numbers are just numbers ... but still, there is some kind of
> > > psychological aspect to this, too, I think)
> > 
> > Most users aren't even aware of version numbers of QEMU - they'll just
> > take whatever their distro has provided run it. The notion that their
> > latest distro version happened to pull in a "major" version instead of
> > previously pulling in a "minor" version is invisible to everyone,
> > except the minority of people who care about the low level details.
> 
> When user-visible changes break existing setups it's common for
> packagers to ship a new family of packages that includes the major
> version number (e.g. apache2, postgresql-9.6).
> 
> The last QEMU 2.x version would be considered stable and still available
> from package repos.  Only critical bug and security fixes could be
> released for another, say, 2 years.
> 
> This way users don't have to migrate to QEMU 3.x until they are ready.

Given the number of security vulnerabilities packagers have to deal with
for QEMU, maintaining multiple QEMU streams in parallel is a pretty
major undertaking. I can't say that would be appealing from a Fedora
maintainer POV - it'd likely just end up shipping only the newest version
to avoid that extra maint burden. I doubt enterprise distros would ship
both versions in parallel in this way [1].

Even if both versions are available, the people affected by the breakage
still need to figure out that the breakage they're seeing is caused by
the change in machine type, and that installing the old version will
fix it. This is still an unpleasant experiance IMHO. 

Regards,
Daniel

[1] RHEL does already ship 2 QEMU streams in parallel, but they are
    differentiated for other reasons, one being a feature limited
    version of the other, and not as frequently rebased.
-- 
|: 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 :|

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

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 3579 bytes --]

On Thu, Jul 06, 2017 at 11:41:56AM +0100, Daniel P. Berrange wrote:
> On Thu, Jul 06, 2017 at 11:30:43AM +0100, Stefan Hajnoczi wrote:
> > On Wed, Jul 05, 2017 at 12:07:57PM +0100, Daniel P. Berrange wrote:
> > > On Wed, Jul 05, 2017 at 10:14:23AM +0200, Thomas Huth wrote:
> > > >  Hi,
> > > > 
> > > > On 05.07.2017 08:57, Chao Peng wrote:
> > > > > 
> > > > > Q35 has been in QEMU for quite a while. Compared to the current default
> > > > > i440FX, Q35 is probably not that mature and not widely used, however in
> > > > > some case, Q35 has advantages, for example, in supporting new features.
> > > > > For instance, we have some features require PCI-e support which is only
> > > > > available on Q35 and some others need it for EFI support. It is of
> > > > > course not necessary to change it as the default but if more and more
> > > > > features have dependencies on Q35 because of requiring much more modern
> > > > > features then I think it may be worth to do so. In such case we can have
> > > > > more people to use it and find problems we may know or not know.
> > > > 
> > > > Yes, IMHO at one point in time, we should switch the default machine
> > > > type to q35. The i440FX is really quite old...
> > > > 
> > > > > There are certainly some drawbacks:
> > > > > -        Compatibility: current code or script may need adjustment
> > > > 
> > > > That might be a real concern ... so I think a good point in time to
> > > > switch to the q35 machine type would be when we switch to the next major
> > > > version number of QEMU, i.e. when we switch to version 3.0. If the users
> > > > see a new major version number, they might be more willing to accept
> > > > such major changes (yeah, I know, we've discussed in the past that
> > > > version numbers are just numbers ... but still, there is some kind of
> > > > psychological aspect to this, too, I think)
> > > 
> > > Most users aren't even aware of version numbers of QEMU - they'll just
> > > take whatever their distro has provided run it. The notion that their
> > > latest distro version happened to pull in a "major" version instead of
> > > previously pulling in a "minor" version is invisible to everyone,
> > > except the minority of people who care about the low level details.
> > 
> > When user-visible changes break existing setups it's common for
> > packagers to ship a new family of packages that includes the major
> > version number (e.g. apache2, postgresql-9.6).
> > 
> > The last QEMU 2.x version would be considered stable and still available
> > from package repos.  Only critical bug and security fixes could be
> > released for another, say, 2 years.
> > 
> > This way users don't have to migrate to QEMU 3.x until they are ready.
> 
> Given the number of security vulnerabilities packagers have to deal with
> for QEMU, maintaining multiple QEMU streams in parallel is a pretty
> major undertaking. I can't say that would be appealing from a Fedora
> maintainer POV - it'd likely just end up shipping only the newest version
> to avoid that extra maint burden. I doubt enterprise distros would ship
> both versions in parallel in this way [1].
> 
> Even if both versions are available, the people affected by the breakage
> still need to figure out that the breakage they're seeing is caused by
> the change in machine type, and that installing the old version will
> fix it. This is still an unpleasant experiance IMHO. 

True, package naming doesn't provide an upgrade path.  That will still
be painful.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

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

[Laszlo Ersek]

On 07/05/17 08:57, Chao Peng wrote:
> Hi,
>  
> Q35 has been in QEMU for quite a while. Compared to the current default
> i440FX, Q35 is probably not that mature and not widely used, however in
> some case, Q35 has advantages, for example, in supporting new features.
> For instance, we have some features require PCI-e support which is only
> available on Q35 and some others need it for EFI support.

To be a bit more precise: OVMF's default upstream build works fine with
i440fx. But, if you build OVMF with "-D SMM_REQUIRE" -- which is
required for making "-D SECURE_BOOT_ENABLE" actually secure --, then you
do need q35 (the firmware binary won't even boot on i440fx past a
certain point), because only q35 provides SMM emulation.

Thanks
Laszlo

> It is of
> course not necessary to change it as the default but if more and more
> features have dependencies on Q35 because of requiring much more modern
> features then I think it may be worth to do so. In such case we can have
> more people to use it and find problems we may know or not know. There
> are certainly some drawbacks:
> -        Compatibility: current code or script may need adjustment
> -        Quality: we may suffer more bugs on Q35
>  
> Any thoughts?
>  
> Chao
> 

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

[Daniel P. Berrange]

On Wed, Jul 05, 2017 at 02:57:56PM +0800, Chao Peng wrote:
> Hi,
>  
> Q35 has been in QEMU for quite a while. Compared to the current default
> i440FX, Q35 is probably not that mature and not widely used, however in
> some case, Q35 has advantages, for example, in supporting new features.
> For instance, we have some features require PCI-e support which is only
> available on Q35 and some others need it for EFI support. It is of
> course not necessary to change it as the default but if more and more
> features have dependencies on Q35 because of requiring much more modern
> features then I think it may be worth to do so. In such case we can have
> more people to use it and find problems we may know or not know. There
> are certainly some drawbacks:
> -        Compatibility: current code or script may need adjustment
> -        Quality: we may suffer more bugs on Q35
> 
> Any thoughts?

Changing the default machine will certainly break a large number of
apps / scripts / users of QEMU because it completely changes the ABI
exposed to guest OS. It will also invalidate documentation about
QEMU usage across countless websites / source repos.

If you're lucky QEMU may immediately fail to start because a command
line argument refers to some property / device that exists by default
in PIIX, but not in Q35.

If you're unlucky QEMU will successfully start, but expose a different
ABI to the guest. This will cause Windows guests to trigger license
reactivation. It will cause QEMU to fail to load any previously saved
snapshots, and will fail to process incoming migration.

Then there is the fact that some guest OS may not work with the chipset
exposed by Q35.

While you can say people should just add '-M pc' that isn't a nice
user experiance, because it makes the assumption that people actually
understand what caused their breakage. When the incompatibilities
arise the error messages are unlikely to give any hint to users that
the problems are caused by the machine type change. So unless someone
is very familiar with debugging QEMU, they're not going to realize
that '-M pc' will fix their problem. Documentation assuming the old
defaults will live on forever, meaning users suffer from the change
in defaults for years, probably decades into the future.

All these problems can be avoided if the change in defaults in done by
higher level applications. For example, OpenStack/oVirt know what guest
OS is being deployed, so they can intelligently choose between either
Q35 or PIIX4, depending on which the guest is known to work with. These
apps will also have a persistent record of full guest config (via libvirt)
to the change in defaults won't risk breaking existing deployed guests,
or their snapshots & ensure migration continues to work.

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 :|

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

[Fam Zheng]

On Wed, 07/05 12:04, Daniel P. Berrange wrote:
> While you can say people should just add '-M pc' that isn't a nice
> user experiance, because it makes the assumption that people actually
> understand what caused their breakage. When the incompatibilities
> arise the error messages are unlikely to give any hint to users that
> the problems are caused by the machine type change. So unless someone
> is very familiar with debugging QEMU, they're not going to realize
> that '-M pc' will fix their problem.

While we change the default, can we start to print a message like 'machine type
("-M" option) not specified, default to Q35. If you find compatibility issues,
try "-M pc"'?

Fam

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

[Thomas Huth]

On 05.07.2017 13:44, Fam Zheng wrote:
> On Wed, 07/05 12:04, Daniel P. Berrange wrote:
>> While you can say people should just add '-M pc' that isn't a nice
>> user experiance, because it makes the assumption that people actually
>> understand what caused their breakage. When the incompatibilities
>> arise the error messages are unlikely to give any hint to users that
>> the problems are caused by the machine type change. So unless someone
>> is very familiar with debugging QEMU, they're not going to realize
>> that '-M pc' will fix their problem.
> 
> While we change the default, can we start to print a message like 'machine type
> ("-M" option) not specified, default to Q35. If you find compatibility issues,
> try "-M pc"'?

Or we could simply remove the default machine type completely for a
couple of releases? That would force people to update their script with
"-M pc" ... and once this has been established, we can finally make q35
the default?

 Thomas

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

[Fam Zheng]

On Wed, 07/05 13:58, Thomas Huth wrote:
> On 05.07.2017 13:44, Fam Zheng wrote:
> > On Wed, 07/05 12:04, Daniel P. Berrange wrote:
> >> While you can say people should just add '-M pc' that isn't a nice
> >> user experiance, because it makes the assumption that people actually
> >> understand what caused their breakage. When the incompatibilities
> >> arise the error messages are unlikely to give any hint to users that
> >> the problems are caused by the machine type change. So unless someone
> >> is very familiar with debugging QEMU, they're not going to realize
> >> that '-M pc' will fix their problem.
> > 
> > While we change the default, can we start to print a message like 'machine type
> > ("-M" option) not specified, default to Q35. If you find compatibility issues,
> > try "-M pc"'?
> 
> Or we could simply remove the default machine type completely for a
> couple of releases? That would force people to update their script with
> "-M pc" ... and once this has been established, we can finally make q35
> the default?

I wouldn't do that.. Defaults are for those who don't care about setting it, or
want something that just works, by default. It's fine not to provide a default
machine type if we decide there isn't a clear win, just like arm, but IMHO
removing it just to restore it later in order to educate people makes a very
poor experience.

Fam

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

[Daniel P. Berrange]

On Wed, Jul 05, 2017 at 08:22:00PM +0800, Fam Zheng wrote:
> On Wed, 07/05 13:58, Thomas Huth wrote:
> > On 05.07.2017 13:44, Fam Zheng wrote:
> > > On Wed, 07/05 12:04, Daniel P. Berrange wrote:
> > >> While you can say people should just add '-M pc' that isn't a nice
> > >> user experiance, because it makes the assumption that people actually
> > >> understand what caused their breakage. When the incompatibilities
> > >> arise the error messages are unlikely to give any hint to users that
> > >> the problems are caused by the machine type change. So unless someone
> > >> is very familiar with debugging QEMU, they're not going to realize
> > >> that '-M pc' will fix their problem.
> > > 
> > > While we change the default, can we start to print a message like 'machine type
> > > ("-M" option) not specified, default to Q35. If you find compatibility issues,
> > > try "-M pc"'?
> > 
> > Or we could simply remove the default machine type completely for a
> > couple of releases? That would force people to update their script with
> > "-M pc" ... and once this has been established, we can finally make q35
> > the default?
> 
> I wouldn't do that.. Defaults are for those who don't care about setting it, or
> want something that just works, by default. It's fine not to provide a default
> machine type if we decide there isn't a clear win, just like arm, but IMHO
> removing it just to restore it later in order to educate people makes a very
> poor experience.

Since the idea of removing the default machine type was brought up, we should
perhaps consider that as a distinct solution. Going from using 'pc' by defailt
to having no default machine type, has significantly better user experiance
than changing the default machine to 'q35' IMHO.

eg if we killed the default, currently QEMU would say something like

   qemu-system-x86_64: No machine specified, and there is no default
   Use -machine help to list supported machines

We could augment that with further details:

   qemu-system-x86_64: No machine specified, and there is no default
   Use -machine help to list supported machines

   For compatibility with previous releases of QEMU, pick the 'pc'
   machine type. New deployments are suggested to use the 'q35'
   machine type.

This avoids the user having problems with guest ABI silently changing
behind their back, or migration suddenly failing to load vm state,
and gives them clear immediate guidance on how to resolve the problem
they're facing, as well as encouraging usage of 'q35' going forward,
without having to actually make it the default.

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 :|

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

[Peter Maydell]

On 6 July 2017 at 11:49, Daniel P. Berrange <berrange@redhat.com> wrote:
> eg if we killed the default, currently QEMU would say something like
>
>    qemu-system-x86_64: No machine specified, and there is no default
>    Use -machine help to list supported machines

Incidentally I really should get round to figuring out how to make
command lines like
 qemu-system-arm -device help
 qemu-system-arm -cpu help
work without the user having to specify "-M virt" too to avoid the
"no default machine" error taking precedence over the help output...

thanks
-- PMM

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

[Thomas Huth]

On 06.07.2017 12:49, Daniel P. Berrange wrote:
[...]
> This avoids the user having problems with guest ABI silently changing
> behind their back, or migration suddenly failing to load vm state,

For proper migration, you've got to specify the right versioned machine
type anyway, so that should not be an issue here.

 Thomas

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

[Daniel P. Berrange]

On Thu, Jul 06, 2017 at 01:00:53PM +0200, Thomas Huth wrote:
> On 06.07.2017 12:49, Daniel P. Berrange wrote:
> [...]
> > This avoids the user having problems with guest ABI silently changing
> > behind their back, or migration suddenly failing to load vm state,
> 
> For proper migration, you've got to specify the right versioned machine
> type anyway, so that should not be an issue here.

That's only true if you have mis-matched QEMU releases on each host.
If you know you have the same QEMU release everywhere, there's no
need for versioned machine types. Though obviously we'd still recommend
people us versioned machine type, its not unreasonable that some people
will not

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 :|

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

[Thomas Huth]

On 06.07.2017 13:06, Daniel P. Berrange wrote:
> On Thu, Jul 06, 2017 at 01:00:53PM +0200, Thomas Huth wrote:
>> On 06.07.2017 12:49, Daniel P. Berrange wrote:
>> [...]
>>> This avoids the user having problems with guest ABI silently changing
>>> behind their back, or migration suddenly failing to load vm state,
>>
>> For proper migration, you've got to specify the right versioned machine
>> type anyway, so that should not be an issue here.
> 
> That's only true if you have mis-matched QEMU releases on each host.
> If you know you have the same QEMU release everywhere, there's no
> need for versioned machine types.
Sure, but in case you use the same QEMU release on both ends, there
should also be no clash with the default machine type here.

 Thomas

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

[Dr. David Alan Gilbert]

* Daniel P. Berrange (berrange@redhat.com) wrote:
> On Thu, Jul 06, 2017 at 01:00:53PM +0200, Thomas Huth wrote:
> > On 06.07.2017 12:49, Daniel P. Berrange wrote:
> > [...]
> > > This avoids the user having problems with guest ABI silently changing
> > > behind their back, or migration suddenly failing to load vm state,
> > 
> > For proper migration, you've got to specify the right versioned machine
> > type anyway, so that should not be an issue here.
> 
> That's only true if you have mis-matched QEMU releases on each host.
> If you know you have the same QEMU release everywhere, there's no
> need for versioned machine types. Though obviously we'd still recommend
> people us versioned machine type, its not unreasonable that some people
> will not

We have got protection against machine type screwups; e.g going from -M
pc to -M q35 we get:

qemu-system-x86_64: Machine type received is 'pc-i440fx-2.9' and local is 'pc-q35-2.9'

Dave

> 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 :|
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

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

[Eduardo Habkost]

On Thu, Jul 06, 2017 at 11:49:40AM +0100, Daniel P. Berrange wrote:
> On Wed, Jul 05, 2017 at 08:22:00PM +0800, Fam Zheng wrote:
> > On Wed, 07/05 13:58, Thomas Huth wrote:
> > > On 05.07.2017 13:44, Fam Zheng wrote:
> > > > On Wed, 07/05 12:04, Daniel P. Berrange wrote:
> > > >> While you can say people should just add '-M pc' that isn't a nice
> > > >> user experiance, because it makes the assumption that people actually
> > > >> understand what caused their breakage. When the incompatibilities
> > > >> arise the error messages are unlikely to give any hint to users that
> > > >> the problems are caused by the machine type change. So unless someone
> > > >> is very familiar with debugging QEMU, they're not going to realize
> > > >> that '-M pc' will fix their problem.
> > > > 
> > > > While we change the default, can we start to print a message like 'machine type
> > > > ("-M" option) not specified, default to Q35. If you find compatibility issues,
> > > > try "-M pc"'?
> > > 
> > > Or we could simply remove the default machine type completely for a
> > > couple of releases? That would force people to update their script with
> > > "-M pc" ... and once this has been established, we can finally make q35
> > > the default?
> > 
> > I wouldn't do that.. Defaults are for those who don't care about setting it, or
> > want something that just works, by default. It's fine not to provide a default
> > machine type if we decide there isn't a clear win, just like arm, but IMHO
> > removing it just to restore it later in order to educate people makes a very
> > poor experience.
> 
> Since the idea of removing the default machine type was brought up, we should
> perhaps consider that as a distinct solution. Going from using 'pc' by defailt
> to having no default machine type, has significantly better user experiance
> than changing the default machine to 'q35' IMHO.
> 
> eg if we killed the default, currently QEMU would say something like
> 
>    qemu-system-x86_64: No machine specified, and there is no default
>    Use -machine help to list supported machines
> 
> We could augment that with further details:
> 
>    qemu-system-x86_64: No machine specified, and there is no default
>    Use -machine help to list supported machines
> 
>    For compatibility with previous releases of QEMU, pick the 'pc'
>    machine type. New deployments are suggested to use the 'q35'
>    machine type.
> 
> This avoids the user having problems with guest ABI silently changing
> behind their back, or migration suddenly failing to load vm state,
> and gives them clear immediate guidance on how to resolve the problem
> they're facing, as well as encouraging usage of 'q35' going forward,
> without having to actually make it the default.

Won't this make things more fragile for libvirt, as it would
fallback to the first machine-type on the list?  If we
inadvertently change the order of the list in QEMU, it could
break users' setups.

Or it would be feasible for libvirt to also stop choosing a
default if there's no clear winner?

-- 
Eduardo

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

[Paolo Bonzini]

On 05/07/2017 13:58, Thomas Huth wrote:
> On 05.07.2017 13:44, Fam Zheng wrote:
>> On Wed, 07/05 12:04, Daniel P. Berrange wrote:
>>> While you can say people should just add '-M pc' that isn't a nice
>>> user experiance, because it makes the assumption that people actually
>>> understand what caused their breakage. When the incompatibilities
>>> arise the error messages are unlikely to give any hint to users that
>>> the problems are caused by the machine type change. So unless someone
>>> is very familiar with debugging QEMU, they're not going to realize
>>> that '-M pc' will fix their problem.
>>
>> While we change the default, can we start to print a message like 'machine type
>> ("-M" option) not specified, default to Q35. If you find compatibility issues,
>> try "-M pc"'?
> 
> Or we could simply remove the default machine type completely for a
> couple of releases? That would force people to update their script with
> "-M pc" ... and once this has been established, we can finally make q35
> the default?

Apart from the user experience issues pointed out by Fam, this would
lead to people using "-M pc" without understanding it, and not being
able to use q35 features.

I think there are two cases:

- if we are worried about command-line users' IDE VMs not booting after
the q35 upgrade (because the PATA adapter becomes SATA/AHCI), we cannot
change the default in QEMU, period.  This would affect at least Windows
VMs; Fedora and derivatives should have both ATA_PIIX and SATA_AHCI as
built-in drivers, I don't know about Debian derivatives and e.g. Gentoo.

- if we are not, and we think q35 is okay for every new VM except
Windows 95 or 2003, we can change the default to "-M q35".  Windows 95
and 2003 users can be asked to add "-M pc".

In the second case, libvirt could still switch from pc to q35 and/or
libosinfo could be changed to suggest q35 instead of pc.

If possible, NICs should keep the same PCI address after upgrade.

Paolo