[libvirt] [PATCH] qemu: ensure default machine types don't change if QEMU changes

[Andrea Bolognani]

On Wed, 2018-08-08 at 10:19 +0100, Daniel P. Berrangé wrote:
> On Wed, Aug 08, 2018 at 10:12:59AM +0200, Andrea Bolognani wrote:
> > On Tue, 2018-08-07 at 16:01 +0100, Daniel P. Berrangé wrote:
> > > Someone could build a QEMU with the "pc" machine type deleted entirely,
> > > in which case libvirt won't find the default. The best we can do there
> > > is fallback to QEMU's own default.
> > 
> > Yeah, that's basically my point: wouldn't it be better to error
> > out rather than silently pick up a different default which is not
> > controlled by libvirt?
> > 
> > Of course that would be slightly annoying for people building their
> > own QEMU binaries with machine types ripped out, but I can't
> > imagine that population being very large and they're certainly
> > capable enough to figure out a way around the error; most people
> > will get their QEMU and libvirt through downstream distributions,
> > and if the downstream changes the list of machines available in
> > QEMU they should patch libvirt to update the table anyway.
> > 
> > Ultimately, users and applications should make sure they include
> > an explicit machine type in the guest XML, so ideally in time this
> > code path will not be hit at all.
> 
> Again, any change which mandates specifying a machine type in the XML
> is a regression for libvirt's users. Even if there's no 'pc' machine
> present in the QEMU binary we must continue to provide a default of
> some kind. Sure some apps would break in this case regardless, but
> other apps will still work. There's no valid reason why we should
> break use of an XML config like this as it works fine with both
> i440fx and q35 
> 
> <domain type='test'>
>   <name>demo</name>
>   <os>
>     <type>hvm</type>
>   </os>
>   <memory>261072</memory>
>   <vcpu>1</vcpu>
>   <devices>
>     <disk type='file'>
>       <source file='/var/lib/libvirt/images/demo.img'/>
>       <target bus="virtio" dev='vda'/>
>     </disk>
>     <interface type='bridge'>
>       <source bridge='br0'/>
>       <mac address='aa:00:00:00:00:11'/>
>       <model type="virtio-net"/>
>     </interface>
>     <console type='pty'/>
>   </devices>
> </domain>

For some definition of "works fine": if demo.img contains a
CentOS 6 installation, for example, the guest will get stuck
during boot... Arguably an error message about the pc machine
type not being available would be more useful to the user in
that case.

But I understand there are several cases in which such a
configuration will result in a perfectly acceptable guest
despite the differences in hardware between pc and q35, so
I see the value in not breaking that use case.

-- 
Andrea Bolognani / Red Hat / Virtualization