From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
qemu-devel@nongnu.org, pbonzini@redhat.com, rth@twiddle.net,
libvir-list@redhat.com
Subject: Re: [Qemu-devel] [PATCH RFC] hw/pc: set q35 as the default x86 machine
Date: Fri, 15 Jun 2018 10:03:14 +0100 [thread overview]
Message-ID: <20180615090314.GA31552@redhat.com> (raw)
In-Reply-To: <20180615025056.GB7451@localhost.localdomain>
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 :|
next prev parent reply other threads:[~2018-06-15 9:03 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-03 9:27 [Qemu-devel] [PATCH RFC] hw/pc: set q35 as the default x86 machine Marcel Apfelbaum
2018-06-04 1:38 ` Michael S. Tsirkin
2018-06-04 12:24 ` Igor Mammedov
2018-06-04 12:35 ` Paolo Bonzini
2018-06-04 18:09 ` John Snow
2018-06-04 12:54 ` Eduardo Habkost
2018-06-04 13:01 ` Daniel P. Berrangé
2018-06-04 13:26 ` Eduardo Habkost
2018-06-04 17:17 ` Michael S. Tsirkin
2018-06-04 18:30 ` Eduardo Habkost
2018-06-04 16:48 ` Michael S. Tsirkin
2018-06-04 16:56 ` Daniel P. Berrangé
2018-06-04 18:40 ` Marcel Apfelbaum
2018-06-04 21:08 ` Eduardo Habkost
2018-06-04 18:29 ` Marcel Apfelbaum
2018-06-05 7:27 ` Gerd Hoffmann
2018-06-05 8:43 ` Daniel P. Berrangé
2018-06-05 13:06 ` [Qemu-devel] libvirt default machine-type guarantees? (was Re: [PATCH RFC] hw/pc: set q35 as the default x86 machine) Eduardo Habkost
2018-06-05 13:12 ` Daniel P. Berrangé
2018-06-05 13:35 ` Eduardo Habkost
2018-06-05 13:41 ` Daniel P. Berrangé
2018-06-05 13:44 ` [Qemu-devel] [libvirt] " Pavel Hrdina
2018-06-05 14:03 ` Eduardo Habkost
2018-06-05 14:07 ` Daniel P. Berrangé
2018-06-05 14:36 ` Pavel Hrdina
2018-06-05 14:14 ` Pavel Hrdina
2018-06-05 16:16 ` [Qemu-devel] " Michael S. Tsirkin
2018-06-05 16:22 ` Daniel P. Berrangé
2018-06-05 13:20 ` [Qemu-devel] [PATCH RFC] hw/pc: set q35 as the default x86 machine Marcel Apfelbaum
2018-06-05 13:29 ` Daniel P. Berrangé
2018-06-05 13:44 ` Laszlo Ersek
2018-06-05 13:51 ` Daniel P. Berrangé
2018-06-05 16:22 ` Michael S. Tsirkin
2018-06-05 15:56 ` Marcel Apfelbaum
2018-06-05 16:01 ` Daniel P. Berrangé
2018-06-05 16:20 ` Michael S. Tsirkin
2018-06-05 16:23 ` Daniel P. Berrangé
2018-06-05 16:33 ` Michael S. Tsirkin
2018-06-13 18:05 ` Eduardo Habkost
2018-06-14 8:09 ` Daniel P. Berrangé
2018-06-15 2:50 ` Eduardo Habkost
2018-06-15 9:03 ` Daniel P. Berrangé [this message]
2018-06-18 17:14 ` Eduardo Habkost
2018-06-18 17:18 ` Michael S. Tsirkin
2018-06-20 17:28 ` Eduardo Habkost
2018-06-21 7:39 ` Daniel P. Berrangé
2018-06-20 17:33 ` Peter Maydell
2018-06-21 7:37 ` Daniel P. Berrangé
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180615090314.GA31552@redhat.com \
--to=berrange@redhat.com \
--cc=ehabkost@redhat.com \
--cc=kraxel@redhat.com \
--cc=libvir-list@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).