[RFC] hw/pc: set q35 as the default x86 machine

Moving to QEMU 3.0 seems like a good opportunity for such a change.

I440FX is really old and does not support modern features like IOMMU.
Q35's SATA emulation is faster than pc's IDE, native PCI express hotplug
is cleaner than ACPI based one and so on...

Also the libvirt guys added very good support for the Q35 machine (thanks!).

Management software should always specify the machine type and for the
current setups, adding '-machine pc' to the command line is not such a
big deal.

In time the pc machine will fade out and we will probably stop adding
new versions at some point.

Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
---
 hw/i386/pc_piix.c | 2 --
 hw/i386/pc_q35.c  | 2 ++
 2 files changed, 2 insertions(+), 2 deletions(-)

On Sun, Jun 03, 2018 at 12:27:49PM +0300, Marcel Apfelbaum wrote:
> Moving to QEMU 3.0 seems like a good opportunity for such a change.
> 
> I440FX is really old and does not support modern features like IOMMU.
> Q35's SATA emulation is faster than pc's IDE, native PCI express hotplug
> is cleaner than ACPI based one and so on...
> 
> Also the libvirt guys added very good support for the Q35 machine (thanks!).
> 
> Management software should always specify the machine type and for the
> current setups, adding '-machine pc' to the command line is not such a
> big deal.
> 
> In time the pc machine will fade out and we will probably stop adding
> new versions at some point.
> 
> Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>

For command line users, I think changing the default isn't nice.

Yes it's easy to add -machine pc but there's no documentation
that tells you to do so. Add to that shortcuts like -cdrom
stop working, hotplug needs extra bridges to work, and one
can see that while management tool users benefit from q35,
command line users will suffer.

Can't we add a tag for management without changing the command line
default? How about "management-default"? "recommended"? "latest"?

On Mon, 4 Jun 2018 04:38:22 +0300
"Michael S. Tsirkin" <mst@redhat.com> wrote:

> On Sun, Jun 03, 2018 at 12:27:49PM +0300, Marcel Apfelbaum wrote:
> > Moving to QEMU 3.0 seems like a good opportunity for such a change.
> > 
> > I440FX is really old and does not support modern features like IOMMU.
> > Q35's SATA emulation is faster than pc's IDE, native PCI express hotplug
> > is cleaner than ACPI based one and so on...
> > 
> > Also the libvirt guys added very good support for the Q35 machine (thanks!).
> > 
> > Management software should always specify the machine type and for the
> > current setups, adding '-machine pc' to the command line is not such a
> > big deal.
> > 
> > In time the pc machine will fade out and we will probably stop adding
> > new versions at some point.
> > 
> > Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>  
> 
> For command line users, I think changing the default isn't nice.
> 
> Yes it's easy to add -machine pc but there's no documentation
> that tells you to do so. Add to that shortcuts like -cdrom
> stop working, hotplug needs extra bridges to work, and one
> can see that while management tool users benefit from q35,
> command line users will suffer.
Maybe we should mark 'pc' default as deprecated first,
like we do with CLI options that we wish to drop in future?

That way we 'create' documentation, so users would be aware
of the change and have time to fix their CLI if they prefer
'pc' machine.


> Can't we add a tag for management without changing the command line
> default? How about "management-default"? "recommended"? "latest"?
>

On 04/06/2018 14:24, Igor Mammedov wrote:
>> Yes it's easy to add -machine pc but there's no documentation
>> that tells you to do so. Add to that shortcuts like -cdrom
>> stop working, hotplug needs extra bridges to work, and one
>> can see that while management tool users benefit from q35,
>> command line users will suffer.
> Maybe we should mark 'pc' default as deprecated first,
> like we do with CLI options that we wish to drop in future?
> 
> That way we 'create' documentation, so users would be aware
> of the change and have time to fix their CLI if they prefer
> 'pc' machine.

Michael has listed reasons why 'pc' cannot be deprecated, since some of
them are not even fixable.  Honestly, 'pc' works well for 99% of the use
cases---just like you probably don't care whether your laptop has a PCI
or PCIe chipset.

Paolo

On Mon, Jun 04, 2018 at 04:38:22AM +0300, Michael S. Tsirkin wrote:
> On Sun, Jun 03, 2018 at 12:27:49PM +0300, Marcel Apfelbaum wrote:
> > Moving to QEMU 3.0 seems like a good opportunity for such a change.
> > 
> > I440FX is really old and does not support modern features like IOMMU.
> > Q35's SATA emulation is faster than pc's IDE, native PCI express hotplug
> > is cleaner than ACPI based one and so on...
> > 
> > Also the libvirt guys added very good support for the Q35 machine (thanks!).
> > 
> > Management software should always specify the machine type and for the
> > current setups, adding '-machine pc' to the command line is not such a
> > big deal.
> > 
> > In time the pc machine will fade out and we will probably stop adding
> > new versions at some point.
> > 
> > Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
> 
> For command line users, I think changing the default isn't nice.
> 
> Yes it's easy to add -machine pc but there's no documentation
> that tells you to do so. Add to that shortcuts like -cdrom
> stop working, hotplug needs extra bridges to work, and one
> can see that while management tool users benefit from q35,
> command line users will suffer.
> 
> Can't we add a tag for management without changing the command line
> default? How about "management-default"? "recommended"? "latest"?

We could add new aliases if they are useful for management
software, but we would need a well-defined use case and set of
requirements+expectations for the new alias.

On Mon, Jun 04, 2018 at 09:54:15AM -0300, Eduardo Habkost wrote:
> On Mon, Jun 04, 2018 at 04:38:22AM +0300, Michael S. Tsirkin wrote:
> > On Sun, Jun 03, 2018 at 12:27:49PM +0300, Marcel Apfelbaum wrote:
> > > Moving to QEMU 3.0 seems like a good opportunity for such a change.
> > > 
> > > I440FX is really old and does not support modern features like IOMMU.
> > > Q35's SATA emulation is faster than pc's IDE, native PCI express hotplug
> > > is cleaner than ACPI based one and so on...
> > > 
> > > Also the libvirt guys added very good support for the Q35 machine (thanks!).
> > > 
> > > Management software should always specify the machine type and for the
> > > current setups, adding '-machine pc' to the command line is not such a
> > > big deal.
> > > 
> > > In time the pc machine will fade out and we will probably stop adding
> > > new versions at some point.
> > > 
> > > Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
> > 
> > For command line users, I think changing the default isn't nice.
> > 
> > Yes it's easy to add -machine pc but there's no documentation
> > that tells you to do so. Add to that shortcuts like -cdrom
> > stop working, hotplug needs extra bridges to work, and one
> > can see that while management tool users benefit from q35,
> > command line users will suffer.
> > 
> > Can't we add a tag for management without changing the command line
> > default? How about "management-default"? "recommended"? "latest"?
> 
> We could add new aliases if they are useful for management
> software, but we would need a well-defined use case and set of
> requirements+expectations for the new alias.

I'm not convinced by the idea of adding a distinct default "for mgmt". All
the problems described wrt 'q35' vs 'pc' apply equally to management apps
as they do to humans. It just happens that one common mgmt layer (libvirt)
knows how to handle some of the complexity of q35. Other mgmt apps though
are just as likely to be hurt by the change as humans are. So effectively
the proposed "for mgmt" is actually  "for libvirt >= some version", which
feels like a layering violation to me.

Regards,
Daniel

On Mon, Jun 04, 2018 at 02:01:29PM +0100, Daniel P. Berrangé wrote:
> On Mon, Jun 04, 2018 at 09:54:15AM -0300, Eduardo Habkost wrote:
> > On Mon, Jun 04, 2018 at 04:38:22AM +0300, Michael S. Tsirkin wrote:
> > > On Sun, Jun 03, 2018 at 12:27:49PM +0300, Marcel Apfelbaum wrote:
> > > > Moving to QEMU 3.0 seems like a good opportunity for such a change.
> > > > 
> > > > I440FX is really old and does not support modern features like IOMMU.
> > > > Q35's SATA emulation is faster than pc's IDE, native PCI express hotplug
> > > > is cleaner than ACPI based one and so on...
> > > > 
> > > > Also the libvirt guys added very good support for the Q35 machine (thanks!).
> > > > 
> > > > Management software should always specify the machine type and for the
> > > > current setups, adding '-machine pc' to the command line is not such a
> > > > big deal.
> > > > 
> > > > In time the pc machine will fade out and we will probably stop adding
> > > > new versions at some point.
> > > > 
> > > > Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
> > > 
> > > For command line users, I think changing the default isn't nice.
> > > 
> > > Yes it's easy to add -machine pc but there's no documentation
> > > that tells you to do so. Add to that shortcuts like -cdrom
> > > stop working, hotplug needs extra bridges to work, and one
> > > can see that while management tool users benefit from q35,
> > > command line users will suffer.
> > > 
> > > Can't we add a tag for management without changing the command line
> > > default? How about "management-default"? "recommended"? "latest"?
> > 
> > We could add new aliases if they are useful for management
> > software, but we would need a well-defined use case and set of
> > requirements+expectations for the new alias.
> 
> I'm not convinced by the idea of adding a distinct default "for mgmt". All
> the problems described wrt 'q35' vs 'pc' apply equally to management apps
> as they do to humans. It just happens that one common mgmt layer (libvirt)
> knows how to handle some of the complexity of q35. Other mgmt apps though
> are just as likely to be hurt by the change as humans are. So effectively
> the proposed "for mgmt" is actually  "for libvirt >= some version", which
> feels like a layering violation to me.

This means the new alias would be used only if requested
explicitly by management software (not used automatically by
libvirt).

Taking that into account, I still don't see what exactly would be
the use case here, and what exactly users can/can't expect when
using the new alias.

On Mon, Jun 04, 2018 at 02:01:29PM +0100, Daniel P. Berrangé wrote:
> On Mon, Jun 04, 2018 at 09:54:15AM -0300, Eduardo Habkost wrote:
> > On Mon, Jun 04, 2018 at 04:38:22AM +0300, Michael S. Tsirkin wrote:
> > > On Sun, Jun 03, 2018 at 12:27:49PM +0300, Marcel Apfelbaum wrote:
> > > > Moving to QEMU 3.0 seems like a good opportunity for such a change.
> > > > 
> > > > I440FX is really old and does not support modern features like IOMMU.
> > > > Q35's SATA emulation is faster than pc's IDE, native PCI express hotplug
> > > > is cleaner than ACPI based one and so on...
> > > > 
> > > > Also the libvirt guys added very good support for the Q35 machine (thanks!).
> > > > 
> > > > Management software should always specify the machine type and for the
> > > > current setups, adding '-machine pc' to the command line is not such a
> > > > big deal.
> > > > 
> > > > In time the pc machine will fade out and we will probably stop adding
> > > > new versions at some point.
> > > > 
> > > > Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
> > > 
> > > For command line users, I think changing the default isn't nice.
> > > 
> > > Yes it's easy to add -machine pc but there's no documentation
> > > that tells you to do so. Add to that shortcuts like -cdrom
> > > stop working, hotplug needs extra bridges to work, and one
> > > can see that while management tool users benefit from q35,
> > > command line users will suffer.
> > > 
> > > Can't we add a tag for management without changing the command line
> > > default? How about "management-default"? "recommended"? "latest"?
> > 
> > We could add new aliases if they are useful for management
> > software, but we would need a well-defined use case and set of
> > requirements+expectations for the new alias.
> 
> I'm not convinced by the idea of adding a distinct default "for mgmt". All
> the problems described wrt 'q35' vs 'pc' apply equally to management apps
> as they do to humans. It just happens that one common mgmt layer (libvirt)
> knows how to handle some of the complexity of q35. Other mgmt apps though
> are just as likely to be hurt by the change as humans are. So effectively
> the proposed "for mgmt" is actually  "for libvirt >= some version", which
> feels like a layering violation to me.
> 
> Regards,
> Daniel

