qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [libvirt] clean/simple Q35 support in libvirt+QEMU for


From: Daniel P . Berrangé
Subject: Re: [Qemu-devel] [libvirt] clean/simple Q35 support in libvirt+QEMU for guest OSes that don't support virtio-1.0
Date: Fri, 17 Aug 2018 14:24:15 +0100
User-agent: Mutt/1.10.1 (2018-07-13)

On Fri, Aug 17, 2018 at 03:13:22PM +0200, Markus Armbruster wrote:
> Daniel P. Berrangé <address@hidden> writes:
> 
> > On Fri, Aug 17, 2018 at 12:35:11PM +0200, Andrea Bolognani wrote:
> >> On Fri, 2018-08-17 at 10:29 +0100, Daniel P. Berrangé wrote:
> >> > On Thu, Aug 16, 2018 at 06:20:29PM -0400, Laine Stump wrote:
> >> > > 5) Some guest OSes that we still want to support (and which would
> >> > > otherwise work okay on a Q35 virtual machine) have virtio drivers too
> >> > > old to support virtio-1.0 (CentOS6 and RHEL6 are examples of such 
> >> > > OSes),
> >> > > but due to the chain of reasons listed above, the "standard" config for
> >> > > a Q35 guest generated by libvirt doesn't support virtio-0.9, hence
> >> > > doesn't support these guest OSes.
> >> > 
> >> > Note when talking about "support" you're really saying it from the
> >> > downstream vendor, specifically RHEL, POV. From upstream or Fedora POV
> >> > essentially all x86 OS ever made are in scope for running under QEMU
> >> > if suitable virtual hardware models have been provided. QEMU doesn't
> >> > maintain any whitelist of "supported" OS that differs from what is
> >> > technically capable of being run, in the way downstream vendors do.
> >> 
> >> Well, at least in the case of RHEL 6, "not supported" means that it
> >> will not boot at all on q35 with the default guest topology created
> >> by libvirt, so that's not really a downstream-only problem :)
> >
> > I mean from an upstream POV we still support RHEL-6 fine in i440fx,
> > so there's no reason to particularly care about RHEL-6 with q35
> > upstream.
> 
> Only true if Q35 provides nothing of value over i440FX for RHEL-6
> guests.  Does it?

Q35 has little technical benefit over i440fx for the majority of guest
deployments, regardless of guest OS.

It provides a more moderning looking platform (nice, but few users are
going to especially care about that), and lets you do secure boot with
OVMF firmware (blocker if you want that feature).

The desire to have everything use Q35 instead of i440fx is more about
downstream vendor testing / support, rather than a strong technical
feature gap requiring it.

> >           It is only downstream decision to try to force it to
> > use q35, despite it not working right today.

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 via email to

[Prev in Thread] Current Thread [Next in Thread]