Re: [libvirt] [Qemu-devel] [PATCH RFC] hw/pc: set q35 as the default x86 machine
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? -- Eduardo
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 -- |: 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 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. -- Eduardo
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 -- |: 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 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. -- Eduardo
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". -- Eduardo
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 -- |: 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 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 -- |: 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 :|
participants (4)
-
Daniel P. Berrangé -
Eduardo Habkost -
Michael S. Tsirkin -
Peter Maydell