Is libvirt happy to just hard-code q35 for now then?

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

On Mon, Jun 04, 2018 at 07:48:51PM +0300, Michael S. Tsirkin wrote:
> On Mon, Jun 04, 2018 at 02:01:29PM +0100, Daniel P. Berrangé wrote:
> > On Mon, Jun 04, 2018 at 09:54:15AM -0300, Eduardo Habkost wrote:
> > > On Mon, Jun 04, 2018 at 04:38:22AM +0300, Michael S. Tsirkin wrote:
> > > > On Sun, Jun 03, 2018 at 12:27:49PM +0300, Marcel Apfelbaum wrote:
> > > > > Moving to QEMU 3.0 seems like a good opportunity for such a change.
> > > > > 
> > > > > I440FX is really old and does not support modern features like IOMMU.
> > > > > Q35's SATA emulation is faster than pc's IDE, native PCI express hotplug
> > > > > is cleaner than ACPI based one and so on...
> > > > > 
> > > > > Also the libvirt guys added very good support for the Q35 machine (thanks!).
> > > > > 
> > > > > Management software should always specify the machine type and for the
> > > > > current setups, adding '-machine pc' to the command line is not such a
> > > > > big deal.
> > > > > 
> > > > > In time the pc machine will fade out and we will probably stop adding
> > > > > new versions at some point.
> > > > > 
> > > > > Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
> > > > 
> > > > For command line users, I think changing the default isn't nice.
> > > > 
> > > > Yes it's easy to add -machine pc but there's no documentation
> > > > that tells you to do so. Add to that shortcuts like -cdrom
> > > > stop working, hotplug needs extra bridges to work, and one
> > > > can see that while management tool users benefit from q35,
> > > > command line users will suffer.
> > > > 
> > > > Can't we add a tag for management without changing the command line
> > > > default? How about "management-default"? "recommended"? "latest"?
> > > 
> > > We could add new aliases if they are useful for management
> > > software, but we would need a well-defined use case and set of
> > > requirements+expectations for the new alias.
> > 
> > I'm not convinced by the idea of adding a distinct default "for mgmt". All
> > the problems described wrt 'q35' vs 'pc' apply equally to management apps
> > as they do to humans. It just happens that one common mgmt layer (libvirt)
> > knows how to handle some of the complexity of q35. Other mgmt apps though
> > are just as likely to be hurt by the change as humans are. So effectively
> > the proposed "for mgmt" is actually  "for libvirt >= some version", which
> > feels like a layering violation to me.
> 
> Is libvirt happy to just hard-code q35 for now then?

I'm pretty wary of doing that, as I feel 'pc' has broader OS compatibility
than 'q35', so we'd be likely to cause breakage for users.

IMHO, defaults are something better expressed in libosinfo, so if there's
guests where we think q35 is a better choice, we can record it there and
leave everything else on pc to avoid risk of breakage.

Regards,
Daniel

On Mon, Jun 04, 2018 at 10:26:24AM -0300, Eduardo Habkost wrote:
> On Mon, Jun 04, 2018 at 02:01:29PM +0100, Daniel P. Berrangé wrote:
> > On Mon, Jun 04, 2018 at 09:54:15AM -0300, Eduardo Habkost wrote:
> > > On Mon, Jun 04, 2018 at 04:38:22AM +0300, Michael S. Tsirkin wrote:
> > > > On Sun, Jun 03, 2018 at 12:27:49PM +0300, Marcel Apfelbaum wrote:
> > > > > Moving to QEMU 3.0 seems like a good opportunity for such a change.
> > > > > 
> > > > > I440FX is really old and does not support modern features like IOMMU.
> > > > > Q35's SATA emulation is faster than pc's IDE, native PCI express hotplug
> > > > > is cleaner than ACPI based one and so on...
> > > > > 
> > > > > Also the libvirt guys added very good support for the Q35 machine (thanks!).
> > > > > 
> > > > > Management software should always specify the machine type and for the
> > > > > current setups, adding '-machine pc' to the command line is not such a
> > > > > big deal.
> > > > > 
> > > > > In time the pc machine will fade out and we will probably stop adding
> > > > > new versions at some point.
> > > > > 
> > > > > Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
> > > > 
> > > > For command line users, I think changing the default isn't nice.
> > > > 
> > > > Yes it's easy to add -machine pc but there's no documentation
> > > > that tells you to do so. Add to that shortcuts like -cdrom
> > > > stop working, hotplug needs extra bridges to work, and one
> > > > can see that while management tool users benefit from q35,
> > > > command line users will suffer.
> > > > 
> > > > Can't we add a tag for management without changing the command line
> > > > default? How about "management-default"? "recommended"? "latest"?
> > > 
> > > We could add new aliases if they are useful for management
> > > software, but we would need a well-defined use case and set of
> > > requirements+expectations for the new alias.
> > 
> > I'm not convinced by the idea of adding a distinct default "for mgmt". All
> > the problems described wrt 'q35' vs 'pc' apply equally to management apps
> > as they do to humans. It just happens that one common mgmt layer (libvirt)
> > knows how to handle some of the complexity of q35. Other mgmt apps though
> > are just as likely to be hurt by the change as humans are. So effectively
> > the proposed "for mgmt" is actually  "for libvirt >= some version", which
> > feels like a layering violation to me.
> 
> This means the new alias would be used only if requested
> explicitly by management software (not used automatically by
> libvirt).
> 
> Taking that into account, I still don't see what exactly would be
> the use case here, and what exactly users can/can't expect when
> using the new alias.

Let's see what we have now first:

1. We have a requirement for the user to save the machine type on install
and maintain it with the image (a separate thread discusses saving that
as part of a qcow2 image).

2. If you use an alias instead you are supposed to resolve it
and save the resolved value. If you save the alias instead,
you can't do cross-version live migration.

3. If you don't specify anything you get a machine tagged default.  You are
supposed to find it and save the value found.  If you don't and just
keep using the default, you can't do cross-version live migration.

---

So now we would like to relax 3 to say
	"If you don't and just keep using the default, some images might not
	boot".

unfortunately we probably can't change 3 like this.
So what I propose instead is simply:

4. If you find a machine type value tagged "qmp-default" you must save
   the value found.  If you don't and just keep using the qmp-default each
   time, then existing guest images won't boot.
   This relaxed compatibility requirement allows for advanced features
   as compared to default.

> -- 
> Eduardo

On 06/04/2018 08:35 AM, Paolo Bonzini wrote:
> On 04/06/2018 14:24, Igor Mammedov wrote:
>>> Yes it's easy to add -machine pc but there's no documentation
>>> that tells you to do so. Add to that shortcuts like -cdrom
>>> stop working, hotplug needs extra bridges to work, and one
>>> can see that while management tool users benefit from q35,
>>> command line users will suffer.
>> Maybe we should mark 'pc' default as deprecated first,
>> like we do with CLI options that we wish to drop in future?
>>
>> That way we 'create' documentation, so users would be aware
>> of the change and have time to fix their CLI if they prefer
>> 'pc' machine.
> 
> Michael has listed reasons why 'pc' cannot be deprecated, since some of
> them are not even fixable.  Honestly, 'pc' works well for 99% of the use
> cases---just like you probably don't care whether your laptop has a PCI
> or PCIe chipset.
> 
> Paolo
> 
> 

I understood this comment to mean deprecating a *default* machine type.

So if you do `-M pc` you're still OK, but if you simply omit a machine
type and hope for a specific one you're out of luck.

... We could just deprecate having any default and then make QEMU whine
at you if you don't specify one, like we do for guessing format types on
drive images -- it'll do it, but if it guesses raw it whines at you a
little.

Hi Michael,

On 06/04/2018 04:38 AM, Michael S. Tsirkin wrote:
> On Sun, Jun 03, 2018 at 12:27:49PM +0300, Marcel Apfelbaum wrote:
>> Moving to QEMU 3.0 seems like a good opportunity for such a change.
>>
>> I440FX is really old and does not support modern features like IOMMU.
>> Q35's SATA emulation is faster than pc's IDE, native PCI express hotplug
>> is cleaner than ACPI based one and so on...
>>
>> Also the libvirt guys added very good support for the Q35 machine (thanks!).
>>
>> Management software should always specify the machine type and for the
>> current setups, adding '-machine pc' to the command line is not such a
>> big deal.
>>
>> In time the pc machine will fade out and we will probably stop adding
>> new versions at some point.
>>
>> Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
> For command line users, I think changing the default isn't nice.
>
> Yes it's easy to add -machine pc but there's no documentation
> that tells you to do so.

We can add something do the help.

>   Add to that shortcuts like -cdrom
> stop working,

Maybe is fixable.

> hotplug needs extra bridges to work,

Adding a pci express root port in case hotplug is desired should
not be too hard.
>   and one
> can see that while management tool users benefit from q35,
> command line users will suffer.
>
> Can't we add a tag for management without changing the command line
> default? How about "management-default"? "recommended"? "latest"?

This will help maybe, but was not the point.
We have two x86 machine types, meaning some features
will be developed/tested for pc, while others for q35.
At some point we will loose track of what is working
for each machine.

The PC machine command line is simpler and it supports older guest OSes,
so we should keep it, of course; but I am not sure
we should add more features to it.

I see marking Q35 as the default machine a first step.

Thanks,
Marcel

