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

[Daniel P. Berrangé]

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:
> > On Tue, Aug 07, 2018 at 04:57:28PM +0200, Andrea Bolognani wrote:
> > > > > I wonder if we shouldn't just drop the default machine type handling
> > > > > altogether at this point, though.
> > > > 
> > > > That's impossible as it violates the back compatibility guarantee
> > > > and will certainly break applications
> > > 
> > > In abstract terms, given that the whole point of this exercise is
> > > shielding our users from changes in QEMU, why wouldn't we go the
> > > whole way and take QEMU defaults out of the picture entirely?
> > > 
> > > I just can't picture a scenario where ignoring the QEMU defaults
> > > would actually cause issues, since we're basically moving the
> > > defaults into libvirt with this commit... Can you describe such
> > > a scenario?
> > 
> > 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>


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 :|