qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
	pbonzini@redhat.com, rth@twiddle.net, qemu-devel@nongnu.org,
	"Michael S. Tsirkin" <mst@redhat.com>,
	libvir-list@redhat.com
Subject: Re: [Qemu-devel] libvirt default machine-type guarantees? (was Re: [PATCH RFC] hw/pc: set q35 as the default x86 machine)
Date: Tue, 5 Jun 2018 14:12:32 +0100	[thread overview]
Message-ID: <20180605131232.GG32286@redhat.com> (raw)
In-Reply-To: <20180605130646.GF7451@localhost.localdomain>

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

  reply	other threads:[~2018-06-05 13:12 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é [this message]
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é
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=20180605131232.GG32286@redhat.com \
    --to=berrange@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=marcel.apfelbaum@gmail.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).