On Mon, Jun 04, 2018 at 08:17:23PM +0300, Michael S. Tsirkin wrote:
> On Mon, Jun 04, 2018 at 10:26:24AM -0300, Eduardo Habkost wrote:
> > On Mon, Jun 04, 2018 at 02:01:29PM +0100, Daniel P. Berrangé wrote:
> > > On Mon, Jun 04, 2018 at 09:54:15AM -0300, Eduardo Habkost wrote:
> > > > On Mon, Jun 04, 2018 at 04:38:22AM +0300, Michael S. Tsirkin wrote:
> > > > > On Sun, Jun 03, 2018 at 12:27:49PM +0300, Marcel Apfelbaum wrote:
> > > > > > Moving to QEMU 3.0 seems like a good opportunity for such a change.
> > > > > > 
> > > > > > I440FX is really old and does not support modern features like IOMMU.
> > > > > > Q35's SATA emulation is faster than pc's IDE, native PCI express hotplug
> > > > > > is cleaner than ACPI based one and so on...
> > > > > > 
> > > > > > Also the libvirt guys added very good support for the Q35 machine (thanks!).
> > > > > > 
> > > > > > Management software should always specify the machine type and for the
> > > > > > current setups, adding '-machine pc' to the command line is not such a
> > > > > > big deal.
> > > > > > 
> > > > > > In time the pc machine will fade out and we will probably stop adding
> > > > > > new versions at some point.
> > > > > > 
> > > > > > Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
> > > > > 
> > > > > For command line users, I think changing the default isn't nice.
> > > > > 
> > > > > Yes it's easy to add -machine pc but there's no documentation
> > > > > that tells you to do so. Add to that shortcuts like -cdrom
> > > > > stop working, hotplug needs extra bridges to work, and one
> > > > > can see that while management tool users benefit from q35,
> > > > > command line users will suffer.
> > > > > 
> > > > > Can't we add a tag for management without changing the command line
> > > > > default? How about "management-default"? "recommended"? "latest"?
> > > > 
> > > > We could add new aliases if they are useful for management
> > > > software, but we would need a well-defined use case and set of
> > > > requirements+expectations for the new alias.
> > > 
> > > I'm not convinced by the idea of adding a distinct default "for mgmt". All
> > > the problems described wrt 'q35' vs 'pc' apply equally to management apps
> > > as they do to humans. It just happens that one common mgmt layer (libvirt)
> > > knows how to handle some of the complexity of q35. Other mgmt apps though
> > > are just as likely to be hurt by the change as humans are. So effectively
> > > the proposed "for mgmt" is actually  "for libvirt >= some version", which
> > > feels like a layering violation to me.
> > 
> > This means the new alias would be used only if requested
> > explicitly by management software (not used automatically by
> > libvirt).
> > 
> > Taking that into account, I still don't see what exactly would be
> > the use case here, and what exactly users can/can't expect when
> > using the new alias.
> 
> Let's see what we have now first:
> 
> 1. We have a requirement for the user to save the machine type on install
> and maintain it with the image (a separate thread discusses saving that
> as part of a qcow2 image).
> 
> 2. If you use an alias instead you are supposed to resolve it
> and save the resolved value. If you save the alias instead,
> you can't do cross-version live migration.
> 
> 3. If you don't specify anything you get a machine tagged default.  You are
> supposed to find it and save the value found.  If you don't and just
> keep using the default, you can't do cross-version live migration.
> 
> ---
> 
> So now we would like to relax 3 to say
> 	"If you don't and just keep using the default, some images might not
> 	boot".
> 
> unfortunately we probably can't change 3 like this.
> So what I propose instead is simply:
> 
> 4. If you find a machine type value tagged "qmp-default" you must save
>    the value found.  If you don't and just keep using the qmp-default each
>    time, then existing guest images won't boot.
>    This relaxed compatibility requirement allows for advanced features
>    as compared to default.

What problems would this system solve?  Who would prefer to use
the "qmp-default" machine-type instead of the "pc" or "q35"
aliases?

On 06/04/2018 07:56 PM, Daniel P. Berrangé wrote:
> On Mon, Jun 04, 2018 at 07:48:51PM +0300, Michael S. Tsirkin wrote:
>> On Mon, Jun 04, 2018 at 02:01:29PM +0100, Daniel P. Berrangé wrote:
>>> On Mon, Jun 04, 2018 at 09:54:15AM -0300, Eduardo Habkost wrote:
>>>> On Mon, Jun 04, 2018 at 04:38:22AM +0300, Michael S. Tsirkin wrote:
>>>>> On Sun, Jun 03, 2018 at 12:27:49PM +0300, Marcel Apfelbaum wrote:
>>>>>> Moving to QEMU 3.0 seems like a good opportunity for such a change.
>>>>>>
>>>>>> I440FX is really old and does not support modern features like IOMMU.
>>>>>> Q35's SATA emulation is faster than pc's IDE, native PCI express hotplug
>>>>>> is cleaner than ACPI based one and so on...
>>>>>>
>>>>>> Also the libvirt guys added very good support for the Q35 machine (thanks!).
>>>>>>
>>>>>> Management software should always specify the machine type and for the
>>>>>> current setups, adding '-machine pc' to the command line is not such a
>>>>>> big deal.
>>>>>>
>>>>>> In time the pc machine will fade out and we will probably stop adding
>>>>>> new versions at some point.
>>>>>>
>>>>>> Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
>>>>> For command line users, I think changing the default isn't nice.
>>>>>
>>>>> Yes it's easy to add -machine pc but there's no documentation
>>>>> that tells you to do so. Add to that shortcuts like -cdrom
>>>>> stop working, hotplug needs extra bridges to work, and one
>>>>> can see that while management tool users benefit from q35,
>>>>> command line users will suffer.
>>>>>
>>>>> Can't we add a tag for management without changing the command line
>>>>> default? How about "management-default"? "recommended"? "latest"?
>>>> We could add new aliases if they are useful for management
>>>> software, but we would need a well-defined use case and set of
>>>> requirements+expectations for the new alias.
>>> I'm not convinced by the idea of adding a distinct default "for mgmt". All
>>> the problems described wrt 'q35' vs 'pc' apply equally to management apps
>>> as they do to humans. It just happens that one common mgmt layer (libvirt)
>>> knows how to handle some of the complexity of q35. Other mgmt apps though
>>> are just as likely to be hurt by the change as humans are. So effectively
>>> the proposed "for mgmt" is actually  "for libvirt >= some version", which
>>> feels like a layering violation to me.
>> Is libvirt happy to just hard-code q35 for now then?
> I'm pretty wary of doing that, as I feel 'pc' has broader OS compatibility
> than 'q35', so we'd be likely to cause breakage for users.
>
> IMHO, defaults are something better expressed in libosinfo, so if there's
> guests where we think q35 is a better choice, we can record it there and
> leave everything else on pc to avoid risk of breakage.

The only info we need to pass properly to management systems is:
"Use q35 unless your guests are really old".

I agree the exiting systems should not be touched.

Thanks,
Marcel

> Regards,
> Daniel

On Mon, Jun 04, 2018 at 09:40:15PM +0300, Marcel Apfelbaum wrote:
> 
> 
> On 06/04/2018 07:56 PM, Daniel P. Berrangé wrote:
> > On Mon, Jun 04, 2018 at 07:48:51PM +0300, Michael S. Tsirkin wrote:
> > > On Mon, Jun 04, 2018 at 02:01:29PM +0100, Daniel P. Berrangé wrote:
> > > > On Mon, Jun 04, 2018 at 09:54:15AM -0300, Eduardo Habkost wrote:
> > > > > On Mon, Jun 04, 2018 at 04:38:22AM +0300, Michael S. Tsirkin wrote:
> > > > > > On Sun, Jun 03, 2018 at 12:27:49PM +0300, Marcel Apfelbaum wrote:
> > > > > > > Moving to QEMU 3.0 seems like a good opportunity for such a change.
> > > > > > > 
> > > > > > > I440FX is really old and does not support modern features like IOMMU.
> > > > > > > Q35's SATA emulation is faster than pc's IDE, native PCI express hotplug
> > > > > > > is cleaner than ACPI based one and so on...
> > > > > > > 
> > > > > > > Also the libvirt guys added very good support for the Q35 machine (thanks!).
> > > > > > > 
> > > > > > > Management software should always specify the machine type and for the
> > > > > > > current setups, adding '-machine pc' to the command line is not such a
> > > > > > > big deal.
> > > > > > > 
> > > > > > > In time the pc machine will fade out and we will probably stop adding
> > > > > > > new versions at some point.
> > > > > > > 
> > > > > > > Signed-off-by: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
> > > > > > For command line users, I think changing the default isn't nice.
> > > > > > 
> > > > > > Yes it's easy to add -machine pc but there's no documentation
> > > > > > that tells you to do so. Add to that shortcuts like -cdrom
> > > > > > stop working, hotplug needs extra bridges to work, and one
> > > > > > can see that while management tool users benefit from q35,
> > > > > > command line users will suffer.
> > > > > > 
> > > > > > Can't we add a tag for management without changing the command line
> > > > > > default? How about "management-default"? "recommended"? "latest"?
> > > > > We could add new aliases if they are useful for management
> > > > > software, but we would need a well-defined use case and set of
> > > > > requirements+expectations for the new alias.
> > > > I'm not convinced by the idea of adding a distinct default "for mgmt". All
> > > > the problems described wrt 'q35' vs 'pc' apply equally to management apps
> > > > as they do to humans. It just happens that one common mgmt layer (libvirt)
> > > > knows how to handle some of the complexity of q35. Other mgmt apps though
> > > > are just as likely to be hurt by the change as humans are. So effectively
> > > > the proposed "for mgmt" is actually  "for libvirt >= some version", which
> > > > feels like a layering violation to me.
> > > Is libvirt happy to just hard-code q35 for now then?
> > I'm pretty wary of doing that, as I feel 'pc' has broader OS compatibility
> > than 'q35', so we'd be likely to cause breakage for users.
> > 
> > IMHO, defaults are something better expressed in libosinfo, so if there's
> > guests where we think q35 is a better choice, we can record it there and
> > leave everything else on pc to avoid risk of breakage.
> 
> The only info we need to pass properly to management systems is:
> "Use q35 unless your guests are really old".

Or if your existing disk image contains drivers or other software
that work only with pc.  Or if it's going to trigger Windows
license reactivation on a disk image prepared using pc.

The stack can't change the default without breaking existing
guest images.  Whether it's a reasonable risk or it's
unacceptable depends on what are the intended audience and use
cases of a given management stack.  I don't think QEMU or libvirt
can make that decision for them.

That said, if something is going to break as soon as the default
in QEMU changes, that's a bug in the management stack.
Management stacks should stop assuming the default machine-type
in libvirt+QEMU is never going to change.

Hi,

> >   Add to that shortcuts like -cdrom
> > stop working,
> 
> Maybe is fixable.

Already fixed for ages.

> I see marking Q35 as the default machine a first step.

Maybe the better option is to go the arm route:  Just don't define a
default, so users have to specify pc or q35.  That will make them notice
there is a world beside 'pc', and we also avoid breaking things
silently.

In case no machine type is given qemu can print some hints together with
the error message.

cheers,
  Gerd

On Tue, Jun 05, 2018 at 09:27:46AM +0200, Gerd Hoffmann wrote:
>   Hi,
> 
> > >   Add to that shortcuts like -cdrom
> > > stop working,
> > 
> > Maybe is fixable.
> 
> Already fixed for ages.
> 
> > I see marking Q35 as the default machine a first step.
> 
> Maybe the better option is to go the arm route:  Just don't define a
> default, so users have to specify pc or q35.  That will make them notice
> there is a world beside 'pc', and we also avoid breaking things
> silently.

If QEMU removes the default, then libvirt will have to hardcode
'pc' as the default to maintain back compatibility, so I don't
think that ends up as a net win

Regards,
Daniel

(CCing libvir-list)

On Tue, Jun 05, 2018 at 09:43:00AM +0100, Daniel P. Berrangé wrote:
> On Tue, Jun 05, 2018 at 09:27:46AM +0200, Gerd Hoffmann wrote:
> >   Hi,
> > 
> > > >   Add to that shortcuts like -cdrom
> > > > stop working,
> > > 
> > > Maybe is fixable.
> > 
> > Already fixed for ages.
> > 
> > > I see marking Q35 as the default machine a first step.
> > 
> > Maybe the better option is to go the arm route:  Just don't define a
> > default, so users have to specify pc or q35.  That will make them notice
> > there is a world beside 'pc', and we also avoid breaking things
> > silently.
> 
> If QEMU removes the default, then libvirt will have to hardcode
> 'pc' as the default to maintain back compatibility, so I don't
> think that ends up as a net win

Is there an actual promise to never change the default
machine-type documented in the libvirt API, or is this just fear
of breaking existing code?

