Daniel P. Berrangé <berrange(a)redhat.com> 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?
It is only downstream decision to try to force it to
use q35, despite it not working right today.