[libvirt] [Qemu-devel] clean/simple Q35 support in libvirt+QEMU for guest OSes that don't support virtio-1.0

Markus Armbruster armbru at redhat.com
Fri Aug 17 13:13:22 UTC 2018


Daniel P. Berrangé <berrange at 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.




More information about the libvir-list mailing list