On Tue, Jun 05, 2018 at 10:06:46AM -0300, Eduardo Habkost wrote:
> (CCing libvir-list)
> 
> On Tue, Jun 05, 2018 at 09:43:00AM +0100, Daniel P. Berrangé wrote:
> > On Tue, Jun 05, 2018 at 09:27:46AM +0200, Gerd Hoffmann wrote:
> > >   Hi,
> > > 
> > > > >   Add to that shortcuts like -cdrom
> > > > > stop working,
> > > > 
> > > > Maybe is fixable.
> > > 
> > > Already fixed for ages.
> > > 
> > > > I see marking Q35 as the default machine a first step.
> > > 
> > > Maybe the better option is to go the arm route:  Just don't define a
> > > default, so users have to specify pc or q35.  That will make them notice
> > > there is a world beside 'pc', and we also avoid breaking things
> > > silently.
> > 
> > If QEMU removes the default, then libvirt will have to hardcode
> > 'pc' as the default to maintain back compatibility, so I don't
> > think that ends up as a net win
> 
> Is there an actual promise to never change the default
> machine-type documented in the libvirt API, or is this just fear
> of breaking existing code?

The risk of breaking things that currently work. Some of the things
discussed here that risk breaking users if QEMU changes the default,
have the same risk if libvirt changes the default.

eg old OS versions that only work with PC, or more commonly pre-existing
cloud disk images that were built against PC can't be assumed to just
work against q35, even if the OS in the image supports it.

If we want to get q35 broadly used for modern OS, then IMHO the best
option is to record that metadata in libosinfo, as ew do for other
virtual hardware preferences.  That doesn't fix the problem of disk
images that might not transparently boot between pc/q35, but at least
avoids breaking OS that don't support q35 at all.

Regards,
Daniel

On 06/05/2018 11:43 AM, Daniel P. Berrangé wrote:
> On Tue, Jun 05, 2018 at 09:27:46AM +0200, Gerd Hoffmann wrote:
>>    Hi,
>>
>>>>    Add to that shortcuts like -cdrom
>>>> stop working,
>>> Maybe is fixable.
>> Already fixed for ages.
>>
>>> I see marking Q35 as the default machine a first step.
>> Maybe the better option is to go the arm route:  Just don't define a
>> default, so users have to specify pc or q35.  That will make them notice
>> there is a world beside 'pc', and we also avoid breaking things
>> silently.

It can work, sure. And we can add user hints: "Use q35 for ...., select 
pc if..."

> If QEMU removes the default, then libvirt will have to hardcode
> 'pc' as the default to maintain back compatibility, so I don't
> think that ends up as a net win

Can't libvirt preserve 'pc' for existing domains, while defaulting to q35
the creation of new domains ? This way it aligns with Gerd's proposal of 
no default
x86 machine.

Thanks,
Marcel

>
> Regards,
> Daniel

On Tue, Jun 05, 2018 at 04:20:46PM +0300, Marcel Apfelbaum wrote:
> 
> 
> On 06/05/2018 11:43 AM, Daniel P. Berrangé wrote:
> > On Tue, Jun 05, 2018 at 09:27:46AM +0200, Gerd Hoffmann wrote:
> > >    Hi,
> > > 
> > > > >    Add to that shortcuts like -cdrom
> > > > > stop working,
> > > > Maybe is fixable.
> > > Already fixed for ages.
> > > 
> > > > I see marking Q35 as the default machine a first step.
> > > Maybe the better option is to go the arm route:  Just don't define a
> > > default, so users have to specify pc or q35.  That will make them notice
> > > there is a world beside 'pc', and we also avoid breaking things
> > > silently.
> 
> It can work, sure. And we can add user hints: "Use q35 for ...., select pc
> if..."
> 
> > If QEMU removes the default, then libvirt will have to hardcode
> > 'pc' as the default to maintain back compatibility, so I don't
> > think that ends up as a net win
> 
> Can't libvirt preserve 'pc' for existing domains, while defaulting to q35
> the creation of new domains ? This way it aligns with Gerd's proposal of no
> default x86 machine.

Existing domains wasn't the case I was concerned about. Consider you have
libvirt 4.4.0 intsalled and you deploy a *new* domain from a prebuilt
disk image "foo". Now update to a libvirt or QEMU which changes to q35
and try to deploy another new domain from the same prebuilt disk
image "foo". It may not work now if that disk image doesn't support
q35. That would be a regression from the user's POV, whether libvirt or
qemu has changed the default.

Regards,
Daniel

On Tue, Jun 05, 2018 at 02:12:32PM +0100, Daniel P. Berrangé wrote:
> On Tue, Jun 05, 2018 at 10:06:46AM -0300, Eduardo Habkost wrote:
> > (CCing libvir-list)
> > 
> > On Tue, Jun 05, 2018 at 09:43:00AM +0100, Daniel P. Berrangé wrote:
> > > On Tue, Jun 05, 2018 at 09:27:46AM +0200, Gerd Hoffmann wrote:
> > > >   Hi,
> > > > 
> > > > > >   Add to that shortcuts like -cdrom
> > > > > > stop working,
> > > > > 
> > > > > Maybe is fixable.
> > > > 
> > > > Already fixed for ages.
> > > > 
> > > > > I see marking Q35 as the default machine a first step.
> > > > 
> > > > Maybe the better option is to go the arm route:  Just don't define a
> > > > default, so users have to specify pc or q35.  That will make them notice
> > > > there is a world beside 'pc', and we also avoid breaking things
> > > > silently.
> > > 
> > > If QEMU removes the default, then libvirt will have to hardcode
> > > 'pc' as the default to maintain back compatibility, so I don't
> > > think that ends up as a net win
> > 
> > Is there an actual promise to never change the default
> > machine-type documented in the libvirt API, or is this just fear
> > of breaking existing code?
> 
> The risk of breaking things that currently work. Some of the things
> discussed here that risk breaking users if QEMU changes the default,
> have the same risk if libvirt changes the default.
> 
> eg old OS versions that only work with PC, or more commonly pre-existing
> cloud disk images that were built against PC can't be assumed to just
> work against q35, even if the OS in the image supports it.
> 
> If we want to get q35 broadly used for modern OS, then IMHO the best
> option is to record that metadata in libosinfo, as ew do for other
> virtual hardware preferences.  That doesn't fix the problem of disk
> images that might not transparently boot between pc/q35, but at least
> avoids breaking OS that don't support q35 at all.

This leads to a more general question: sometimes the defaults
chosen by libvirt are obsolete or broken, and we might want to
change them.

Is there a process for changing defaults in libvirt, or libvirt
is bound by past decisions forever?

On Tue, Jun 05, 2018 at 10:35:38AM -0300, Eduardo Habkost wrote:
> On Tue, Jun 05, 2018 at 02:12:32PM +0100, Daniel P. Berrangé wrote:
> > On Tue, Jun 05, 2018 at 10:06:46AM -0300, Eduardo Habkost wrote:
> > > (CCing libvir-list)
> > > 
> > > On Tue, Jun 05, 2018 at 09:43:00AM +0100, Daniel P. Berrangé wrote:
> > > > On Tue, Jun 05, 2018 at 09:27:46AM +0200, Gerd Hoffmann wrote:
> > > > >   Hi,
> > > > > 
> > > > > > >   Add to that shortcuts like -cdrom
> > > > > > > stop working,
> > > > > > 
> > > > > > Maybe is fixable.
> > > > > 
> > > > > Already fixed for ages.
> > > > > 
> > > > > > I see marking Q35 as the default machine a first step.
> > > > > 
> > > > > Maybe the better option is to go the arm route:  Just don't define a
> > > > > default, so users have to specify pc or q35.  That will make them notice
> > > > > there is a world beside 'pc', and we also avoid breaking things
> > > > > silently.
> > > > 
> > > > If QEMU removes the default, then libvirt will have to hardcode
> > > > 'pc' as the default to maintain back compatibility, so I don't
> > > > think that ends up as a net win
> > > 
> > > Is there an actual promise to never change the default
> > > machine-type documented in the libvirt API, or is this just fear
> > > of breaking existing code?
> > 
> > The risk of breaking things that currently work. Some of the things
> > discussed here that risk breaking users if QEMU changes the default,
> > have the same risk if libvirt changes the default.
> > 
> > eg old OS versions that only work with PC, or more commonly pre-existing
> > cloud disk images that were built against PC can't be assumed to just
> > work against q35, even if the OS in the image supports it.
> > 
> > If we want to get q35 broadly used for modern OS, then IMHO the best
> > option is to record that metadata in libosinfo, as ew do for other
> > virtual hardware preferences.  That doesn't fix the problem of disk
> > images that might not transparently boot between pc/q35, but at least
> > avoids breaking OS that don't support q35 at all.
> 
> This leads to a more general question: sometimes the defaults
> chosen by libvirt are obsolete or broken, and we might want to
> change them.
> 
> Is there a process for changing defaults in libvirt, or libvirt
> is bound by past decisions forever?

The general promise is that if you upgrade libvirt everything an application
was doing before should still work in the same way. We also aim to promise
that if you upgrade the hypervisor underneath things will still work. This
is much harder to guarantee but we'll make reasonable effort to try to
present an unchanged view to the mgmt app. Guest ABI is of course most
critical part of that but anything that affects APIs a mgmt app is using
relevant. This largely precludes changing defaults unless the feature goes
away entirely or is unusable in some serious way.

This is why we try to push the idea of policy decisions into a layer
above with libosinfo suggesting defaults for individual guest OS.

Regards,
Daniel

On 06/05/18 15:29, Daniel P. Berrangé wrote:
> On Tue, Jun 05, 2018 at 04:20:46PM +0300, Marcel Apfelbaum wrote:
>>
>>
>> On 06/05/2018 11:43 AM, Daniel P. Berrangé wrote:
>>> On Tue, Jun 05, 2018 at 09:27:46AM +0200, Gerd Hoffmann wrote:
>>>>    Hi,
>>>>
>>>>>>    Add to that shortcuts like -cdrom
>>>>>> stop working,
>>>>> Maybe is fixable.
>>>> Already fixed for ages.
>>>>
>>>>> I see marking Q35 as the default machine a first step.
>>>> Maybe the better option is to go the arm route:  Just don't define a
>>>> default, so users have to specify pc or q35.  That will make them notice
>>>> there is a world beside 'pc', and we also avoid breaking things
>>>> silently.
>>
>> It can work, sure. And we can add user hints: "Use q35 for ...., select pc
>> if..."
>>
>>> If QEMU removes the default, then libvirt will have to hardcode
>>> 'pc' as the default to maintain back compatibility, so I don't
>>> think that ends up as a net win
>>
>> Can't libvirt preserve 'pc' for existing domains, while defaulting to q35
>> the creation of new domains ? This way it aligns with Gerd's proposal of no
>> default x86 machine.
> 
> Existing domains wasn't the case I was concerned about. Consider you have
> libvirt 4.4.0 intsalled and you deploy a *new* domain from a prebuilt
> disk image "foo". Now update to a libvirt or QEMU which changes to q35
> and try to deploy another new domain from the same prebuilt disk
> image "foo". It may not work now if that disk image doesn't support
> q35. That would be a regression from the user's POV, whether libvirt or
> qemu has changed the default.

How about:
- "create new domain with empty disk" --> i440fx now, q35 later
- "create new domain from domain XML and disk image" --> whatever the
  domain definition dictates
- "create new domain from disk image and no domain XML" --> assume
  i440fx forever (with a detailed board / device config that's used for
  all legacy (definition-less) disk images)
- convince disk image distributors to provide their domain definitions
  with their disks (need not be libvirt domain XML, other definitions
  might work)
