[libvirt] [PATCH 0/7] Drop support for QEMU < 0.12.0

Daniel P. Berrange berrange at redhat.com
Fri Nov 6 10:07:47 UTC 2015


On Thu, Nov 05, 2015 at 06:15:52PM -0500, John Ferlan wrote:
> 
> 
> On 11/05/2015 12:33 PM, Daniel P. Berrange wrote:
> > The patches for introducing virtlogd will be significantly
> > simplified if we don't need to worry about parsing stderr
> > during startup. This is required prior to QEMU 0.11 so
> > that we can get the dyanamically allocated /dev/pty/NNN
> > paths.
> > 
> > The QEMU 0.12.1 release was shipped in RHEL-6 vintage
> > distros and is already quite old, so seems like a fair
> > target version to aim for as the minimum required.
> > 
> > By dropping support for anything older than QEMU 0.12.0
> > we can remove the code for parsing stderr. The QEMU 0.12.0
> > release was quite special because it was the release where
> > QEMU switched what I call its "modern" approach to configuration
> > via -device. A major part of the complexity of the QEMU command
> > line generator is due to need to support non-device syntax,
> > so by mandating QEMU 0.12.0 we'll be able to kill off alot
> > of conditional code. This series makes a start by assuming
> > existance of 5 features, -vnc, 'info chardev', -no-reboot,
> > -drive and -name, but there are a tonne more we can assume.
> > 
> 
> Gone through them all - in waves... first coverity, the w/ check and
> syntax-check builds.. and finally at least through the code looking for
> anything I can spot.  Only had a couple of questions, mostly formatting
> issues found.

Urgh, sorry about all the syntax-check stuff - I completely forgot to
run it before posting last night.

> Beyond the questions already asked - should we version bump too?
> After/with patch 1? Seems this is a fairly significant change... If Erik
> gets the virt-admin patches in that'd version bump anyway.

Yep, its probably the kind of thing that justifies a version bump

> I also assume your contention is "someone" could go through the
> following caps and start making similar adjustments?  Although based on
> reading - should QEMU_CAPS_DEVICE be in the list?

I'll probably do more fixes for the following caps myself, until
I end up gouging my eyes out after fixing one too many of the
test suite XML files, and then leave the rest for other motiviated
people :-) The CAPS_DEVICE stuff needs more investigation because
of the issues I recall with non-x86 platform support. It might be
that we can just say that non-x86 support requires an even newer
QEMU on the basis that we never had good non-x86 support until
relatively recently.

> > Looking at tests/qemuhelptest, we can drop about 30 capability
> > flag tests
> > 
> >             QEMU_CAPS_UUID,
> >             QEMU_CAPS_MIGRATE_QEMU_TCP,
> >             QEMU_CAPS_MIGRATE_QEMU_EXEC,
> >             QEMU_CAPS_DRIVE_CACHE_V2,
> >             QEMU_CAPS_DRIVE_FORMAT,
> >             QEMU_CAPS_DRIVE_SERIAL,
> >             QEMU_CAPS_DRIVE_READONLY,
> >             QEMU_CAPS_VGA,
> >             QEMU_CAPS_0_10,
> >             QEMU_CAPS_ENABLE_KVM,
> >             QEMU_CAPS_SDL,
> >             QEMU_CAPS_XEN_DOMID,
> >             QEMU_CAPS_MIGRATE_QEMU_UNIX,
> >             QEMU_CAPS_CHARDEV,
> >             QEMU_CAPS_BALLOON,
> >             QEMU_CAPS_DEVICE,
> >             QEMU_CAPS_SMP_TOPOLOGY,
> >             QEMU_CAPS_RTC,
> >             QEMU_CAPS_NO_HPET,
> >             QEMU_CAPS_BOOT_MENU,
> >             QEMU_CAPS_NAME_PROCESS,
> >             QEMU_CAPS_SMBIOS_TYPE,
> >             QEMU_CAPS_VGA_NONE,
> >             QEMU_CAPS_MIGRATE_QEMU_FD,
> >             QEMU_CAPS_DRIVE_AIO,
> >             QEMU_CAPS_NO_SHUTDOWN,
> >             QEMU_CAPS_PCI_ROMBAR,
> >             QEMU_CAPS_NO_ACPI,
> >             QEMU_CAPS_VIRTIO_BLK_SG_IO,
> >             QEMU_CAPS_CPU_HOST,
> >             QEMU_CAPS_VNC
> > 
> > The only slow complication is that some non-x86 architectures
> > were slow in converting to -device syntax, so we cannot
> > entirely assume -device is used everywhere.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|




More information about the libvir-list mailing list