Daniel P. Berrangé <berrange@xxxxxxxxxx> 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. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