- write converters from those other definition formats to libvirt XML,
  or QEMU cfg file?

(I'm with Markus:
<http://mid.mail-archive.com/87o9h6hb59.fsf@dusky.pond.sub.org>. Not
specifically about OVF, but disk image providers need to start exposing
their QEMU configs. And I think they should do that in whatever format
their management stack supports.)

Just my two cents, feel free to ignore.

Thanks
Laszlo

On Tue, Jun 05, 2018 at 10:35:38AM -0300, Eduardo Habkost wrote:
> On Tue, Jun 05, 2018 at 02:12:32PM +0100, Daniel P. Berrangé wrote:
> > On Tue, Jun 05, 2018 at 10:06:46AM -0300, Eduardo Habkost wrote:
> > > (CCing libvir-list)
> > > 
> > > On Tue, Jun 05, 2018 at 09:43:00AM +0100, Daniel P. Berrangé wrote:
> > > > On Tue, Jun 05, 2018 at 09:27:46AM +0200, Gerd Hoffmann wrote:
> > > > >   Hi,
> > > > > 
> > > > > > >   Add to that shortcuts like -cdrom
> > > > > > > stop working,
> > > > > > 
> > > > > > Maybe is fixable.
> > > > > 
> > > > > Already fixed for ages.
> > > > > 
> > > > > > I see marking Q35 as the default machine a first step.
> > > > > 
> > > > > Maybe the better option is to go the arm route:  Just don't define a
> > > > > default, so users have to specify pc or q35.  That will make them notice
> > > > > there is a world beside 'pc', and we also avoid breaking things
> > > > > silently.
> > > > 
> > > > If QEMU removes the default, then libvirt will have to hardcode
> > > > 'pc' as the default to maintain back compatibility, so I don't
> > > > think that ends up as a net win
> > > 
> > > Is there an actual promise to never change the default
> > > machine-type documented in the libvirt API, or is this just fear
> > > of breaking existing code?
> > 
> > The risk of breaking things that currently work. Some of the things
> > discussed here that risk breaking users if QEMU changes the default,
> > have the same risk if libvirt changes the default.
> > 
> > eg old OS versions that only work with PC, or more commonly pre-existing
> > cloud disk images that were built against PC can't be assumed to just
> > work against q35, even if the OS in the image supports it.
> > 
> > If we want to get q35 broadly used for modern OS, then IMHO the best
> > option is to record that metadata in libosinfo, as ew do for other
> > virtual hardware preferences.  That doesn't fix the problem of disk
> > images that might not transparently boot between pc/q35, but at least
> > avoids breaking OS that don't support q35 at all.
> 
> This leads to a more general question: sometimes the defaults
> chosen by libvirt are obsolete or broken, and we might want to
> change them.
> 
> Is there a process for changing defaults in libvirt, or libvirt
> is bound by past decisions forever?

If the default was always recorded in the domain XML it is safe to
change it because it will not affect already existing domains or
migration but if the default is not recorded in the domain XML there
needs to be a lot of compatibility code.

In the past we've changed some of the defaults, for example default
device model.

Pavel

On Tue, Jun 05, 2018 at 03:44:14PM +0200, Laszlo Ersek wrote:
> On 06/05/18 15:29, Daniel P. Berrangé wrote:
> > On Tue, Jun 05, 2018 at 04:20:46PM +0300, Marcel Apfelbaum wrote:
> >>
> >>
> >> On 06/05/2018 11:43 AM, Daniel P. Berrangé wrote:
> >>> On Tue, Jun 05, 2018 at 09:27:46AM +0200, Gerd Hoffmann wrote:
> >>>>    Hi,
> >>>>
> >>>>>>    Add to that shortcuts like -cdrom
> >>>>>> stop working,
> >>>>> Maybe is fixable.
> >>>> Already fixed for ages.
> >>>>
> >>>>> I see marking Q35 as the default machine a first step.
> >>>> Maybe the better option is to go the arm route:  Just don't define a
> >>>> default, so users have to specify pc or q35.  That will make them notice
> >>>> there is a world beside 'pc', and we also avoid breaking things
> >>>> silently.
> >>
> >> It can work, sure. And we can add user hints: "Use q35 for ...., select pc
> >> if..."
> >>
> >>> If QEMU removes the default, then libvirt will have to hardcode
> >>> 'pc' as the default to maintain back compatibility, so I don't
> >>> think that ends up as a net win
> >>
> >> Can't libvirt preserve 'pc' for existing domains, while defaulting to q35
> >> the creation of new domains ? This way it aligns with Gerd's proposal of no
> >> default x86 machine.
> > 
> > Existing domains wasn't the case I was concerned about. Consider you have
> > libvirt 4.4.0 intsalled and you deploy a *new* domain from a prebuilt
> > disk image "foo". Now update to a libvirt or QEMU which changes to q35
> > and try to deploy another new domain from the same prebuilt disk
> > image "foo". It may not work now if that disk image doesn't support
> > q35. That would be a regression from the user's POV, whether libvirt or
> > qemu has changed the default.
> 
> How about:
> - "create new domain with empty disk" --> i440fx now, q35 later

"empty disk" is not something that can be determined by the
host - libvirt might not even have direct access to the disk
at the time this info would be needed.

> - "create new domain from domain XML and disk image" --> whatever the
>   domain definition dictates
> - "create new domain from disk image and no domain XML" --> assume
>   i440fx forever (with a detailed board / device config that's used for
>   all legacy (definition-less) disk images)



> - convince disk image distributors to provide their domain definitions
>   with their disks (need not be libvirt domain XML, other definitions
>   might work)

Libvirt domain XML is absolutely not suitable - it is a host specific
instantiation of a guest, that is not guaranteed to be portable to
any other host.

Funnily enough though, I just remembered that 10 years ago we invented
another XML format called "virt-image XML", that went along with a
"virt-image" command line tool

  https://github.com/virt-manager/virt-manager/blob/2e7d477156e9d0f6fb218fa19fc00d6229d33e85/man/virt-image-xml.pod

This was rarely used because the "virt-image" tool itself was rather
broken by design, so we eventually deleted this entirely.

The virt-image XML  description though could be resurrected as it
is largely relevant to the conversation.

> - write converters from those other definition formats to libvirt XML,
>   or QEMU cfg file?

Regards,
Daniel

On Tue, Jun 05, 2018 at 03:44:39PM +0200, Pavel Hrdina wrote:
> On Tue, Jun 05, 2018 at 10:35:38AM -0300, Eduardo Habkost wrote:
> > On Tue, Jun 05, 2018 at 02:12:32PM +0100, Daniel P. Berrangé wrote:
> > > On Tue, Jun 05, 2018 at 10:06:46AM -0300, Eduardo Habkost wrote:
> > > > (CCing libvir-list)
> > > > 
> > > > On Tue, Jun 05, 2018 at 09:43:00AM +0100, Daniel P. Berrangé wrote:
> > > > > On Tue, Jun 05, 2018 at 09:27:46AM +0200, Gerd Hoffmann wrote:
> > > > > >   Hi,
> > > > > > 
> > > > > > > >   Add to that shortcuts like -cdrom
> > > > > > > > stop working,
> > > > > > > 
> > > > > > > Maybe is fixable.
> > > > > > 
> > > > > > Already fixed for ages.
> > > > > > 
> > > > > > > I see marking Q35 as the default machine a first step.
> > > > > > 
> > > > > > Maybe the better option is to go the arm route:  Just don't define a
> > > > > > default, so users have to specify pc or q35.  That will make them notice
> > > > > > there is a world beside 'pc', and we also avoid breaking things
> > > > > > silently.
> > > > > 
> > > > > If QEMU removes the default, then libvirt will have to hardcode
> > > > > 'pc' as the default to maintain back compatibility, so I don't
> > > > > think that ends up as a net win
> > > > 
> > > > Is there an actual promise to never change the default
> > > > machine-type documented in the libvirt API, or is this just fear
> > > > of breaking existing code?
> > > 
> > > The risk of breaking things that currently work. Some of the things
> > > discussed here that risk breaking users if QEMU changes the default,
> > > have the same risk if libvirt changes the default.
> > > 
> > > eg old OS versions that only work with PC, or more commonly pre-existing
> > > cloud disk images that were built against PC can't be assumed to just
> > > work against q35, even if the OS in the image supports it.
> > > 
> > > If we want to get q35 broadly used for modern OS, then IMHO the best
> > > option is to record that metadata in libosinfo, as ew do for other
> > > virtual hardware preferences.  That doesn't fix the problem of disk
> > > images that might not transparently boot between pc/q35, but at least
> > > avoids breaking OS that don't support q35 at all.
> > 
> > This leads to a more general question: sometimes the defaults
> > chosen by libvirt are obsolete or broken, and we might want to
> > change them.
> > 
> > Is there a process for changing defaults in libvirt, or libvirt
> > is bound by past decisions forever?
> 
> If the default was always recorded in the domain XML it is safe to
> change it because it will not affect already existing domains or
> migration but if the default is not recorded in the domain XML there
> needs to be a lot of compatibility code.

That's the opposite of what Daniel said above, isn't it?  The
machine-type is always recorded in the domain XML, but it's still
considered unsafe to change.

On Tue, Jun 05, 2018 at 11:03:46AM -0300, Eduardo Habkost wrote:
> On Tue, Jun 05, 2018 at 03:44:39PM +0200, Pavel Hrdina wrote:
> > On Tue, Jun 05, 2018 at 10:35:38AM -0300, Eduardo Habkost wrote:
> > > On Tue, Jun 05, 2018 at 02:12:32PM +0100, Daniel P. Berrangé wrote:
> > > > On Tue, Jun 05, 2018 at 10:06:46AM -0300, Eduardo Habkost wrote:
> > > > > (CCing libvir-list)
> > > > > 
> > > > > On Tue, Jun 05, 2018 at 09:43:00AM +0100, Daniel P. Berrangé wrote:
> > > > > > On Tue, Jun 05, 2018 at 09:27:46AM +0200, Gerd Hoffmann wrote:
> > > > > > >   Hi,
> > > > > > > 
> > > > > > > > >   Add to that shortcuts like -cdrom
> > > > > > > > > stop working,
> > > > > > > > 
> > > > > > > > Maybe is fixable.
> > > > > > > 
> > > > > > > Already fixed for ages.
> > > > > > > 
> > > > > > > > I see marking Q35 as the default machine a first step.
> > > > > > > 
> > > > > > > Maybe the better option is to go the arm route:  Just don't define a
> > > > > > > default, so users have to specify pc or q35.  That will make them notice
> > > > > > > there is a world beside 'pc', and we also avoid breaking things
> > > > > > > silently.
> > > > > > 
> > > > > > If QEMU removes the default, then libvirt will have to hardcode
> > > > > > 'pc' as the default to maintain back compatibility, so I don't
> > > > > > think that ends up as a net win
> > > > > 
> > > > > Is there an actual promise to never change the default
> > > > > machine-type documented in the libvirt API, or is this just fear
> > > > > of breaking existing code?
> > > > 
> > > > The risk of breaking things that currently work. Some of the things
> > > > discussed here that risk breaking users if QEMU changes the default,
> > > > have the same risk if libvirt changes the default.
> > > > 
> > > > eg old OS versions that only work with PC, or more commonly pre-existing
> > > > cloud disk images that were built against PC can't be assumed to just
> > > > work against q35, even if the OS in the image supports it.
> > > > 
> > > > If we want to get q35 broadly used for modern OS, then IMHO the best
> > > > option is to record that metadata in libosinfo, as ew do for other
> > > > virtual hardware preferences.  That doesn't fix the problem of disk
> > > > images that might not transparently boot between pc/q35, but at least
> > > > avoids breaking OS that don't support q35 at all.
> > > 
> > > This leads to a more general question: sometimes the defaults
> > > chosen by libvirt are obsolete or broken, and we might want to
> > > change them.
> > > 
> > > Is there a process for changing defaults in libvirt, or libvirt
> > > is bound by past decisions forever?
> > 
> > If the default was always recorded in the domain XML it is safe to
> > change it because it will not affect already existing domains or
> > migration but if the default is not recorded in the domain XML there
> > needs to be a lot of compatibility code.
> 
> That's the opposite of what Daniel said above, isn't it?  The
> machine-type is always recorded in the domain XML, but it's still
> considered unsafe to change.

Yes, I disagree with that Pavel has written here. The domain XML recording
of settings is critical for preserving guest ABI for migration, etc, so
obviously must be stable. Even if there is *no* domain XML yet, however,
libvirt still aims to avoid changes in defaults that are liable to break
an existing mgmt application creating guests in future.

Regards,
Daniel

On Tue, Jun 05, 2018 at 11:03:46AM -0300, Eduardo Habkost wrote:
> On Tue, Jun 05, 2018 at 03:44:39PM +0200, Pavel Hrdina wrote:
> > On Tue, Jun 05, 2018 at 10:35:38AM -0300, Eduardo Habkost wrote:
> > > On Tue, Jun 05, 2018 at 02:12:32PM +0100, Daniel P. Berrangé wrote:
> > > > On Tue, Jun 05, 2018 at 10:06:46AM -0300, Eduardo Habkost wrote:
> > > > > (CCing libvir-list)
> > > > > 
> > > > > On Tue, Jun 05, 2018 at 09:43:00AM +0100, Daniel P. Berrangé wrote:
> > > > > > On Tue, Jun 05, 2018 at 09:27:46AM +0200, Gerd Hoffmann wrote:
> > > > > > >   Hi,
> > > > > > > 
> > > > > > > > >   Add to that shortcuts like -cdrom
> > > > > > > > > stop working,
> > > > > > > > 
> > > > > > > > Maybe is fixable.
> > > > > > > 
> > > > > > > Already fixed for ages.
> > > > > > > 
> > > > > > > > I see marking Q35 as the default machine a first step.
> > > > > > > 
> > > > > > > Maybe the better option is to go the arm route:  Just don't define a
> > > > > > > default, so users have to specify pc or q35.  That will make them notice
> > > > > > > there is a world beside 'pc', and we also avoid breaking things
> > > > > > > silently.
> > > > > > 
> > > > > > If QEMU removes the default, then libvirt will have to hardcode
> > > > > > 'pc' as the default to maintain back compatibility, so I don't
> > > > > > think that ends up as a net win
> > > > > 
> > > > > Is there an actual promise to never change the default
> > > > > machine-type documented in the libvirt API, or is this just fear
> > > > > of breaking existing code?
> > > > 
> > > > The risk of breaking things that currently work. Some of the things
> > > > discussed here that risk breaking users if QEMU changes the default,
> > > > have the same risk if libvirt changes the default.
> > > > 
> > > > eg old OS versions that only work with PC, or more commonly pre-existing
> > > > cloud disk images that were built against PC can't be assumed to just
> > > > work against q35, even if the OS in the image supports it.
> > > > 
> > > > If we want to get q35 broadly used for modern OS, then IMHO the best
> > > > option is to record that metadata in libosinfo, as ew do for other
> > > > virtual hardware preferences.  That doesn't fix the problem of disk
> > > > images that might not transparently boot between pc/q35, but at least
> > > > avoids breaking OS that don't support q35 at all.
> > > 
> > > This leads to a more general question: sometimes the defaults
> > > chosen by libvirt are obsolete or broken, and we might want to
> > > change them.
> > > 
> > > Is there a process for changing defaults in libvirt, or libvirt
> > > is bound by past decisions forever?
> > 
> > If the default was always recorded in the domain XML it is safe to
> > change it because it will not affect already existing domains or
> > migration but if the default is not recorded in the domain XML there
> > needs to be a lot of compatibility code.
> 
> That's the opposite of what Daniel said above, isn't it?  The
> machine-type is always recorded in the domain XML, but it's still
> considered unsafe to change.

It's not opposite.  The thing is that some of the defaults are not that
easy change for other reasons, not from libvirt POV or because of ABI
stability.  In general yes, it is possible to change it but in some
cases it might not be good idea, one example could be the machine time.

Changing default machine time affects the whole guest and may break
a lot of use-cases but changing some default device model if the current
default is obsolete and most of the OSes supports the new one should
be safe.

Pavel

On Tue, Jun 05, 2018 at 03:07:04PM +0100, Daniel P. Berrangé wrote:
> On Tue, Jun 05, 2018 at 11:03:46AM -0300, Eduardo Habkost wrote:
> > On Tue, Jun 05, 2018 at 03:44:39PM +0200, Pavel Hrdina wrote:
> > > On Tue, Jun 05, 2018 at 10:35:38AM -0300, Eduardo Habkost wrote:
> > > > On Tue, Jun 05, 2018 at 02:12:32PM +0100, Daniel P. Berrangé wrote:
> > > > > On Tue, Jun 05, 2018 at 10:06:46AM -0300, Eduardo Habkost wrote:
> > > > > > (CCing libvir-list)
> > > > > > 
> > > > > > On Tue, Jun 05, 2018 at 09:43:00AM +0100, Daniel P. Berrangé wrote:
> > > > > > > On Tue, Jun 05, 2018 at 09:27:46AM +0200, Gerd Hoffmann wrote:
> > > > > > > >   Hi,
> > > > > > > > 
> > > > > > > > > >   Add to that shortcuts like -cdrom
> > > > > > > > > > stop working,
> > > > > > > > > 
> > > > > > > > > Maybe is fixable.
> > > > > > > > 
> > > > > > > > Already fixed for ages.
> > > > > > > > 
> > > > > > > > > I see marking Q35 as the default machine a first step.
> > > > > > > > 
> > > > > > > > Maybe the better option is to go the arm route:  Just don't define a
> > > > > > > > default, so users have to specify pc or q35.  That will make them notice
> > > > > > > > there is a world beside 'pc', and we also avoid breaking things
> > > > > > > > silently.
> > > > > > > 
> > > > > > > If QEMU removes the default, then libvirt will have to hardcode
> > > > > > > 'pc' as the default to maintain back compatibility, so I don't
> > > > > > > think that ends up as a net win
> > > > > > 
> > > > > > Is there an actual promise to never change the default
> > > > > > machine-type documented in the libvirt API, or is this just fear
> > > > > > of breaking existing code?
> > > > > 
> > > > > The risk of breaking things that currently work. Some of the things
> > > > > discussed here that risk breaking users if QEMU changes the default,
> > > > > have the same risk if libvirt changes the default.
> > > > > 
> > > > > eg old OS versions that only work with PC, or more commonly pre-existing
> > > > > cloud disk images that were built against PC can't be assumed to just
> > > > > work against q35, even if the OS in the image supports it.
> > > > > 
> > > > > If we want to get q35 broadly used for modern OS, then IMHO the best
> > > > > option is to record that metadata in libosinfo, as ew do for other
> > > > > virtual hardware preferences.  That doesn't fix the problem of disk
> > > > > images that might not transparently boot between pc/q35, but at least
> > > > > avoids breaking OS that don't support q35 at all.
> > > > 
> > > > This leads to a more general question: sometimes the defaults
> > > > chosen by libvirt are obsolete or broken, and we might want to
> > > > change them.
> > > > 
> > > > Is there a process for changing defaults in libvirt, or libvirt
> > > > is bound by past decisions forever?
> > > 
> > > If the default was always recorded in the domain XML it is safe to
> > > change it because it will not affect already existing domains or
> > > migration but if the default is not recorded in the domain XML there
> > > needs to be a lot of compatibility code.
> > 
> > That's the opposite of what Daniel said above, isn't it?  The
> > machine-type is always recorded in the domain XML, but it's still
> > considered unsafe to change.
> 
> Yes, I disagree with that Pavel has written here. The domain XML recording
> of settings is critical for preserving guest ABI for migration, etc, so
> obviously must be stable. Even if there is *no* domain XML yet, however,
> libvirt still aims to avoid changes in defaults that are liable to break
> an existing mgmt application creating guests in future.

Yes in general we try to avoid changing defaults and no it's possible to
do it if there is good reason <568887a32f9985b95d998dd0d675255ea985013f>.

So technically there is a way but usually it's not good idea.  I should
have noted in the first reply that machine type is huge change and that
my statement applies to smaller changes.

Pavel

On 06/05/2018 04:29 PM, Daniel P. Berrangé wrote:
> On Tue, Jun 05, 2018 at 04:20:46PM +0300, Marcel Apfelbaum wrote:
>>
>> On 06/05/2018 11:43 AM, Daniel P. Berrangé wrote:
>>> On Tue, Jun 05, 2018 at 09:27:46AM +0200, Gerd Hoffmann wrote:
>>>>     Hi,
>>>>
>>>>>>     Add to that shortcuts like -cdrom
>>>>>> stop working,
>>>>> Maybe is fixable.
>>>> Already fixed for ages.
>>>>
>>>>> I see marking Q35 as the default machine a first step.
>>>> Maybe the better option is to go the arm route:  Just don't define a
>>>> default, so users have to specify pc or q35.  That will make them notice
>>>> there is a world beside 'pc', and we also avoid breaking things
>>>> silently.
>> It can work, sure. And we can add user hints: "Use q35 for ...., select pc
>> if..."
>>
>>> If QEMU removes the default, then libvirt will have to hardcode
>>> 'pc' as the default to maintain back compatibility, so I don't
>>> think that ends up as a net win
>> Can't libvirt preserve 'pc' for existing domains, while defaulting to q35
>> the creation of new domains ? This way it aligns with Gerd's proposal of no
>> default x86 machine.
> Existing domains wasn't the case I was concerned about. Consider you have
> libvirt 4.4.0 intsalled and you deploy a *new* domain from a prebuilt
> disk image "foo".

Using Laszlo idea (I think):
  1) disk image "foo"/no info -> use 'pc' machine.
  2) no prebuild image (clean install?) ->  use q35 and add this info to 
xml
In the meantime find a way to embed the supported machine type(s) in the 
image.
(I think the above idea was already discussed, not sure what was the 
conclusion )


Thanks,
Marcel

>   Now update to a libvirt or QEMU which changes to q35
> and try to deploy another new domain from the same prebuilt disk
> image "foo". It may not work now if that disk image doesn't support
> q35. That would be a regression from the user's POV, whether libvirt or
> qemu has changed the default.
>
> Regards,
> Daniel

On Tue, Jun 05, 2018 at 06:56:09PM +0300, Marcel Apfelbaum wrote:
> 
> 
> On 06/05/2018 04:29 PM, Daniel P. Berrangé wrote:
> > On Tue, Jun 05, 2018 at 04:20:46PM +0300, Marcel Apfelbaum wrote:
> > > 
> > > On 06/05/2018 11:43 AM, Daniel P. Berrangé wrote:
> > > > On Tue, Jun 05, 2018 at 09:27:46AM +0200, Gerd Hoffmann wrote:
> > > > >     Hi,
> > > > > 
> > > > > > >     Add to that shortcuts like -cdrom
> > > > > > > stop working,
> > > > > > Maybe is fixable.
> > > > > Already fixed for ages.
> > > > > 
> > > > > > I see marking Q35 as the default machine a first step.
> > > > > Maybe the better option is to go the arm route:  Just don't define a
> > > > > default, so users have to specify pc or q35.  That will make them notice
> > > > > there is a world beside 'pc', and we also avoid breaking things
> > > > > silently.
> > > It can work, sure. And we can add user hints: "Use q35 for ...., select pc
> > > if..."
> > > 
> > > > If QEMU removes the default, then libvirt will have to hardcode
> > > > 'pc' as the default to maintain back compatibility, so I don't
> > > > think that ends up as a net win
> > > Can't libvirt preserve 'pc' for existing domains, while defaulting to q35
> > > the creation of new domains ? This way it aligns with Gerd's proposal of no
> > > default x86 machine.
> > Existing domains wasn't the case I was concerned about. Consider you have
> > libvirt 4.4.0 intsalled and you deploy a *new* domain from a prebuilt
> > disk image "foo".
> 
> Using Laszlo idea (I think):
>  1) disk image "foo"/no info -> use 'pc' machine.
>  2) no prebuild image (clean install?) ->  use q35 and add this info to xml

NB there's no reliable distinction of "new" from "old" guest install
from libvirt's POV. When we receive XML from an application we've
no way of knowing if this is a brand new guest about to be installed
or a previously installed guest.

Regards,
Daniel

On Tue, Jun 05, 2018 at 02:12:32PM +0100, Daniel P. Berrangé wrote:
> eg old OS versions that only work with PC, or more commonly pre-existing
> cloud disk images that were built against PC can't be assumed to just
> work against q35, even if the OS in the image supports it.

I don't understand that part - when using libvirt domain xml records the
machine type used for the install, so it seems that installed images
won't be affected.

On Tue, Jun 05, 2018 at 02:29:48PM +0100, Daniel P. Berrangé wrote:
> Existing domains wasn't the case I was concerned about. Consider you have
> libvirt 4.4.0 intsalled and you deploy a *new* domain from a prebuilt
> disk image "foo".

I see. How about q35 as default for new domains only?

On Tue, Jun 05, 2018 at 02:51:52PM +0100, Daniel P. Berrangé wrote:
> On Tue, Jun 05, 2018 at 03:44:14PM +0200, Laszlo Ersek wrote:
> > On 06/05/18 15:29, Daniel P. Berrangé wrote:
> > > On Tue, Jun 05, 2018 at 04:20:46PM +0300, Marcel Apfelbaum wrote:
> > >>
> > >>
> > >> On 06/05/2018 11:43 AM, Daniel P. Berrangé wrote:
> > >>> On Tue, Jun 05, 2018 at 09:27:46AM +0200, Gerd Hoffmann wrote:
> > >>>>    Hi,
> > >>>>
> > >>>>>>    Add to that shortcuts like -cdrom
> > >>>>>> stop working,
> > >>>>> Maybe is fixable.
> > >>>> Already fixed for ages.
> > >>>>
> > >>>>> I see marking Q35 as the default machine a first step.
> > >>>> Maybe the better option is to go the arm route:  Just don't define a
> > >>>> default, so users have to specify pc or q35.  That will make them notice
> > >>>> there is a world beside 'pc', and we also avoid breaking things
> > >>>> silently.
> > >>
> > >> It can work, sure. And we can add user hints: "Use q35 for ...., select pc
> > >> if..."
> > >>
> > >>> If QEMU removes the default, then libvirt will have to hardcode
> > >>> 'pc' as the default to maintain back compatibility, so I don't
> > >>> think that ends up as a net win
> > >>
> > >> Can't libvirt preserve 'pc' for existing domains, while defaulting to q35
> > >> the creation of new domains ? This way it aligns with Gerd's proposal of no
> > >> default x86 machine.
> > > 
> > > Existing domains wasn't the case I was concerned about. Consider you have
> > > libvirt 4.4.0 intsalled and you deploy a *new* domain from a prebuilt
> > > disk image "foo". Now update to a libvirt or QEMU which changes to q35
> > > and try to deploy another new domain from the same prebuilt disk
> > > image "foo". It may not work now if that disk image doesn't support
> > > q35. That would be a regression from the user's POV, whether libvirt or
> > > qemu has changed the default.
> > 
> > How about:
> > - "create new domain with empty disk" --> i440fx now, q35 later
> 
> "empty disk" is not something that can be determined by the
> host - libvirt might not even have direct access to the disk
> at the time this info would be needed.
> 
> > - "create new domain from domain XML and disk image" --> whatever the
> >   domain definition dictates
> > - "create new domain from disk image and no domain XML" --> assume
> >   i440fx forever (with a detailed board / device config that's used for
> >   all legacy (definition-less) disk images)
> 
> 
> 
> > - convince disk image distributors to provide their domain definitions
> >   with their disks (need not be libvirt domain XML, other definitions
> >   might work)
> 
> Libvirt domain XML is absolutely not suitable - it is a host specific
> instantiation of a guest, that is not guaranteed to be portable to
> any other host.
> 
> Funnily enough though, I just remembered that 10 years ago we invented
> another XML format called "virt-image XML", that went along with a
> "virt-image" command line tool
> 
>   https://github.com/virt-manager/virt-manager/blob/2e7d477156e9d0f6fb218fa19fc00d6229d33e85/man/virt-image-xml.pod
> 
> This was rarely used because the "virt-image" tool itself was rather
> broken by design, so we eventually deleted this entirely.
> 
> The virt-image XML  description though could be resurrected as it
> is largely relevant to the conversation.

Oh, that might be a nice thing to put into qcow2 meta-data.
(Hopefully in a format that's easier to parse and write than xml).


> > - write converters from those other definition formats to libvirt XML,
> >   or QEMU cfg file?
> 
> 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 :|

On Tue, Jun 05, 2018 at 07:16:56PM +0300, Michael S. Tsirkin wrote:
> On Tue, Jun 05, 2018 at 02:12:32PM +0100, Daniel P. Berrangé wrote:
> > eg old OS versions that only work with PC, or more commonly pre-existing
> > cloud disk images that were built against PC can't be assumed to just
> > work against q35, even if the OS in the image supports it.
> 
> I don't understand that part - when using libvirt domain xml records the
> machine type used for the install, so it seems that installed images
> won't be affected.

There's no libvirt XML for distributed cloud images, it is created whenever
the image is instantiated. Libvirt also doesn't require use of its persistent
guest feature - it is possible to create so called "transient" guests with
libvirt where you just provide an XML doc at each boot up, and libvirt does
not save this XML between boots. Even if an app is using persistent libvirt
XML they might not boot the VM on the same host each time, so the previous
persistent XML may not be available at next boot up. So there's many ways
existing deployed guests can be affected by changes in defaults, even when
libvirt records info in the XML.

Regards,
Daniel

On Tue, Jun 05, 2018 at 07:20:24PM +0300, Michael S. Tsirkin wrote:
> On Tue, Jun 05, 2018 at 02:29:48PM +0100, Daniel P. Berrangé wrote:
> > Existing domains wasn't the case I was concerned about. Consider you have
> > libvirt 4.4.0 intsalled and you deploy a *new* domain from a prebuilt
> > disk image "foo".
> 
> I see. How about q35 as default for new domains only?

There's no concept of "new" or "old" domains in libvirt. It just sees XML
and boots it and has no way of knowing if this is a brand new deployment
never booted before or an old deployed booted for the 1000th time.

Regards,
Daniel

On Tue, Jun 05, 2018 at 05:23:59PM +0100, Daniel P. Berrangé wrote:
> On Tue, Jun 05, 2018 at 07:20:24PM +0300, Michael S. Tsirkin wrote:
> > On Tue, Jun 05, 2018 at 02:29:48PM +0100, Daniel P. Berrangé wrote:
> > > Existing domains wasn't the case I was concerned about. Consider you have
> > > libvirt 4.4.0 intsalled and you deploy a *new* domain from a prebuilt
> > > disk image "foo".
> > 
> > I see. How about q35 as default for new domains only?
> 
> There's no concept of "new" or "old" domains in libvirt. It just sees XML
> and boots it and has no way of knowing if this is a brand new deployment
> never booted before or an old deployed booted for the 1000th time.
> 
> Regards,
> Daniel

Oh I mean when XML is created using e.g. virt-install

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

Getting back to this discussion:

On Tue, Jun 05, 2018 at 09:43:00AM +0100, Daniel P. Berrangé wrote:
> On Tue, Jun 05, 2018 at 09:27:46AM +0200, Gerd Hoffmann wrote:
> >   Hi,
> > 
> > > >   Add to that shortcuts like -cdrom
> > > > stop working,
> > > 
> > > Maybe is fixable.
> > 
> > Already fixed for ages.
> > 
> > > I see marking Q35 as the default machine a first step.
> > 
> > Maybe the better option is to go the arm route:  Just don't define a
> > default, so users have to specify pc or q35.  That will make them notice
> > there is a world beside 'pc', and we also avoid breaking things
> > silently.
> 
> If QEMU removes the default, then libvirt will have to hardcode
> 'pc' as the default to maintain back compatibility, so I don't
> think that ends up as a net win

I believe there's consensus that applications blindly relying on
the default machine-type when creating a domain is a bad idea.

That said, can we deprecate this feature in libvirt, encourage
applications to always specify an explicit machine-type, thus
making it possible to deprecate the i440fx machine-types one day?

On Wed, Jun 13, 2018 at 03:05:08PM -0300, Eduardo Habkost wrote:
> Getting back to this discussion:
> 
> On Tue, Jun 05, 2018 at 09:43:00AM +0100, Daniel P. Berrangé wrote:
> > On Tue, Jun 05, 2018 at 09:27:46AM +0200, Gerd Hoffmann wrote:
> > >   Hi,
> > > 
> > > > >   Add to that shortcuts like -cdrom
> > > > > stop working,
> > > > 
> > > > Maybe is fixable.
> > > 
> > > Already fixed for ages.
> > > 
> > > > I see marking Q35 as the default machine a first step.
> > > 
> > > Maybe the better option is to go the arm route:  Just don't define a
> > > default, so users have to specify pc or q35.  That will make them notice
> > > there is a world beside 'pc', and we also avoid breaking things
> > > silently.
> > 
> > If QEMU removes the default, then libvirt will have to hardcode
> > 'pc' as the default to maintain back compatibility, so I don't
> > think that ends up as a net win
> 
> I believe there's consensus that applications blindly relying on
> the default machine-type when creating a domain is a bad idea.
> 
> That said, can we deprecate this feature in libvirt, encourage
> applications to always specify an explicit machine-type, thus
> making it possible to deprecate the i440fx machine-types one day?

Well from libvirt's POV this scenario arrives if a mgmt app simply omits
the relevant element/attribute from the XML config. Deprecating something
implies that in future we'd drop support for it, but we're never going
to make this mandatory in libvirt as that would be a regression in
behaviour from libvirt's POV. So I don't think it is something we would
deprecate.

I'm happy to see an update to the XML docs to strongly recommend that
apps always provide a machine type though. Many will likely already be
doing so with aarch64 to get the "virt" machine type anyway, since the
default libvirt picks is often not suitable.

Regards,
Daniel

On Thu, Jun 14, 2018 at 09:09:48AM +0100, Daniel P. Berrangé wrote:
> On Wed, Jun 13, 2018 at 03:05:08PM -0300, Eduardo Habkost wrote:
> > Getting back to this discussion:
> > 
> > On Tue, Jun 05, 2018 at 09:43:00AM +0100, Daniel P. Berrangé wrote:
> > > On Tue, Jun 05, 2018 at 09:27:46AM +0200, Gerd Hoffmann wrote:
> > > >   Hi,
> > > > 
> > > > > >   Add to that shortcuts like -cdrom
> > > > > > stop working,
> > > > > 
> > > > > Maybe is fixable.
> > > > 
> > > > Already fixed for ages.
> > > > 
> > > > > I see marking Q35 as the default machine a first step.
> > > > 
> > > > Maybe the better option is to go the arm route:  Just don't define a
> > > > default, so users have to specify pc or q35.  That will make them notice
> > > > there is a world beside 'pc', and we also avoid breaking things
> > > > silently.
> > > 
> > > If QEMU removes the default, then libvirt will have to hardcode
> > > 'pc' as the default to maintain back compatibility, so I don't
> > > think that ends up as a net win
> > 
> > I believe there's consensus that applications blindly relying on
> > the default machine-type when creating a domain is a bad idea.
> > 
> > That said, can we deprecate this feature in libvirt, encourage
> > applications to always specify an explicit machine-type, thus
> > making it possible to deprecate the i440fx machine-types one day?
> 
> Well from libvirt's POV this scenario arrives if a mgmt app simply omits
> the relevant element/attribute from the XML config. Deprecating something
> implies that in future we'd drop support for it, but we're never going
> to make this mandatory in libvirt as that would be a regression in
> behaviour from libvirt's POV. So I don't think it is something we would
> deprecate.

Does libvirt really have an option, here?  I'm sure that sooner
or later somebody will distribute QEMU binaries without "pc".


> I'm happy to see an update to the XML docs to strongly recommend that
> apps always provide a machine type though. Many will likely already be
> doing so with aarch64 to get the "virt" machine type anyway, since the
> default libvirt picks is often not suitable.

Well, if you don't want to explicitly remove the default-is-pc
feature from libvirt, strongly recommending against it (and
letting people know that it may stop working in the future) might
be enough.

On Thu, Jun 14, 2018 at 11:50:56PM -0300, Eduardo Habkost wrote:
> On Thu, Jun 14, 2018 at 09:09:48AM +0100, Daniel P. Berrangé wrote:
> > On Wed, Jun 13, 2018 at 03:05:08PM -0300, Eduardo Habkost wrote:
> > > Getting back to this discussion:
> > > 
> > > On Tue, Jun 05, 2018 at 09:43:00AM +0100, Daniel P. Berrangé wrote:
> > > > On Tue, Jun 05, 2018 at 09:27:46AM +0200, Gerd Hoffmann wrote:
> > > > >   Hi,
> > > > > 
> > > > > > >   Add to that shortcuts like -cdrom
> > > > > > > stop working,
> > > > > > 
> > > > > > Maybe is fixable.
> > > > > 
> > > > > Already fixed for ages.
> > > > > 
> > > > > > I see marking Q35 as the default machine a first step.
> > > > > 
> > > > > Maybe the better option is to go the arm route:  Just don't define a
> > > > > default, so users have to specify pc or q35.  That will make them notice
> > > > > there is a world beside 'pc', and we also avoid breaking things
> > > > > silently.
> > > > 
> > > > If QEMU removes the default, then libvirt will have to hardcode
> > > > 'pc' as the default to maintain back compatibility, so I don't
> > > > think that ends up as a net win
> > > 
> > > I believe there's consensus that applications blindly relying on
> > > the default machine-type when creating a domain is a bad idea.
> > > 
> > > That said, can we deprecate this feature in libvirt, encourage
> > > applications to always specify an explicit machine-type, thus
> > > making it possible to deprecate the i440fx machine-types one day?
> > 
> > Well from libvirt's POV this scenario arrives if a mgmt app simply omits
> > the relevant element/attribute from the XML config. Deprecating something
> > implies that in future we'd drop support for it, but we're never going
> > to make this mandatory in libvirt as that would be a regression in
> > behaviour from libvirt's POV. So I don't think it is something we would
> > deprecate.
> 
> Does libvirt really have an option, here?  I'm sure that sooner
> or later somebody will distribute QEMU binaries without "pc".

Sure if someone does that, we'll have no choice, but as long as 'pc' is
shipped we shouldn't gratuitously break apps by changing the default.


Regards,
Daniel

On Fri, Jun 15, 2018 at 10:03:14AM +0100, Daniel P. Berrangé wrote:
> On Thu, Jun 14, 2018 at 11:50:56PM -0300, Eduardo Habkost wrote:
> > On Thu, Jun 14, 2018 at 09:09:48AM +0100, Daniel P. Berrangé wrote:
> > > On Wed, Jun 13, 2018 at 03:05:08PM -0300, Eduardo Habkost wrote:
> > > > Getting back to this discussion:
> > > > 
> > > > On Tue, Jun 05, 2018 at 09:43:00AM +0100, Daniel P. Berrangé wrote:
> > > > > On Tue, Jun 05, 2018 at 09:27:46AM +0200, Gerd Hoffmann wrote:
> > > > > >   Hi,
> > > > > > 
> > > > > > > >   Add to that shortcuts like -cdrom
> > > > > > > > stop working,
> > > > > > > 
> > > > > > > Maybe is fixable.
> > > > > > 
> > > > > > Already fixed for ages.
> > > > > > 
> > > > > > > I see marking Q35 as the default machine a first step.
> > > > > > 
> > > > > > Maybe the better option is to go the arm route:  Just don't define a
> > > > > > default, so users have to specify pc or q35.  That will make them notice
> > > > > > there is a world beside 'pc', and we also avoid breaking things
> > > > > > silently.
> > > > > 
> > > > > If QEMU removes the default, then libvirt will have to hardcode
> > > > > 'pc' as the default to maintain back compatibility, so I don't
> > > > > think that ends up as a net win
> > > > 
> > > > I believe there's consensus that applications blindly relying on
> > > > the default machine-type when creating a domain is a bad idea.
> > > > 
> > > > That said, can we deprecate this feature in libvirt, encourage
> > > > applications to always specify an explicit machine-type, thus
> > > > making it possible to deprecate the i440fx machine-types one day?
> > > 
> > > Well from libvirt's POV this scenario arrives if a mgmt app simply omits
> > > the relevant element/attribute from the XML config. Deprecating something
> > > implies that in future we'd drop support for it, but we're never going
> > > to make this mandatory in libvirt as that would be a regression in
> > > behaviour from libvirt's POV. So I don't think it is something we would
> > > deprecate.
> > 
> > Does libvirt really have an option, here?  I'm sure that sooner
> > or later somebody will distribute QEMU binaries without "pc".
> 
> Sure if someone does that, we'll have no choice, but as long as 'pc' is
> shipped we shouldn't gratuitously break apps by changing the default.

Right.  I just want to make sure "omitting the machine-type may
stop working in the future" is documented somehow.

On Mon, Jun 18, 2018 at 02:14:31PM -0300, Eduardo Habkost wrote:
> > Sure if someone does that, we'll have no choice, but as long as 'pc' is
> > shipped we shouldn't gratuitously break apps by changing the default.
> 
> Right.  I just want to make sure "omitting the machine-type may
> stop working in the future" is documented somehow.

I still think we should just add links to the qemu binary and
use ARGV to detect the machine type.

qemu-pc-i386
qemu-q35-x86_64

etc.

> -- 
> Eduardo

On Mon, Jun 18, 2018 at 08:18:16PM +0300, Michael S. Tsirkin wrote:
> On Mon, Jun 18, 2018 at 02:14:31PM -0300, Eduardo Habkost wrote:
> > > Sure if someone does that, we'll have no choice, but as long as 'pc' is
> > > shipped we shouldn't gratuitously break apps by changing the default.
> > 
> > Right.  I just want to make sure "omitting the machine-type may
> > stop working in the future" is documented somehow.
> 
> I still think we should just add links to the qemu binary and
> use ARGV to detect the machine type.
> 
> qemu-pc-i386
> qemu-q35-x86_64

Why having separate QEMU binaries would help?  We still need to
define and document what will happen when both the machine-type
and the QEMU binary are omitted in the domain XML.

Personally I prefer to document this as "we recommend you always
specify the machine-type" instead of "we recommend you always
specify the QEMU binary path".

On 18 June 2018 at 18:18, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Mon, Jun 18, 2018 at 02:14:31PM -0300, Eduardo Habkost wrote:
>> > Sure if someone does that, we'll have no choice, but as long as 'pc' is
>> > shipped we shouldn't gratuitously break apps by changing the default.
>>
>> Right.  I just want to make sure "omitting the machine-type may
>> stop working in the future" is documented somehow.
>
> I still think we should just add links to the qemu binary and
> use ARGV to detect the machine type.
>
> qemu-pc-i386
> qemu-q35-x86_64

Do you really want 60 different qemu-something-arm symlinks?

thanks
-- PMM

On Wed, Jun 20, 2018 at 06:33:51PM +0100, Peter Maydell wrote:
> On 18 June 2018 at 18:18, Michael S. Tsirkin <mst@redhat.com> wrote:
> > On Mon, Jun 18, 2018 at 02:14:31PM -0300, Eduardo Habkost wrote:
> >> > Sure if someone does that, we'll have no choice, but as long as 'pc' is
> >> > shipped we shouldn't gratuitously break apps by changing the default.
> >>
> >> Right.  I just want to make sure "omitting the machine-type may
> >> stop working in the future" is documented somehow.
> >
> > I still think we should just add links to the qemu binary and
> > use ARGV to detect the machine type.
> >
> > qemu-pc-i386
> > qemu-q35-x86_64
> 
> Do you really want 60 different qemu-something-arm symlinks?

Absolutely not !

Regards,
Daniel

On Wed, Jun 20, 2018 at 02:28:24PM -0300, Eduardo Habkost wrote:
> On Mon, Jun 18, 2018 at 08:18:16PM +0300, Michael S. Tsirkin wrote:
> > On Mon, Jun 18, 2018 at 02:14:31PM -0300, Eduardo Habkost wrote:
> > > > Sure if someone does that, we'll have no choice, but as long as 'pc' is
> > > > shipped we shouldn't gratuitously break apps by changing the default.
> > > 
> > > Right.  I just want to make sure "omitting the machine-type may
> > > stop working in the future" is documented somehow.
> > 
> > I still think we should just add links to the qemu binary and
> > use ARGV to detect the machine type.
> > 
> > qemu-pc-i386
> > qemu-q35-x86_64
> 
> Why having separate QEMU binaries would help?  We still need to
> define and document what will happen when both the machine-type
> and the QEMU binary are omitted in the domain XML.

It would not help libvirt at all, and in fact it would cause extra pain
for applications, because we don't have ability to associated separate
QEMU binaries with machine types in our capabilities design. So not
only would libvirt need changing, but apps using libvirt too.

> Personally I prefer to document this as "we recommend you always
> specify the machine-type" instead of "we recommend you always
> specify the QEMU binary path".

Indeed, the former is something apps already do in many cases.

Regards,
Daniel