It's been a while since we last bumped the minimum QEMU version.
Let's get rid of -help parsing and bring our test suite closer
to real world usage by implying lots of capabilities.

Ján Tomko (44):
  qemuxml2argvtest: Fix q35-virt-manager capabilities
  Delete bogus cpu-host-passthrough test
  Force QMP capability probing
  Require QEMU 1.3.0
  Deprecate QEMU_CAPS_PCI_MULTIFUNCTION
  Deprecate QEMU_CAPS_NETDEV
  Clean up qemuDomainAttachNetDevice
  Remove unused qemuDomainNetVLAN
  Remove qemuDomainSupportsNetdev
  Deprecate QEMU_CAPS_MONITOR_JSON
  Deprecate QEMU_CAPS_NO_USER_CONFIG
  Deprecate QEMU_CAPS_MEM_PATH
  Deprecate QEMU_CAPS_DRIVE_SERIAL
  Deprecate QEMU_CAPS_SDL
  Deprecate QEMU_CAPS_RTC
  Deprecate QEMU_CAPS_RTC_TD_HACK
  Deprecate QEMU_CAPS_VHOST_NET
  Deprecate QEMU_CAPS_NODEFCONFIG
  Deprecate QEMU_CAPS_BOOT_MENU
  Deprecate QEMU_CAPS_FSDEV
  Deprecate QEMU_CAPS_NAME_PROCESS
  Deprecate QEMU_CAPS_SMBIOS_TYPE
  Deprecate QEMU_CAPS_VGA_NONE
  Deprecate QEMU_CAPS_DRIVE_AIO
  Deprecate QEMU_CAPS_CHARDEV_SPICEVMC
  Deprecate QEMU_CAPS_DEVICE_SPICEVMC
  Deprecate QEMU_CAPS_DRIVE_CACHE_DIRECTSYNC
  Deprecate QEMU_CAPS_NO_SHUTDOWN
  Deprecate QEMU_CAPS_DRIVE_CACHE_UNSAFE
  Deprecate QEMU_CAPS_FSDEV_READONLY
  Deprecate QEMU_CAPS_DRIVE_COPY_ON_READ
  Deprecate QEMU_CAPS_FSDEV_WRITEOUT
  Deprecate QEMU_CAPS_DRIVE_IOTUNE
  Deprecate QEMU_CAPS_WAKEUP
  Deprecate QEMU_CAPS_NETDEV_BRIDGE
  Deprecate QEMU_CAPS_SECCOMP_SANDBOX
  Deprecate QEMU_CAPS_DTB
  Deprecate QEMU_CAPS_IPV6_MIGRATION
  Deprecate QEMU_CAPS_MACHINE_OPT
  Deprecate QEMU_CAPS_DUMP_GUEST_CORE
  Deprecate QEMU_CAPS_VNC_SHARE_POLICY
  Deprecate QEMU_CAPS_HOST_PCI_MULTIDOMAIN
  Deprecate QEMU_CAPS_DISPLAY
  Deprecate QEMU_CAPS_MACHINE_USB_OPT

 cfg.mk                                             |    2 +-
 src/qemu/qemu_capabilities.c                       |  931 +---------
 src/qemu/qemu_capabilities.h                       |   74 +-
 src/qemu/qemu_capspriv.h                           |   17 +-
 src/qemu/qemu_command.c                            |  690 +++----
 src/qemu/qemu_domain.c                             |   16 -
 src/qemu/qemu_domain.h                             |    6 -
 src/qemu/qemu_driver.c                             |   48 +-
 src/qemu/qemu_hotplug.c                            |  147 +-
 src/qemu/qemu_interface.c                          |    4 +-
 src/qemu/qemu_interface.h                          |    1 -
 src/qemu/qemu_migration.c                          |   10 +-
 src/qemu/qemu_process.c                            |   23 +-
 tests/Makefile.am                                  |    8 +-
 .../qemucapabilitiesdata/caps_1.2.2.x86_64.replies | 1886 --------------------
 tests/qemucapabilitiesdata/caps_1.2.2.x86_64.xml   |  172 --
 tests/qemucapabilitiesdata/caps_1.3.1.x86_64.xml   |   35 -
 tests/qemucapabilitiesdata/caps_1.4.2.x86_64.xml   |   35 -
 tests/qemucapabilitiesdata/caps_1.5.3.x86_64.xml   |   35 -
 tests/qemucapabilitiesdata/caps_1.6.0.x86_64.xml   |   35 -
 tests/qemucapabilitiesdata/caps_1.7.0.x86_64.xml   |   35 -
 tests/qemucapabilitiesdata/caps_2.1.1.x86_64.xml   |   35 -
 tests/qemucapabilitiesdata/caps_2.10.0.aarch64.xml |   35 -
 tests/qemucapabilitiesdata/caps_2.10.0.ppc64.xml   |   35 -
 tests/qemucapabilitiesdata/caps_2.10.0.s390x.xml   |   35 -
 tests/qemucapabilitiesdata/caps_2.10.0.x86_64.xml  |   35 -
 tests/qemucapabilitiesdata/caps_2.11.0.s390x.xml   |   35 -
 tests/qemucapabilitiesdata/caps_2.12.0.aarch64.xml |   35 -
 tests/qemucapabilitiesdata/caps_2.12.0.ppc64.xml   |   35 -
 tests/qemucapabilitiesdata/caps_2.12.0.s390x.xml   |   35 -
 tests/qemucapabilitiesdata/caps_2.12.0.x86_64.xml  |   35 -
 tests/qemucapabilitiesdata/caps_2.4.0.x86_64.xml   |   35 -
 tests/qemucapabilitiesdata/caps_2.5.0.x86_64.xml   |   35 -
 tests/qemucapabilitiesdata/caps_2.6.0.aarch64.xml  |   35 -
 tests/qemucapabilitiesdata/caps_2.6.0.ppc64.xml    |   35 -
 tests/qemucapabilitiesdata/caps_2.6.0.x86_64.xml   |   35 -
 tests/qemucapabilitiesdata/caps_2.7.0.s390x.xml    |   35 -
 tests/qemucapabilitiesdata/caps_2.7.0.x86_64.xml   |   35 -
 tests/qemucapabilitiesdata/caps_2.8.0.s390x.xml    |   35 -
 tests/qemucapabilitiesdata/caps_2.8.0.x86_64.xml   |   35 -
 tests/qemucapabilitiesdata/caps_2.9.0.ppc64.xml    |   35 -
 tests/qemucapabilitiesdata/caps_2.9.0.s390x.xml    |   35 -
 tests/qemucapabilitiesdata/caps_2.9.0.x86_64.xml   |   35 -
 tests/qemucapabilitiestest.c                       |    1 -
 tests/qemucapsprobe.c                              |    2 +-
 tests/qemuhelpdata/qemu-0.12.1                     |  198 --
 tests/qemuhelpdata/qemu-0.12.1-device              |   62 -
 tests/qemuhelpdata/qemu-1.0                        |  253 ---
 tests/qemuhelpdata/qemu-1.0-device                 |  148 --
 tests/qemuhelpdata/qemu-1.1.0                      |  269 ---
 tests/qemuhelpdata/qemu-1.1.0-device               |  170 --
 tests/qemuhelpdata/qemu-1.2.0                      |  272 ---
 tests/qemuhelpdata/qemu-kvm-0.12.3                 |  215 ---
 tests/qemuhelpdata/qemu-kvm-0.12.3-device          |   63 -
 tests/qemuhelpdata/qemu-kvm-0.13.0                 |  242 ---
 tests/qemuhelpdata/qemu-kvm-0.13.0-device          |   90 -
 tests/qemuhelpdata/qemu-kvm-1.2.0                  |  277 ---
 tests/qemuhelptest.c                               |  437 -----
 .../aarch64-aavmf-virtio-mmio.args                 |   14 +-
 tests/qemuxml2argvdata/aarch64-acpi-uefi.args      |    9 +-
 .../qemuxml2argvdata/aarch64-cpu-passthrough.args  |   10 +-
 tests/qemuxml2argvdata/aarch64-gic-host.args       |    9 +-
 tests/qemuxml2argvdata/aarch64-gic-none-tcg.args   |    9 +-
 tests/qemuxml2argvdata/aarch64-gic-v2.args         |    9 +-
 tests/qemuxml2argvdata/aarch64-gic-v3.args         |    9 +-
 tests/qemuxml2argvdata/aarch64-kvm-32-on-64.args   |   14 +-
 tests/qemuxml2argvdata/aarch64-noacpi-nouefi.args  |    9 +-
 tests/qemuxml2argvdata/aarch64-noacpi-uefi.args    |    9 +-
 tests/qemuxml2argvdata/aarch64-pci-serial.args     |   10 +-
 .../aarch64-usb-controller-nec-xhci.args           |    9 +-
 .../aarch64-usb-controller-qemu-xhci.args          |    9 +-
 tests/qemuxml2argvdata/aarch64-video-default.args  |    8 +-
 .../aarch64-video-virtio-gpu-pci.args              |   16 +-
 .../aarch64-virt-2.6-virtio-pci-default.args       |   15 +-
 .../qemuxml2argvdata/aarch64-virt-default-nic.args |   14 +-
 tests/qemuxml2argvdata/aarch64-virt-virtio.args    |   14 +-
 .../aarch64-virtio-pci-default.args                |   15 +-
 .../aarch64-virtio-pci-manual-addresses.args       |   20 +-
 tests/qemuxml2argvdata/acpi-table.args             |    9 +-
 tests/qemuxml2argvdata/arm-vexpressa9-basic.args   |   10 +-
 tests/qemuxml2argvdata/arm-vexpressa9-nodevs.args  |   10 +-
 tests/qemuxml2argvdata/arm-vexpressa9-virtio.args  |   14 +-
 tests/qemuxml2argvdata/arm-virt-virtio.args        |   14 +-
 tests/qemuxml2argvdata/autoindex.args              |    9 +-
 tests/qemuxml2argvdata/balloon-ccw-deflate.args    |   10 +-
 tests/qemuxml2argvdata/balloon-device-auto.args    |   10 +-
 .../balloon-device-deflate-off.args                |   10 +-
 tests/qemuxml2argvdata/balloon-device-deflate.args |   10 +-
 tests/qemuxml2argvdata/balloon-device-period.args  |   10 +-
 tests/qemuxml2argvdata/balloon-device.args         |   10 +-
 tests/qemuxml2argvdata/balloon-mmio-deflate.args   |   10 +-
 tests/qemuxml2argvdata/bios-nvram-secure.args      |   11 +-
 tests/qemuxml2argvdata/bios-nvram.args             |   11 +-
 tests/qemuxml2argvdata/bios.args                   |   11 +-
 tests/qemuxml2argvdata/blkdeviotune-group-num.args |    9 +-
 .../qemuxml2argvdata/blkdeviotune-max-length.args  |    9 +-
 tests/qemuxml2argvdata/blkdeviotune-max.args       |    9 +-
 tests/qemuxml2argvdata/blkdeviotune.args           |    9 +-
 tests/qemuxml2argvdata/blkiotune-device.args       |    9 +-
 tests/qemuxml2argvdata/blkiotune.args              |    9 +-
 tests/qemuxml2argvdata/boot-cdrom.args             |    9 +-
 tests/qemuxml2argvdata/boot-complex-bootindex.args |   20 +-
 tests/qemuxml2argvdata/boot-complex.args           |   19 +-
 tests/qemuxml2argvdata/boot-floppy-q35.args        |    9 +-
 tests/qemuxml2argvdata/boot-floppy.args            |    9 +-
 .../boot-menu-disable-drive-bootindex.args         |    9 +-
 .../qemuxml2argvdata/boot-menu-disable-drive.args  |    9 +-
 tests/qemuxml2argvdata/boot-menu-disable.args      |    9 +-
 .../boot-menu-enable-bootindex.args                |    9 +-
 .../boot-menu-enable-with-timeout.args             |    9 +-
 tests/qemuxml2argvdata/boot-menu-enable.args       |    9 +-
 tests/qemuxml2argvdata/boot-multi.args             |    9 +-
 tests/qemuxml2argvdata/boot-network.args           |    9 +-
 tests/qemuxml2argvdata/boot-order.args             |   15 +-
 tests/qemuxml2argvdata/boot-strict.args            |   20 +-
 tests/qemuxml2argvdata/bootindex-floppy-q35.args   |    9 +-
 tests/qemuxml2argvdata/channel-guestfwd.args       |   10 +-
 tests/qemuxml2argvdata/channel-spicevmc-old.args   |   29 -
 tests/qemuxml2argvdata/channel-spicevmc-old.xml    |   35 -
 tests/qemuxml2argvdata/channel-spicevmc.args       |    8 +-
 tests/qemuxml2argvdata/channel-virtio-auto.args    |   10 +-
 tests/qemuxml2argvdata/channel-virtio-autoadd.args |   10 +-
 .../channel-virtio-autoassign.args                 |   10 +-
 tests/qemuxml2argvdata/channel-virtio-default.args |   10 +-
 tests/qemuxml2argvdata/channel-virtio-state.args   |   10 +-
 tests/qemuxml2argvdata/channel-virtio-unix.args    |   10 +-
 tests/qemuxml2argvdata/channel-virtio.args         |   10 +-
 tests/qemuxml2argvdata/chardev-reconnect.args      |   10 +-
 tests/qemuxml2argvdata/clock-catchup.args          |    8 +-
 tests/qemuxml2argvdata/clock-france.args           |    8 +-
 tests/qemuxml2argvdata/clock-hpet-off.args         |    8 +-
 .../clock-localtime-basis-localtime.args           |    8 +-
 tests/qemuxml2argvdata/clock-localtime.args        |   10 +-
 tests/qemuxml2argvdata/clock-timer-hyperv-rtc.args |    9 +-
 tests/qemuxml2argvdata/clock-utc.args              |   10 +-
 tests/qemuxml2argvdata/clock-variable.args         |    8 +-
 tests/qemuxml2argvdata/console-compat-auto.args    |    9 +-
 tests/qemuxml2argvdata/console-compat-chardev.args |   10 +-
 tests/qemuxml2argvdata/console-compat.args         |    9 +-
 tests/qemuxml2argvdata/console-sclp.args           |   10 +-
 tests/qemuxml2argvdata/console-virtio-ccw.args     |   10 +-
 tests/qemuxml2argvdata/console-virtio-many.args    |   10 +-
 tests/qemuxml2argvdata/console-virtio-s390.args    |   10 +-
 tests/qemuxml2argvdata/console-virtio.args         |   10 +-
 tests/qemuxml2argvdata/controller-order.args       |   13 +-
 tests/qemuxml2argvdata/cpu-Haswell-noTSX.args      |    9 +-
 tests/qemuxml2argvdata/cpu-Haswell.args            |    9 +-
 tests/qemuxml2argvdata/cpu-Haswell2.args           |    9 +-
 tests/qemuxml2argvdata/cpu-Haswell3.args           |    9 +-
 tests/qemuxml2argvdata/cpu-cache-disable.args      |    9 +-
 tests/qemuxml2argvdata/cpu-cache-disable2.args     |    9 +-
 tests/qemuxml2argvdata/cpu-cache-disable3.args     |    9 +-
 tests/qemuxml2argvdata/cpu-cache-emulate-l3.args   |    9 +-
 tests/qemuxml2argvdata/cpu-cache-passthrough.args  |    9 +-
 tests/qemuxml2argvdata/cpu-cache-passthrough2.args |    9 +-
 tests/qemuxml2argvdata/cpu-check-default-none.args |    9 +-
 .../qemuxml2argvdata/cpu-check-default-none2.args  |    9 +-
 .../cpu-check-default-partial.args                 |    9 +-
 .../cpu-check-default-partial2.args                |    9 +-
 tests/qemuxml2argvdata/cpu-check-none.args         |    9 +-
 tests/qemuxml2argvdata/cpu-eoi-disabled.args       |    9 +-
 tests/qemuxml2argvdata/cpu-eoi-enabled.args        |    9 +-
 tests/qemuxml2argvdata/cpu-exact1.args             |    9 +-
 tests/qemuxml2argvdata/cpu-exact2-nofallback.args  |    9 +-
 tests/qemuxml2argvdata/cpu-exact2.args             |    9 +-
 tests/qemuxml2argvdata/cpu-fallback.args           |    9 +-
 tests/qemuxml2argvdata/cpu-host-kvmclock.args      |   10 +-
 tests/qemuxml2argvdata/cpu-host-model-cmt.args     |    9 +-
 .../qemuxml2argvdata/cpu-host-model-fallback.args  |    9 +-
 tests/qemuxml2argvdata/cpu-host-model-vendor.args  |    9 +-
 tests/qemuxml2argvdata/cpu-host-model.args         |    9 +-
 .../cpu-host-passthrough-features.args             |    9 +-
 tests/qemuxml2argvdata/cpu-host-passthrough.args   |    9 +-
 tests/qemuxml2argvdata/cpu-hotplug-startup.args    |    9 +-
 tests/qemuxml2argvdata/cpu-kvmclock.args           |   10 +-
 tests/qemuxml2argvdata/cpu-minimum1.args           |    9 +-
 tests/qemuxml2argvdata/cpu-minimum2.args           |    9 +-
 tests/qemuxml2argvdata/cpu-numa-disjoint.args      |    9 +-
 tests/qemuxml2argvdata/cpu-numa-memshared.args     |    9 +-
 .../cpu-numa-no-memory-element.args                |    9 +-
 tests/qemuxml2argvdata/cpu-numa1.args              |    9 +-
 tests/qemuxml2argvdata/cpu-numa2.args              |    9 +-
 tests/qemuxml2argvdata/cpu-s390-features.args      |    9 +-
 tests/qemuxml2argvdata/cpu-s390-zEC12.args         |    9 +-
 tests/qemuxml2argvdata/cpu-strict1.args            |    9 +-
 tests/qemuxml2argvdata/cpu-topology1.args          |    9 +-
 tests/qemuxml2argvdata/cpu-topology2.args          |    9 +-
 tests/qemuxml2argvdata/cpu-topology3.args          |    9 +-
 tests/qemuxml2argvdata/cpu-tsc-frequency.args      |    9 +-
 tests/qemuxml2argvdata/cputune-numatune.args       |    9 +-
 tests/qemuxml2argvdata/cputune-zero-shares.args    |    9 +-
 tests/qemuxml2argvdata/cputune.args                |    9 +-
 tests/qemuxml2argvdata/debug-threads.args          |    9 +-
 tests/qemuxml2argvdata/default-kvm-host-arch.args  |    9 +-
 tests/qemuxml2argvdata/default-qemu-host-arch.args |    9 +-
 tests/qemuxml2argvdata/disk-aio.args               |    9 +-
 tests/qemuxml2argvdata/disk-blockio.args           |   10 +-
 tests/qemuxml2argvdata/disk-cdrom-empty.args       |    9 +-
 tests/qemuxml2argvdata/disk-cdrom-network-ftp.args |    9 +-
 .../qemuxml2argvdata/disk-cdrom-network-ftps.args  |    9 +-
 .../qemuxml2argvdata/disk-cdrom-network-http.args  |    9 +-
 .../qemuxml2argvdata/disk-cdrom-network-https.args |    9 +-
 .../qemuxml2argvdata/disk-cdrom-network-tftp.args  |    9 +-
 .../disk-cdrom-tray-no-device-cap.args             |    9 +-
 tests/qemuxml2argvdata/disk-cdrom-tray.args        |   11 +-
 tests/qemuxml2argvdata/disk-cdrom.args             |    9 +-
 tests/qemuxml2argvdata/disk-copy_on_read.args      |   17 +-
 tests/qemuxml2argvdata/disk-drive-boot-cdrom.args  |    9 +-
 tests/qemuxml2argvdata/disk-drive-boot-disk.args   |    9 +-
 .../disk-drive-cache-directsync.args               |    9 +-
 .../qemuxml2argvdata/disk-drive-cache-unsafe.args  |    9 +-
 .../qemuxml2argvdata/disk-drive-cache-v2-none.args |    9 +-
 tests/qemuxml2argvdata/disk-drive-cache-v2-wb.args |    9 +-
 tests/qemuxml2argvdata/disk-drive-cache-v2-wt.args |    9 +-
 .../qemuxml2argvdata/disk-drive-copy-on-read.args  |    9 +-
 .../qemuxml2argvdata/disk-drive-detect-zeroes.args |   11 +-
 tests/qemuxml2argvdata/disk-drive-discard.args     |   11 +-
 .../disk-drive-error-policy-enospace.args          |    7 +-
 .../disk-drive-error-policy-stop.args              |    7 +-
 .../disk-drive-error-policy-wreport-rignore.args   |    7 +-
 tests/qemuxml2argvdata/disk-drive-fmt-qcow.args    |    9 +-
 .../disk-drive-network-gluster.args                |    9 +-
 .../disk-drive-network-iscsi-auth.args             |    9 +-
 .../disk-drive-network-iscsi-lun.args              |   10 +-
 .../qemuxml2argvdata/disk-drive-network-iscsi.args |    9 +-
 .../disk-drive-network-nbd-export.args             |    9 +-
 .../disk-drive-network-nbd-ipv6-export.args        |    9 +-
 .../disk-drive-network-nbd-ipv6.args               |    9 +-
 .../disk-drive-network-nbd-unix.args               |    9 +-
 tests/qemuxml2argvdata/disk-drive-network-nbd.args |    9 +-
 .../disk-drive-network-rbd-auth-AES.args           |    9 +-
 .../disk-drive-network-rbd-auth.args               |    9 +-
 .../disk-drive-network-rbd-ipv6.args               |    9 +-
 tests/qemuxml2argvdata/disk-drive-network-rbd.args |    9 +-
 .../disk-drive-network-sheepdog.args               |    9 +-
 .../disk-drive-network-source-auth.args            |    9 +-
 .../disk-drive-network-tlsx509-vxhs.args           |   15 +-
 .../qemuxml2argvdata/disk-drive-network-vxhs.args  |   11 +-
 tests/qemuxml2argvdata/disk-drive-no-boot.args     |    9 +-
 .../qemuxml2argvdata/disk-drive-readonly-disk.args |   10 +-
 .../disk-drive-readonly-no-device.args             |   10 +-
 .../disk-drive-shared-locking.args                 |    9 +-
 tests/qemuxml2argvdata/disk-drive-shared.args      |    9 +-
 .../disk-floppy-tray-no-device-cap.args            |    9 +-
 tests/qemuxml2argvdata/disk-floppy-tray.args       |    9 +-
 tests/qemuxml2argvdata/disk-floppy.args            |    9 +-
 tests/qemuxml2argvdata/disk-geometry.args          |    9 +-
 .../disk-hostdev-scsi-virtio-iscsi-auth-AES.args   |    9 +-
 tests/qemuxml2argvdata/disk-ide-drive-split.args   |   10 +-
 tests/qemuxml2argvdata/disk-ide-wwn.args           |    9 +-
 tests/qemuxml2argvdata/disk-ioeventfd.args         |   15 +-
 tests/qemuxml2argvdata/disk-iscsi.args             |    9 +-
 .../qemuxml2argvdata/disk-many-format-probing.args |    9 +-
 tests/qemuxml2argvdata/disk-many.args              |    9 +-
 tests/qemuxml2argvdata/disk-order.args             |    9 +-
 tests/qemuxml2argvdata/disk-sata-device.args       |   10 +-
 tests/qemuxml2argvdata/disk-scsi-device-auto.args  |   10 +-
 tests/qemuxml2argvdata/disk-scsi-device.args       |   10 +-
 tests/qemuxml2argvdata/disk-scsi-disk-split.args   |   10 +-
 tests/qemuxml2argvdata/disk-scsi-disk-vpd.args     |   10 +-
 tests/qemuxml2argvdata/disk-scsi-disk-wwn.args     |   12 +-
 .../disk-scsi-lun-passthrough.args                 |    9 +-
 tests/qemuxml2argvdata/disk-scsi-megasas.args      |   10 +-
 tests/qemuxml2argvdata/disk-scsi-mptsas1068.args   |   10 +-
 tests/qemuxml2argvdata/disk-scsi-virtio-scsi.args  |   10 +-
 tests/qemuxml2argvdata/disk-scsi-vscsi.args        |   10 +-
 tests/qemuxml2argvdata/disk-serial.args            |    9 +-
 tests/qemuxml2argvdata/disk-snapshot.args          |    9 +-
 tests/qemuxml2argvdata/disk-source-pool-mode.args  |   10 +-
 tests/qemuxml2argvdata/disk-source-pool.args       |   10 +-
 .../disk-usb-device-removable.args                 |   10 +-
 tests/qemuxml2argvdata/disk-usb-device.args        |   10 +-
 tests/qemuxml2argvdata/disk-virtio-ccw-many.args   |    9 +-
 tests/qemuxml2argvdata/disk-virtio-ccw.args        |    9 +-
 .../qemuxml2argvdata/disk-virtio-drive-queues.args |    9 +-
 tests/qemuxml2argvdata/disk-virtio-s390.args       |    9 +-
 tests/qemuxml2argvdata/disk-virtio-scsi-ccw.args   |    9 +-
 .../disk-virtio-scsi-cmd_per_lun.args              |   10 +-
 .../disk-virtio-scsi-ioeventfd.args                |   10 +-
 .../disk-virtio-scsi-max_sectors.args              |   10 +-
 .../disk-virtio-scsi-num_queues.args               |   10 +-
 tests/qemuxml2argvdata/disk-virtio.args            |    9 +-
 tests/qemuxml2argvdata/encrypted-disk-usage.args   |    9 +-
 tests/qemuxml2argvdata/encrypted-disk.args         |    9 +-
 tests/qemuxml2argvdata/eoi-disabled.args           |    9 +-
 tests/qemuxml2argvdata/eoi-enabled.args            |    9 +-
 tests/qemuxml2argvdata/event_idx.args              |   17 +-
 .../fd-memory-no-numa-topology.args                |    9 +-
 .../qemuxml2argvdata/fd-memory-numa-topology.args  |    9 +-
 .../qemuxml2argvdata/fd-memory-numa-topology2.args |    9 +-
 .../qemuxml2argvdata/fd-memory-numa-topology3.args |    9 +-
 tests/qemuxml2argvdata/fips-enabled.args           |    9 +-
 tests/qemuxml2argvdata/floppy-drive-fat.args       |    9 +-
 tests/qemuxml2argvdata/fs9p-ccw.args               |   10 +-
 tests/qemuxml2argvdata/fs9p.args                   |   10 +-
 .../qemuxml2argvdata/graphics-sdl-fullscreen.args  |    7 +-
 tests/qemuxml2argvdata/graphics-sdl.args           |    7 +-
 .../graphics-spice-agent-file-xfer.args            |    7 +-
 .../graphics-spice-agentmouse.args                 |    8 +-
 .../graphics-spice-auto-socket-cfg.args            |    7 +-
 .../graphics-spice-auto-socket.args                |    7 +-
 .../graphics-spice-compression.args                |    7 +-
 tests/qemuxml2argvdata/graphics-spice-no-args.args |    7 +-
 tests/qemuxml2argvdata/graphics-spice-qxl-vga.args |    7 +-
 tests/qemuxml2argvdata/graphics-spice-sasl.args    |    7 +-
 tests/qemuxml2argvdata/graphics-spice-socket.args  |    7 +-
 tests/qemuxml2argvdata/graphics-spice-timeout.args |   14 +-
 .../qemuxml2argvdata/graphics-spice-usb-redir.args |    8 +-
 tests/qemuxml2argvdata/graphics-spice.args         |    7 +-
 .../graphics-vnc-auto-socket-cfg.args              |    7 +-
 .../qemuxml2argvdata/graphics-vnc-auto-socket.args |    7 +-
 .../graphics-vnc-no-listen-attr.args               |    7 +-
 tests/qemuxml2argvdata/graphics-vnc-none.args      |    7 +-
 tests/qemuxml2argvdata/graphics-vnc-policy.args    |    7 +-
 .../graphics-vnc-remove-generated-socket.args      |    7 +-
 tests/qemuxml2argvdata/graphics-vnc-sasl.args      |    7 +-
 .../graphics-vnc-socket-new-cmdline.args           |    7 +-
 tests/qemuxml2argvdata/graphics-vnc-socket.args    |    7 +-
 tests/qemuxml2argvdata/graphics-vnc-tls.args       |    7 +-
 tests/qemuxml2argvdata/graphics-vnc-websocket.args |    7 +-
 tests/qemuxml2argvdata/graphics-vnc.args           |    7 +-
 .../qemuxml2argvdata/hostdev-mdev-precreated.args  |   10 +-
 .../hostdev-pci-address-device.args                |   10 +-
 tests/qemuxml2argvdata/hostdev-pci-address.args    |    9 +-
 .../hostdev-scsi-lsi-iscsi-auth.args               |    9 +-
 tests/qemuxml2argvdata/hostdev-scsi-lsi-iscsi.args |    9 +-
 tests/qemuxml2argvdata/hostdev-scsi-lsi.args       |    9 +-
 tests/qemuxml2argvdata/hostdev-scsi-readonly.args  |    9 +-
 .../hostdev-scsi-vhost-scsi-ccw.args               |    9 +-
 .../hostdev-scsi-vhost-scsi-pci.args               |    9 +-
 .../hostdev-scsi-vhost-scsi-pcie.args              |    9 +-
 .../hostdev-scsi-virtio-iscsi-auth.args            |    9 +-
 .../hostdev-scsi-virtio-iscsi.args                 |    9 +-
 .../qemuxml2argvdata/hostdev-scsi-virtio-scsi.args |    9 +-
 .../hostdev-usb-address-device-boot.args           |   10 +-
 .../hostdev-usb-address-device.args                |   10 +-
 tests/qemuxml2argvdata/hostdev-usb-address.args    |    9 +-
 .../qemuxml2argvdata/hostdev-vfio-multidomain.args |   10 +-
 tests/qemuxml2argvdata/hostdev-vfio.args           |   10 +-
 tests/qemuxml2argvdata/hotplug-base.args           |    9 +-
 tests/qemuxml2argvdata/hugepages-memaccess.args    |    9 +-
 tests/qemuxml2argvdata/hugepages-memaccess2.args   |    9 +-
 tests/qemuxml2argvdata/hugepages-numa.args         |    6 +-
 tests/qemuxml2argvdata/hugepages-pages.args        |    9 +-
 tests/qemuxml2argvdata/hugepages-pages2.args       |    9 +-
 tests/qemuxml2argvdata/hugepages-pages3.args       |    9 +-
 tests/qemuxml2argvdata/hugepages-pages5.args       |    9 +-
 tests/qemuxml2argvdata/hugepages-pages6.args       |    9 +-
 tests/qemuxml2argvdata/hugepages-pages7.args       |    9 +-
 tests/qemuxml2argvdata/hugepages-shared.args       |    9 +-
 tests/qemuxml2argvdata/hugepages.args              |    9 +-
 tests/qemuxml2argvdata/hyperv-off.args             |    9 +-
 tests/qemuxml2argvdata/hyperv-panic.args           |    9 +-
 tests/qemuxml2argvdata/hyperv.args                 |    9 +-
 tests/qemuxml2argvdata/input-usbmouse-addr.args    |   10 +-
 tests/qemuxml2argvdata/input-usbmouse.args         |    9 +-
 tests/qemuxml2argvdata/input-usbtablet.args        |    9 +-
 tests/qemuxml2argvdata/input-virtio-ccw.args       |    9 +-
 .../qemuxml2argvdata/intel-iommu-caching-mode.args |   14 +-
 .../qemuxml2argvdata/intel-iommu-device-iotlb.args |    9 +-
 tests/qemuxml2argvdata/intel-iommu-eim.args        |    9 +-
 tests/qemuxml2argvdata/intel-iommu-machine.args    |    9 +-
 tests/qemuxml2argvdata/intel-iommu.args            |    9 +-
 .../iothreads-disk-virtio-ccw.args                 |    9 +-
 tests/qemuxml2argvdata/iothreads-disk.args         |    9 +-
 tests/qemuxml2argvdata/iothreads-ids-partial.args  |    9 +-
 tests/qemuxml2argvdata/iothreads-ids.args          |    9 +-
 .../iothreads-virtio-scsi-ccw.args                 |    9 +-
 .../iothreads-virtio-scsi-pci.args                 |    9 +-
 tests/qemuxml2argvdata/iothreads.args              |    9 +-
 tests/qemuxml2argvdata/kvm-features-off.args       |    9 +-
 tests/qemuxml2argvdata/kvm-features.args           |    9 +-
 tests/qemuxml2argvdata/kvm-pit-delay.args          |    9 +-
 tests/qemuxml2argvdata/kvm-pit-discard.args        |    9 +-
 tests/qemuxml2argvdata/kvm.args                    |    9 +-
 tests/qemuxml2argvdata/kvmclock+eoi-disabled.args  |    9 +-
 tests/qemuxml2argvdata/kvmclock.args               |    9 +-
 tests/qemuxml2argvdata/luks-disks-source.args      |    9 +-
 tests/qemuxml2argvdata/luks-disks.args             |    9 +-
 .../qemuxml2argvdata/mach-virt-console-virtio.args |   10 +-
 .../qemuxml2argvdata/mach-virt-serial-native.args  |   10 +-
 tests/qemuxml2argvdata/mach-virt-serial-pci.args   |   10 +-
 tests/qemuxml2argvdata/mach-virt-serial-usb.args   |   10 +-
 .../machine-aeskeywrap-off-cap.args                |   10 +-
 .../machine-aeskeywrap-off-caps.args               |   10 +-
 .../machine-aeskeywrap-on-cap.args                 |    9 +-
 .../machine-aeskeywrap-on-caps.args                |    9 +-
 tests/qemuxml2argvdata/machine-aliases1.args       |    9 +-
 tests/qemuxml2argvdata/machine-aliases2.args       |    9 +-
 tests/qemuxml2argvdata/machine-core-cfg-off.args   |    9 +-
 tests/qemuxml2argvdata/machine-core-off.args       |    9 +-
 tests/qemuxml2argvdata/machine-core-on.args        |    9 +-
 .../machine-deakeywrap-off-cap.args                |   10 +-
 .../machine-deakeywrap-off-caps.args               |   10 +-
 .../machine-deakeywrap-on-cap.args                 |    9 +-
 .../machine-deakeywrap-on-caps.args                |    9 +-
 .../machine-keywrap-none-caps.args                 |    9 +-
 tests/qemuxml2argvdata/machine-keywrap-none.args   |    9 +-
 .../machine-loadparm-multiple-disks-nets-s390.args |   21 +-
 .../machine-loadparm-net-s390.args                 |   15 +-
 tests/qemuxml2argvdata/machine-loadparm-s390.args  |    9 +-
 tests/qemuxml2argvdata/machine-smm-opt.args        |    9 +-
 tests/qemuxml2argvdata/machine-usb-opt.args        |    9 +-
 tests/qemuxml2argvdata/machine-vmport-opt.args     |    9 +-
 tests/qemuxml2argvdata/master-key.args             |    9 +-
 .../qemuxml2argvdata/memory-hotplug-dimm-addr.args |    9 +-
 tests/qemuxml2argvdata/memory-hotplug-dimm.args    |    9 +-
 .../memory-hotplug-nvdimm-access.args              |    9 +-
 .../memory-hotplug-nvdimm-label.args               |    9 +-
 tests/qemuxml2argvdata/memory-hotplug-nvdimm.args  |    9 +-
 .../memory-hotplug-ppc64-nonuma.args               |    9 +-
 tests/qemuxml2argvdata/memory-hotplug.args         |    9 +-
 tests/qemuxml2argvdata/memtune-unlimited.args      |    9 +-
 tests/qemuxml2argvdata/memtune.args                |    9 +-
 tests/qemuxml2argvdata/migrate-numa-unaligned.args |    9 +-
 tests/qemuxml2argvdata/migrate.args                |    9 +-
 tests/qemuxml2argvdata/minimal-msg-timestamp.args  |    9 +-
 tests/qemuxml2argvdata/minimal.args                |    9 +-
 tests/qemuxml2argvdata/misc-acpi.args              |    9 +-
 tests/qemuxml2argvdata/misc-disable-s3.args        |    9 +-
 tests/qemuxml2argvdata/misc-disable-suspends.args  |    9 +-
 tests/qemuxml2argvdata/misc-enable-s4.args         |    9 +-
 tests/qemuxml2argvdata/misc-no-reboot.args         |    8 +-
 tests/qemuxml2argvdata/misc-uuid.args              |    9 +-
 tests/qemuxml2argvdata/mlock-off.args              |    9 +-
 tests/qemuxml2argvdata/mlock-on.args               |    9 +-
 tests/qemuxml2argvdata/mlock-unsupported.args      |    9 +-
 tests/qemuxml2argvdata/monitor-json.args           |    8 +-
 .../qemuxml2argvdata/multifunction-pci-device.args |   10 +-
 tests/qemuxml2argvdata/name-escape.args            |    7 +-
 tests/qemuxml2argvdata/net-client.args             |   14 +-
 tests/qemuxml2argvdata/net-eth-hostip.args         |   14 +-
 tests/qemuxml2argvdata/net-eth-ifname.args         |   14 +-
 tests/qemuxml2argvdata/net-eth-names.args          |   18 +-
 tests/qemuxml2argvdata/net-eth.args                |   14 +-
 .../qemuxml2argvdata/net-hostdev-multidomain.args  |   10 +-
 .../net-hostdev-vfio-multidomain.args              |   10 +-
 tests/qemuxml2argvdata/net-hostdev-vfio.args       |   10 +-
 tests/qemuxml2argvdata/net-hostdev.args            |   10 +-
 tests/qemuxml2argvdata/net-mcast.args              |   14 +-
 tests/qemuxml2argvdata/net-server.args             |   14 +-
 tests/qemuxml2argvdata/net-udp.args                |   15 +-
 tests/qemuxml2argvdata/net-user-addr.args          |    9 +-
 tests/qemuxml2argvdata/net-user.args               |   14 +-
 tests/qemuxml2argvdata/net-vhostuser-multiq.args   |    9 +-
 tests/qemuxml2argvdata/net-vhostuser.args          |    9 +-
 tests/qemuxml2argvdata/net-virtio-ccw.args         |   19 +-
 tests/qemuxml2argvdata/net-virtio-device.args      |   16 +-
 .../net-virtio-disable-offloads.args               |   14 +-
 tests/qemuxml2argvdata/net-virtio-netdev.args      |   10 +-
 .../qemuxml2argvdata/net-virtio-rxtxqueuesize.args |   15 +-
 tests/qemuxml2argvdata/net-virtio-s390.args        |   13 +-
 tests/qemuxml2argvdata/net-virtio.args             |   14 +-
 tests/qemuxml2argvdata/no-kvm-pit-device.args      |    9 +-
 tests/qemuxml2argvdata/no-shutdown.args            |    7 +-
 tests/qemuxml2argvdata/nographics-display.args     |    7 +-
 tests/qemuxml2argvdata/nographics-vga.args         |    9 +-
 tests/qemuxml2argvdata/nographics.args             |    9 +-
 tests/qemuxml2argvdata/nosharepages.args           |    9 +-
 .../numad-auto-memory-vcpu-cpuset.args             |    9 +-
 ...d-auto-memory-vcpu-no-cpuset-and-placement.args |    9 +-
 .../numad-auto-vcpu-static-numatune.args           |    9 +-
 .../numad-static-memory-auto-vcpu.args             |    9 +-
 tests/qemuxml2argvdata/numad.args                  |    9 +-
 .../numatune-auto-nodeset-invalid.args             |    9 +-
 tests/qemuxml2argvdata/numatune-auto-prefer.args   |    9 +-
 tests/qemuxml2argvdata/numatune-distances.args     |    9 +-
 .../numatune-memnode-no-memory.args                |    9 +-
 tests/qemuxml2argvdata/numatune-memnode.args       |    9 +-
 tests/qemuxml2argvdata/numatune-memory.args        |    9 +-
 tests/qemuxml2argvdata/panic-double.args           |   10 +-
 tests/qemuxml2argvdata/panic-no-address.args       |   10 +-
 tests/qemuxml2argvdata/panic.args                  |   10 +-
 .../qemuxml2argvdata/parallel-parport-chardev.args |   10 +-
 tests/qemuxml2argvdata/parallel-tcp-chardev.args   |   10 +-
 tests/qemuxml2argvdata/pci-autoadd-addr.args       |    9 +-
 tests/qemuxml2argvdata/pci-autoadd-idx.args        |    9 +-
 tests/qemuxml2argvdata/pci-autofill-addr.args      |    9 +-
 tests/qemuxml2argvdata/pci-bridge-many-disks.args  |    9 +-
 tests/qemuxml2argvdata/pci-bridge.args             |  158 +-
 tests/qemuxml2argvdata/pci-expander-bus.args       |  160 +-
 tests/qemuxml2argvdata/pci-many.args               |    9 +-
 tests/qemuxml2argvdata/pci-rom.args                |   22 +-
 tests/qemuxml2argvdata/pci-serial-dev-chardev.args |   10 +-
 tests/qemuxml2argvdata/pcie-expander-bus.args      |  164 +-
 .../pcie-root-port-model-generic.args              |    9 +-
 .../pcie-root-port-model-ioh3420.args              |    9 +-
 tests/qemuxml2argvdata/pcie-root-port.args         |    9 +-
 tests/qemuxml2argvdata/pcie-root.args              |    9 +-
 .../pcie-switch-downstream-port.args               |    9 +-
 .../pcie-switch-upstream-port.args                 |    9 +-
 tests/qemuxml2argvdata/pcihole64-q35.args          |    9 +-
 tests/qemuxml2argvdata/pcihole64.args              |    9 +-
 tests/qemuxml2argvdata/pmu-feature-off.args        |    9 +-
 tests/qemuxml2argvdata/pmu-feature.args            |    9 +-
 tests/qemuxml2argvdata/ppc-dtb.args                |    9 +-
 .../ppc64-usb-controller-legacy.args               |    9 +-
 .../ppc64-usb-controller-qemu-xhci.args            |    9 +-
 tests/qemuxml2argvdata/ppc64-usb-controller.args   |    9 +-
 tests/qemuxml2argvdata/ppce500-serial.args         |    9 +-
 tests/qemuxml2argvdata/pseries-basic.args          |   10 +-
 tests/qemuxml2argvdata/pseries-console-virtio.args |   10 +-
 .../pseries-cpu-compat-power9.args                 |   10 +-
 tests/qemuxml2argvdata/pseries-cpu-compat.args     |   10 +-
 tests/qemuxml2argvdata/pseries-cpu-exact.args      |   10 +-
 tests/qemuxml2argvdata/pseries-cpu-le.args         |   10 +-
 tests/qemuxml2argvdata/pseries-features.args       |    9 +-
 tests/qemuxml2argvdata/pseries-hostdevs-1.args     |   10 +-
 tests/qemuxml2argvdata/pseries-hostdevs-2.args     |   10 +-
 tests/qemuxml2argvdata/pseries-hostdevs-3.args     |   10 +-
 .../pseries-machine-max-cpu-compat.args            |   10 +-
 tests/qemuxml2argvdata/pseries-many-buses-1.args   |   10 +-
 tests/qemuxml2argvdata/pseries-many-buses-2.args   |   10 +-
 tests/qemuxml2argvdata/pseries-many-devices.args   |   10 +-
 tests/qemuxml2argvdata/pseries-nvram.args          |    9 +-
 tests/qemuxml2argvdata/pseries-panic-missing.args  |   10 +-
 .../qemuxml2argvdata/pseries-panic-no-address.args |   10 +-
 .../pseries-phb-default-missing.args               |   10 +-
 tests/qemuxml2argvdata/pseries-phb-numa-node.args  |    9 +-
 tests/qemuxml2argvdata/pseries-phb-simple.args     |   10 +-
 tests/qemuxml2argvdata/pseries-serial-native.args  |   10 +-
 tests/qemuxml2argvdata/pseries-serial-pci.args     |   10 +-
 tests/qemuxml2argvdata/pseries-serial-usb.args     |   10 +-
 tests/qemuxml2argvdata/pseries-usb-default.args    |   10 +-
 tests/qemuxml2argvdata/pseries-usb-kbd.args        |   10 +-
 tests/qemuxml2argvdata/pseries-usb-multi.args      |   10 +-
 .../pseries-vio-user-assigned.args                 |   10 +-
 tests/qemuxml2argvdata/pseries-vio.args            |   10 +-
 tests/qemuxml2argvdata/pv-spinlock-disabled.args   |    9 +-
 tests/qemuxml2argvdata/pv-spinlock-enabled.args    |    9 +-
 tests/qemuxml2argvdata/q35-acpi-nouefi.args        |    9 +-
 tests/qemuxml2argvdata/q35-acpi-uefi.args          |    9 +-
 .../qemuxml2argvdata/q35-default-devices-only.args |    9 +-
 tests/qemuxml2argvdata/q35-multifunction.args      |    9 +-
 tests/qemuxml2argvdata/q35-noacpi-nouefi.args      |    9 +-
 tests/qemuxml2argvdata/q35-pci-force-address.args  |   14 +-
 tests/qemuxml2argvdata/q35-pcie-autoadd.args       |    9 +-
 tests/qemuxml2argvdata/q35-pcie.args               |    9 +-
 .../qemuxml2argvdata/q35-pm-disable-fallback.args  |    9 +-
 tests/qemuxml2argvdata/q35-pm-disable.args         |    9 +-
 tests/qemuxml2argvdata/q35-usb2-multi.args         |    9 +-
 tests/qemuxml2argvdata/q35-usb2-reorder.args       |    9 +-
 tests/qemuxml2argvdata/q35-usb2.args               |    9 +-
 tests/qemuxml2argvdata/q35-virt-manager-basic.args |    6 +-
 tests/qemuxml2argvdata/q35-virtio-pci.args         |    9 +-
 tests/qemuxml2argvdata/q35.args                    |    9 +-
 tests/qemuxml2argvdata/qemu-ns-alt.args            |    9 +-
 .../qemuxml2argvdata/qemu-ns-commandline-ns0.args  |    9 +-
 .../qemuxml2argvdata/qemu-ns-commandline-ns1.args  |    9 +-
 tests/qemuxml2argvdata/qemu-ns-commandline.args    |    9 +-
 .../qemu-ns-domain-commandline-ns0.args            |    9 +-
 .../qemu-ns-domain-commandline.args                |    9 +-
 tests/qemuxml2argvdata/qemu-ns-domain-ns0.args     |    9 +-
 tests/qemuxml2argvdata/qemu-ns-no-env.args         |    9 +-
 tests/qemuxml2argvdata/qemu-ns.args                |    9 +-
 .../qemuxml2argvdata/reboot-timeout-disabled.args  |    9 +-
 tests/qemuxml2argvdata/reboot-timeout-enabled.args |    9 +-
 tests/qemuxml2argvdata/restore-v2-fd.args          |    9 +-
 tests/qemuxml2argvdata/restore-v2.args             |    9 +-
 .../s390-allow-bogus-usb-controller.args           |   10 +-
 .../s390-allow-bogus-usb-none.args                 |   10 +-
 tests/qemuxml2argvdata/s390-panic-missing.args     |   10 +-
 tests/qemuxml2argvdata/s390-panic-no-address.args  |   10 +-
 tests/qemuxml2argvdata/s390-serial-2.args          |   10 +-
 tests/qemuxml2argvdata/s390-serial-console.args    |   10 +-
 tests/qemuxml2argvdata/s390-serial.args            |   10 +-
 tests/qemuxml2argvdata/seclabel-dac-none.args      |    9 +-
 .../seclabel-dynamic-baselabel.args                |    9 +-
 .../seclabel-dynamic-labelskip.args                |    9 +-
 .../seclabel-dynamic-override.args                 |    9 +-
 .../qemuxml2argvdata/seclabel-dynamic-relabel.args |    9 +-
 tests/qemuxml2argvdata/seclabel-dynamic.args       |    9 +-
 tests/qemuxml2argvdata/seclabel-none.args          |    9 +-
 .../seclabel-static-labelskip.args                 |    9 +-
 .../qemuxml2argvdata/seclabel-static-relabel.args  |    9 +-
 tests/qemuxml2argvdata/seclabel-static.args        |    9 +-
 .../serial-dev-chardev-iobase.args                 |   10 +-
 tests/qemuxml2argvdata/serial-dev-chardev.args     |   10 +-
 tests/qemuxml2argvdata/serial-file-chardev.args    |   10 +-
 tests/qemuxml2argvdata/serial-file-log.args        |    9 +-
 tests/qemuxml2argvdata/serial-many-chardev.args    |   10 +-
 tests/qemuxml2argvdata/serial-pty-chardev.args     |   10 +-
 .../qemuxml2argvdata/serial-spiceport-nospice.args |    9 +-
 tests/qemuxml2argvdata/serial-spiceport.args       |    8 +-
 tests/qemuxml2argvdata/serial-tcp-chardev.args     |   10 +-
 .../serial-tcp-telnet-chardev.args                 |   10 +-
 .../serial-tcp-tlsx509-chardev-notls.args          |   10 +-
 .../serial-tcp-tlsx509-chardev-verify.args         |   10 +-
 .../serial-tcp-tlsx509-chardev.args                |   10 +-
 .../serial-tcp-tlsx509-secret-chardev.args         |   10 +-
 tests/qemuxml2argvdata/serial-udp-chardev.args     |   10 +-
 tests/qemuxml2argvdata/serial-unix-chardev.args    |   10 +-
 tests/qemuxml2argvdata/serial-vc-chardev.args      |   10 +-
 tests/qemuxml2argvdata/shmem-plain-doorbell.args   |    9 +-
 tests/qemuxml2argvdata/shmem.args                  |    9 +-
 tests/qemuxml2argvdata/smartcard-controller.args   |   10 +-
 .../smartcard-host-certificates.args               |   10 +-
 tests/qemuxml2argvdata/smartcard-host.args         |   10 +-
 .../smartcard-passthrough-spicevmc.args            |   10 +-
 .../smartcard-passthrough-tcp.args                 |   10 +-
 tests/qemuxml2argvdata/smbios.args                 |    9 +-
 tests/qemuxml2argvdata/smp.args                    |    9 +-
 tests/qemuxml2argvdata/sound-device.args           |   10 +-
 tests/qemuxml2argvdata/sound.args                  |    9 +-
 tests/qemuxml2argvdata/tpm-passthrough.args        |   11 +-
 .../usb-controller-default-q35.args                |    9 +-
 .../usb-controller-explicit-q35.args               |    9 +-
 .../qemuxml2argvdata/usb-controller-qemu-xhci.args |    9 +-
 tests/qemuxml2argvdata/usb-controller-xhci.args    |   10 +-
 tests/qemuxml2argvdata/usb-controller.args         |   10 +-
 tests/qemuxml2argvdata/usb-hub-autoadd-deluxe.args |   10 +-
 tests/qemuxml2argvdata/usb-hub-autoadd.args        |   10 +-
 tests/qemuxml2argvdata/usb-hub.args                |   10 +-
 tests/qemuxml2argvdata/usb-ich9-autoassign.args    |   10 +-
 tests/qemuxml2argvdata/usb-ich9-companion.args     |   10 +-
 tests/qemuxml2argvdata/usb-ich9-ehci-addr.args     |   10 +-
 tests/qemuxml2argvdata/usb-long-port-path.args     |   10 +-
 tests/qemuxml2argvdata/usb-none.args               |   10 +-
 tests/qemuxml2argvdata/usb-piix3-controller.args   |   10 +-
 tests/qemuxml2argvdata/usb-port-autoassign.args    |   10 +-
 tests/qemuxml2argvdata/usb-port-missing.args       |   10 +-
 tests/qemuxml2argvdata/usb-ports.args              |   10 +-
 tests/qemuxml2argvdata/usb-redir-boot.args         |   10 +-
 .../qemuxml2argvdata/usb-redir-filter-version.args |   10 +-
 tests/qemuxml2argvdata/usb-redir-filter.args       |   10 +-
 tests/qemuxml2argvdata/usb-redir.args              |   10 +-
 tests/qemuxml2argvdata/usb-xhci-autoassign.args    |   10 +-
 tests/qemuxml2argvdata/usb1-usb2.args              |   10 +-
 tests/qemuxml2argvdata/user-aliases-usb.args       |    9 +-
 tests/qemuxml2argvdata/user-aliases.args           |   25 +-
 tests/qemuxml2argvdata/vcpu-placement-static.args  |    9 +-
 .../video-device-pciaddr-default.args              |    7 +-
 .../qemuxml2argvdata/video-qxl-device-vgamem.args  |    9 +-
 tests/qemuxml2argvdata/video-qxl-device.args       |    9 +-
 tests/qemuxml2argvdata/video-qxl-heads.args        |    9 +-
 tests/qemuxml2argvdata/video-qxl-nodevice.args     |    9 +-
 tests/qemuxml2argvdata/video-qxl-noheads.args      |    9 +-
 .../video-qxl-sec-device-vgamem.args               |    9 +-
 tests/qemuxml2argvdata/video-qxl-sec-device.args   |    9 +-
 .../qemuxml2argvdata/video-vga-device-vgamem.args  |    9 +-
 tests/qemuxml2argvdata/video-vga-device.args       |    9 +-
 tests/qemuxml2argvdata/video-vga-nodevice.args     |    9 +-
 tests/qemuxml2argvdata/video-vga-qxl-heads.args    |    9 +-
 tests/qemuxml2argvdata/video-virtio-gpu-ccw.args   |    7 +-
 .../qemuxml2argvdata/video-virtio-gpu-device.args  |    9 +-
 .../video-virtio-gpu-secondary.args                |    9 +-
 .../video-virtio-gpu-spice-gl.args                 |    7 +-
 tests/qemuxml2argvdata/video-virtio-gpu-virgl.args |    9 +-
 tests/qemuxml2argvdata/video-virtio-vga.args       |    9 +-
 .../qemuxml2argvdata/virtio-input-passthrough.args |    9 +-
 tests/qemuxml2argvdata/virtio-input.args           |    9 +-
 tests/qemuxml2argvdata/virtio-lun.args             |   16 +-
 tests/qemuxml2argvdata/virtio-options.args         |   15 +-
 tests/qemuxml2argvdata/virtio-rng-ccw.args         |   10 +-
 tests/qemuxml2argvdata/virtio-rng-default.args     |    9 +-
 tests/qemuxml2argvdata/virtio-rng-egd.args         |    9 +-
 tests/qemuxml2argvdata/virtio-rng-multiple.args    |    9 +-
 tests/qemuxml2argvdata/virtio-rng-random.args      |    9 +-
 tests/qemuxml2argvdata/vmcoreinfo.args             |    9 +-
 tests/qemuxml2argvdata/watchdog-device.args        |   10 +-
 tests/qemuxml2argvdata/watchdog-diag288.args       |   10 +-
 tests/qemuxml2argvdata/watchdog-dump.args          |    9 +-
 tests/qemuxml2argvdata/watchdog-injectnmi.args     |    9 +-
 tests/qemuxml2argvdata/watchdog.args               |    9 +-
 tests/qemuxml2argvdata/x86-kvm-32-on-64.args       |    9 +-
 tests/qemuxml2argvtest.c                           |  744 +++-----
 tests/qemuxml2xmltest.c                            |  119 +-
 667 files changed, 4571 insertions(+), 10320 deletions(-)
 delete mode 100644 tests/qemucapabilitiesdata/caps_1.2.2.x86_64.replies
 delete mode 100644 tests/qemucapabilitiesdata/caps_1.2.2.x86_64.xml
 delete mode 100644 tests/qemuhelpdata/qemu-0.12.1
 delete mode 100644 tests/qemuhelpdata/qemu-0.12.1-device
 delete mode 100644 tests/qemuhelpdata/qemu-1.0
 delete mode 100644 tests/qemuhelpdata/qemu-1.0-device
 delete mode 100644 tests/qemuhelpdata/qemu-1.1.0
 delete mode 100644 tests/qemuhelpdata/qemu-1.1.0-device
 delete mode 100644 tests/qemuhelpdata/qemu-1.2.0
 delete mode 100644 tests/qemuhelpdata/qemu-kvm-0.12.3
 delete mode 100644 tests/qemuhelpdata/qemu-kvm-0.12.3-device
 delete mode 100644 tests/qemuhelpdata/qemu-kvm-0.13.0
 delete mode 100644 tests/qemuhelpdata/qemu-kvm-0.13.0-device
 delete mode 100644 tests/qemuhelpdata/qemu-kvm-1.2.0
 delete mode 100644 tests/qemuhelptest.c
 delete mode 100644 tests/qemuxml2argvdata/channel-spicevmc-old.args
 delete mode 100644 tests/qemuxml2argvdata/channel-spicevmc-old.xml

-- 
2.16.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Fri, Mar 30, 2018 at 03:15:16PM +0200, Ján Tomko wrote:
>It's been a while since we last bumped the minimum QEMU version.
>Let's get rid of -help parsing and bring our test suite closer
>to real world usage by implying lots of capabilities.
>
>Ján Tomko (44):

The following patches were > 300 kB:

>  Deprecate QEMU_CAPS_MONITOR_JSON
>  Deprecate QEMU_CAPS_NO_USER_CONFIG
>  Deprecate QEMU_CAPS_RTC
>  Deprecate QEMU_CAPS_NO_SHUTDOWN
>  Deprecate QEMU_CAPS_MACHINE_OPT
>  Deprecate QEMU_CAPS_DUMP_GUEST_CORE
>  Deprecate QEMU_CAPS_DISPLAY
>  Deprecate QEMU_CAPS_MACHINE_USB_OPT
>

I will send shortened versions, you can see the full patches here:

https://repo.or.cz/libvirt/jtomko.git/shortlog/refs/heads/caps_cleanup
git fetch git://repo.or.cz/libvirt/jtomko.git caps_cleanup:

Jano
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Fri, Mar 30, 2018 at 03:15:16PM +0200, Ján Tomko wrote:
> It's been a while since we last bumped the minimum QEMU version.
> Let's get rid of -help parsing and bring our test suite closer
> to real world usage by implying lots of capabilities.

NACK, this is effectively dropping support for RHEL-6 without explicitly
saying you're doing this.

When we bump min required versions, we need to clearly indicate which
distros we're expecting to be supportable given the new min version.

As & when RHEL-8 makes a public appearance of some kind, then we can
drop RHEL-6, but even then we need to consider what other distros are
targetted (Debian, Ubuntu, SLES, etc) when picking the next min version.

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

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Tue, Apr 03, 2018 at 11:45:19 +0100, Daniel Berrange wrote:
> On Fri, Mar 30, 2018 at 03:15:16PM +0200, Ján Tomko wrote:
> > It's been a while since we last bumped the minimum QEMU version.
> > Let's get rid of -help parsing and bring our test suite closer
> > to real world usage by implying lots of capabilities.
> 
> NACK, this is effectively dropping support for RHEL-6 without explicitly
> saying you're doing this.

Upstream libvirt does not support driving the RHEL-6 qemu anyways (at
least from the latest releases) as it diverged significantly from
upstream. Upstream will e.g. not be able to see that JSON monitor needs
to be used with that old version or that the downstream implementations
of some commands need to be used.

Using upstream libvirt on rhel6 without upstream qemu is nonsense. The
argument that you might want new features with the "stability" of the
old OS is wrong if you pull in bugs from upstream.
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Tue, 2018-04-03 at 12:57 +0200, Peter Krempa wrote:
> On Tue, Apr 03, 2018 at 11:45:19 +0100, Daniel Berrange wrote:
> > On Fri, Mar 30, 2018 at 03:15:16PM +0200, Ján Tomko wrote:
> > > It's been a while since we last bumped the minimum QEMU version.
> > > Let's get rid of -help parsing and bring our test suite closer
> > > to real world usage by implying lots of capabilities.
> > 
> > NACK, this is effectively dropping support for RHEL-6 without explicitly
> > saying you're doing this.
> 
> Upstream libvirt does not support driving the RHEL-6 qemu anyways (at
> least from the latest releases) as it diverged significantly from
> upstream. Upstream will e.g. not be able to see that JSON monitor needs
> to be used with that old version or that the downstream implementations
> of some commands need to be used.
> 
> Using upstream libvirt on rhel6 without upstream qemu is nonsense. The
> argument that you might want new features with the "stability" of the
> old OS is wrong if you pull in bugs from upstream.

This makes sense to me. One of the (several) times the topic of
dropping support for older OS, one of the arguments against it was
that downstream vendors were building products on top of RHEL 6,
but at the same time needed newer QEMU / libvirt features, so they
pulled those in from upstream.

Bumping our minimum QEMU version wouldn't affect that kind of
scenario, as long as we keep making sure libvirt itself builds on
RHEL 6 - which we already do as part of the CI effort.

Honestly, who in the world absolutely needs the very last libvirt
while at the same time being stuck with QEMU < 1.3.0? However you
slice it, that doesn't sound like a remotely sane scenario.

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On 04/03/2018 07:23 AM, Andrea Bolognani wrote:
> On Tue, 2018-04-03 at 12:57 +0200, Peter Krempa wrote:
>> On Tue, Apr 03, 2018 at 11:45:19 +0100, Daniel Berrange wrote:
>>> On Fri, Mar 30, 2018 at 03:15:16PM +0200, Ján Tomko wrote:
>>>> It's been a while since we last bumped the minimum QEMU version.
>>>> Let's get rid of -help parsing and bring our test suite closer
>>>> to real world usage by implying lots of capabilities.
>>>
>>> NACK, this is effectively dropping support for RHEL-6 without explicitly
>>> saying you're doing this.
>>
>> Upstream libvirt does not support driving the RHEL-6 qemu anyways (at
>> least from the latest releases) as it diverged significantly from
>> upstream. Upstream will e.g. not be able to see that JSON monitor needs
>> to be used with that old version or that the downstream implementations
>> of some commands need to be used.
>>
>> Using upstream libvirt on rhel6 without upstream qemu is nonsense. The
>> argument that you might want new features with the "stability" of the
>> old OS is wrong if you pull in bugs from upstream.
> 
> This makes sense to me. One of the (several) times the topic of
> dropping support for older OS, one of the arguments against it was
> that downstream vendors were building products on top of RHEL 6,
> but at the same time needed newer QEMU / libvirt features, so they
> pulled those in from upstream.
> 
> Bumping our minimum QEMU version wouldn't affect that kind of
> scenario, as long as we keep making sure libvirt itself builds on
> RHEL 6 - which we already do as part of the CI effort.
> 
> Honestly, who in the world absolutely needs the very last libvirt
> while at the same time being stuck with QEMU < 1.3.0? However you
> slice it, that doesn't sound like a remotely sane scenario.
> 

Between this and Martin's recent posting:

https://www.redhat.com/archives/libvir-list/2018-April/msg00112.html

Maybe we need to formulate some sort of "annual processing" to declare
minimal version support and declare certain non-maintained drivers to be
dead. I believe it becomes harder and harder to support a policy of must
keep support for some sort of "older distro" as time goes on. Tools we
use or rely on don't seem to have this same policy. Considering the
recent python-2 to python-3 adjustments and what seems to be progressing
towards a debate about JSON or yajl parse/formatting support - it seems
upstream libvirt gets caught in the middle of a many "hard places".

At least we have some sort of CI environment that tells us when we've
violated some old version or a distro that some developer didn't
consider/use. Of course, by moving the cheese from upstream to the CI
environment - that essentially "moves" the problem of keeping older
version support on the CI environment rather than the upstream
development environment. All the dependency requirements are (at least
to me) mind boggling to try to keep track of. Not sure we document them
anywhere either.

While perhaps not thought of completely in that manner, perhaps the
*-maint branches should become "the" mechanism for support of older or
more stable supported code. Probably means we need to do a better job at
making sure *-maint branches always get created and of course document
perhaps what "version adjustments" or "dependency changes" occurred for
any particular *-maint branch. Additionally, as part of the review
process consider whether or not a patch [series] should be back ported
into those type branches. That leaves upstream to be relatively fresh or
at least fresh to some period of time chosen.

So, where does one start the draw the line for QEMU considering the
following list of versions and release dates?  Realistically speaking
how long can or should upstream libvirt be expected to keep some really
old QEMU version as minimum? Especially as it gets to be more and more
painful to support newer versions that are coming out in 4 month cycles now.

Looking at git history and considering adjustments to the VERSION file
in the QEMU tree, I get:

QEMU 2.11 -> Dec 2017
QEMU 2.10 -> Aug 2017
QEMU 2.9  -> Apr 2017
QEMU 2.8  -> Dec 2016
QEMU 2.7  -> Sep 2016
QEMU 2.6  -> May 2016
QEMU 2.5  -> Dec 2015
QEMU 2.4  -> Aug 2015
QEMU 2.3  -> Apr 2015
QEMU 2.2  -> Dec 2014
QEMU 2.1  -> Aug 2014
QEMU 2.0  -> Apr 2014
QEMU 1.7  -> Nov 2013
QEMU 1.6  -> Aug 2013
QEMU 1.5  -> May 2013
QEMU 1.4  -> Feb 2013
QEMU 1.3  -> Dec 2012
QEMU 1.2  -> Sep 2012
QEMU 1.1  -> Jun 2012
QEMU 1.0  -> Dec 2011
QEMU 0.15 -> Jul 2011
QEMU 0.14 -> Feb 2011
QEMU 0.13 -> Jul 2010
QEMU 0.12 -> Dec 2009

It would seem to me that ~5 years for 1.3.0 is a "good start" as opposed
to the ~8 years that is 0.12.


John

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Tue, Apr 03, 2018 at 09:29:01AM -0400, John Ferlan wrote:
> 
> 
> On 04/03/2018 07:23 AM, Andrea Bolognani wrote:
> > On Tue, 2018-04-03 at 12:57 +0200, Peter Krempa wrote:
> >> On Tue, Apr 03, 2018 at 11:45:19 +0100, Daniel Berrange wrote:
> >>> On Fri, Mar 30, 2018 at 03:15:16PM +0200, Ján Tomko wrote:
> >>>> It's been a while since we last bumped the minimum QEMU version.
> >>>> Let's get rid of -help parsing and bring our test suite closer
> >>>> to real world usage by implying lots of capabilities.
> >>>
> >>> NACK, this is effectively dropping support for RHEL-6 without explicitly
> >>> saying you're doing this.
> >>
> >> Upstream libvirt does not support driving the RHEL-6 qemu anyways (at
> >> least from the latest releases) as it diverged significantly from
> >> upstream. Upstream will e.g. not be able to see that JSON monitor needs
> >> to be used with that old version or that the downstream implementations
> >> of some commands need to be used.
> >>
> >> Using upstream libvirt on rhel6 without upstream qemu is nonsense. The
> >> argument that you might want new features with the "stability" of the
> >> old OS is wrong if you pull in bugs from upstream.
> > 
> > This makes sense to me. One of the (several) times the topic of
> > dropping support for older OS, one of the arguments against it was
> > that downstream vendors were building products on top of RHEL 6,
> > but at the same time needed newer QEMU / libvirt features, so they
> > pulled those in from upstream.
> > 
> > Bumping our minimum QEMU version wouldn't affect that kind of
> > scenario, as long as we keep making sure libvirt itself builds on
> > RHEL 6 - which we already do as part of the CI effort.
> > 
> > Honestly, who in the world absolutely needs the very last libvirt
> > while at the same time being stuck with QEMU < 1.3.0? However you
> > slice it, that doesn't sound like a remotely sane scenario.
> > 
> 
> Between this and Martin's recent posting:
> 
> https://www.redhat.com/archives/libvir-list/2018-April/msg00112.html
> 
> Maybe we need to formulate some sort of "annual processing" to declare
> minimal version support and declare certain non-maintained drivers to be
> dead. I believe it becomes harder and harder to support a policy of must
> keep support for some sort of "older distro" as time goes on. Tools we
> use or rely on don't seem to have this same policy. Considering the
> recent python-2 to python-3 adjustments and what seems to be progressing
> towards a debate about JSON or yajl parse/formatting support - it seems
> upstream libvirt gets caught in the middle of a many "hard places".
> 
> At least we have some sort of CI environment that tells us when we've
> violated some old version or a distro that some developer didn't
> consider/use. Of course, by moving the cheese from upstream to the CI
> environment - that essentially "moves" the problem of keeping older
> version support on the CI environment rather than the upstream
> development environment. All the dependency requirements are (at least
> to me) mind boggling to try to keep track of. Not sure we document them
> anywhere either.
> 
> While perhaps not thought of completely in that manner, perhaps the
> *-maint branches should become "the" mechanism for support of older or
> more stable supported code. Probably means we need to do a better job at
> making sure *-maint branches always get created and of course document
> perhaps what "version adjustments" or "dependency changes" occurred for
> any particular *-maint branch. Additionally, as part of the review
> process consider whether or not a patch [series] should be back ported
> into those type branches. That leaves upstream to be relatively fresh or
> at least fresh to some period of time chosen.
> 
> So, where does one start the draw the line for QEMU considering the
> following list of versions and release dates?  Realistically speaking
> how long can or should upstream libvirt be expected to keep some really
> old QEMU version as minimum? Especially as it gets to be more and more
> painful to support newer versions that are coming out in 4 month cycles now.
> 
> Looking at git history and considering adjustments to the VERSION file
> in the QEMU tree, I get:

IMHO targetting QEMU specifically is wrong, because the same question comes
up repeatedly for every piece of 3rd party software we depend on. eg it makes
no sense to drop support for QEMU in RHEL-6, but then keep support for yajl
library due to jansson being missing in RHEL-6. We need to consider host
OS platforms as targets, and having decided which host OS we want, that in
turn trivially tells us when we can raise min version of *any* software
package we use.

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

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On 04/03/2018 10:04 AM, Daniel P. Berrangé wrote:
> On Tue, Apr 03, 2018 at 09:29:01AM -0400, John Ferlan wrote:
>>
>>
>> On 04/03/2018 07:23 AM, Andrea Bolognani wrote:
>>> On Tue, 2018-04-03 at 12:57 +0200, Peter Krempa wrote:
>>>> On Tue, Apr 03, 2018 at 11:45:19 +0100, Daniel Berrange wrote:
>>>>> On Fri, Mar 30, 2018 at 03:15:16PM +0200, Ján Tomko wrote:
>>>>>> It's been a while since we last bumped the minimum QEMU version.
>>>>>> Let's get rid of -help parsing and bring our test suite closer
>>>>>> to real world usage by implying lots of capabilities.
>>>>>
>>>>> NACK, this is effectively dropping support for RHEL-6 without explicitly
>>>>> saying you're doing this.
>>>>
>>>> Upstream libvirt does not support driving the RHEL-6 qemu anyways (at
>>>> least from the latest releases) as it diverged significantly from
>>>> upstream. Upstream will e.g. not be able to see that JSON monitor needs
>>>> to be used with that old version or that the downstream implementations
>>>> of some commands need to be used.
>>>>
>>>> Using upstream libvirt on rhel6 without upstream qemu is nonsense. The
>>>> argument that you might want new features with the "stability" of the
>>>> old OS is wrong if you pull in bugs from upstream.
>>>
>>> This makes sense to me. One of the (several) times the topic of
>>> dropping support for older OS, one of the arguments against it was
>>> that downstream vendors were building products on top of RHEL 6,
>>> but at the same time needed newer QEMU / libvirt features, so they
>>> pulled those in from upstream.
>>>
>>> Bumping our minimum QEMU version wouldn't affect that kind of
>>> scenario, as long as we keep making sure libvirt itself builds on
>>> RHEL 6 - which we already do as part of the CI effort.
>>>
>>> Honestly, who in the world absolutely needs the very last libvirt
>>> while at the same time being stuck with QEMU < 1.3.0? However you
>>> slice it, that doesn't sound like a remotely sane scenario.
>>>
>>
>> Between this and Martin's recent posting:
>>
>> https://www.redhat.com/archives/libvir-list/2018-April/msg00112.html
>>
>> Maybe we need to formulate some sort of "annual processing" to declare
>> minimal version support and declare certain non-maintained drivers to be
>> dead. I believe it becomes harder and harder to support a policy of must
>> keep support for some sort of "older distro" as time goes on. Tools we
>> use or rely on don't seem to have this same policy. Considering the
>> recent python-2 to python-3 adjustments and what seems to be progressing
>> towards a debate about JSON or yajl parse/formatting support - it seems
>> upstream libvirt gets caught in the middle of a many "hard places".
>>
>> At least we have some sort of CI environment that tells us when we've
>> violated some old version or a distro that some developer didn't
>> consider/use. Of course, by moving the cheese from upstream to the CI
>> environment - that essentially "moves" the problem of keeping older
>> version support on the CI environment rather than the upstream
>> development environment. All the dependency requirements are (at least
>> to me) mind boggling to try to keep track of. Not sure we document them
>> anywhere either.
>>
>> While perhaps not thought of completely in that manner, perhaps the
>> *-maint branches should become "the" mechanism for support of older or
>> more stable supported code. Probably means we need to do a better job at
>> making sure *-maint branches always get created and of course document
>> perhaps what "version adjustments" or "dependency changes" occurred for
>> any particular *-maint branch. Additionally, as part of the review
>> process consider whether or not a patch [series] should be back ported
>> into those type branches. That leaves upstream to be relatively fresh or
>> at least fresh to some period of time chosen.
>>
>> So, where does one start the draw the line for QEMU considering the
>> following list of versions and release dates?  Realistically speaking
>> how long can or should upstream libvirt be expected to keep some really
>> old QEMU version as minimum? Especially as it gets to be more and more
>> painful to support newer versions that are coming out in 4 month cycles now.
>>
>> Looking at git history and considering adjustments to the VERSION file
>> in the QEMU tree, I get:
> 
> IMHO targetting QEMU specifically is wrong, because the same question comes
> up repeatedly for every piece of 3rd party software we depend on. eg it makes
> no sense to drop support for QEMU in RHEL-6, but then keep support for yajl
> library due to jansson being missing in RHEL-6. We need to consider host
> OS platforms as targets, and having decided which host OS we want, that in
> turn trivially tells us when we can raise min version of *any* software
> package we use.
> 

Right - but beyond depending on you to know the history, culling some
spec file for dependencies, or trying to read/understand the
mappings.yaml file in the CI system, it sure would be nice to have in
some sort of tabular form what we depend on, when we first started
depending on it, when we "discovered" that something new was replacing
it, etc. Personally there's way too many variables and considerations to
keep track of in my head in order to make reasonable conclusions!

I understand QEMU is just but one variable in the complex equation.
Listing QEMU was just an example for this series based on the 8 years
since 0.12 which is the minimum we support now vs. 5 years since 1.3
which is where this series was headed. Using the 2-3 years you responded
in other threads would bring us to QEMU 2.2 or even 2.5.

In the long run, I think this becomes more about being proactive than
reactive. What will be "the policy" going forward.

John

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Tue, Apr 03, 2018 at 10:57:44AM -0400, John Ferlan wrote:
> 
> 
> On 04/03/2018 10:04 AM, Daniel P. Berrangé wrote:
> > On Tue, Apr 03, 2018 at 09:29:01AM -0400, John Ferlan wrote:
> >> Looking at git history and considering adjustments to the VERSION file
> >> in the QEMU tree, I get:
> > 
> > IMHO targetting QEMU specifically is wrong, because the same question comes
> > up repeatedly for every piece of 3rd party software we depend on. eg it makes
> > no sense to drop support for QEMU in RHEL-6, but then keep support for yajl
> > library due to jansson being missing in RHEL-6. We need to consider host
> > OS platforms as targets, and having decided which host OS we want, that in
> > turn trivially tells us when we can raise min version of *any* software
> > package we use.
> > 
> 
> Right - but beyond depending on you to know the history, culling some
> spec file for dependencies, or trying to read/understand the
> mappings.yaml file in the CI system, it sure would be nice to have in
> some sort of tabular form what we depend on, when we first started
> depending on it, when we "discovered" that something new was replacing
> it, etc. Personally there's way too many variables and considerations to
> keep track of in my head in order to make reasonable conclusions!

Yes, its a bit rubbish that we've never documented any of this
before, so I sent a docs patch to set out a policy we could
follow. It would make it easier to identify whether it is
reasonable to cull a platform / target.

> I understand QEMU is just but one variable in the complex equation.
> Listing QEMU was just an example for this series based on the 8 years
> since 0.12 which is the minimum we support now vs. 5 years since 1.3
> which is where this series was headed. Using the 2-3 years you responded
> in other threads would bring us to QEMU 2.2 or even 2.5.

Not sure how you get to 2.2 ?  Even if we drop RHEL-6, RHEL-7 ships 1.5.3
version of QEMU.

> In the long run, I think this becomes more about being proactive than
> reactive. What will be "the policy" going forward.


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

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[...]

>> I understand QEMU is just but one variable in the complex equation.
>> Listing QEMU was just an example for this series based on the 8 years
>> since 0.12 which is the minimum we support now vs. 5 years since 1.3
>> which is where this series was headed. Using the 2-3 years you responded
>> in other threads would bring us to QEMU 2.2 or even 2.5.
> 
> Not sure how you get to 2.2 ?  Even if we drop RHEL-6, RHEL-7 ships 1.5.3
> version of QEMU.
> 

It's the always troubling multiple factor equation. My eyes/brain
dropped the "overlapping" in the other thread's comment:

"This is a sign that instead of saying 2 major releases, we should
instead define "NN" years of overlapping support for a value of NN that
is 2 or 3."

If we went strict 3 years on QEMU support it's 2.2, but throw RHEL7 into
the equation it's 1.5 (almost 5 years old). When/if any OS release train
starts moving faster, we could have a whole lot of interesting
decisions. Still keeping track of which QEMU went into which RHEL (or
SLES or Debian or ...) is not something I keep in the short or long term
memory 0-).

John

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Tue, 2018-04-03 at 09:29 -0400, John Ferlan wrote:
> Maybe we need to formulate some sort of "annual processing" to declare
> minimal version support and declare certain non-maintained drivers to be
> dead. I believe it becomes harder and harder to support a policy of must
> keep support for some sort of "older distro" as time goes on. Tools we
> use or rely on don't seem to have this same policy. Considering the
> recent python-2 to python-3 adjustments and what seems to be progressing
> towards a debate about JSON or yajl parse/formatting support - it seems
> upstream libvirt gets caught in the middle of a many "hard places".

I think there's a distinction to be made between what's part of
the "base system" and what's part of the virtualization stack.

The former is much harder to replace: if we want libvirt to build
at all on RHEL 6, we can't use glibc features that are not available
in RHEL 6's glibc, for example. Same goes for Python, yajl and many
more projects we build upon.

On the other hand, as long as both libvirt and QEMU can be built
and run on RHEL 6, it's perfectly reasonable for someone to take
the latest upstream version of *both* and run them on top of what's
still a supported OS.

Of course, it's still very possible to just stick with whatever
your vendor is offering: in RHEL 6's case, that would be QEMU 0.12
and libvirt 0.10.2, both of which are many years old at this point.

The only issue arises when you try to *combine* the two approaches,
and want to have the very latest libvirt drive RHEL 6's ancient QEMU
version. That's the kind of scenario that, when acknowledged, forces
us to keep around a lot of crufty code. What me and Peter (and Jano,
I guess, since he posted the series to begin with ;) are arguing is
that such a scenario is not very reasonable and we should stop
pretending it is, by keeping around support for RHEL 6 but requiring
a reasonably modern QEMU.

> At least we have some sort of CI environment that tells us when we've
> violated some old version or a distro that some developer didn't
> consider/use. Of course, by moving the cheese from upstream to the CI
> environment - that essentially "moves" the problem of keeping older
> version support on the CI environment rather than the upstream
> development environment. All the dependency requirements are (at least
> to me) mind boggling to try to keep track of. Not sure we document them
> anywhere either.

What you're looking for is

  https://libvirt.org/git/?p=libvirt-jenkins-ci.git;a=tree;f=guests/vars

where we keep track, for each of the projects built on the CentOS
CI, of the build dependencies and, for each of the OS we build on,
what package needs to be installed in order to satisfy said build
dependencies.

And yes, it was a *lot* of work to put it together. Keeping it up
to date is not that bad, though :)

> While perhaps not thought of completely in that manner, perhaps the
> *-maint branches should become "the" mechanism for support of older or
> more stable supported code. Probably means we need to do a better job at
> making sure *-maint branches always get created and of course document
> perhaps what "version adjustments" or "dependency changes" occurred for
> any particular *-maint branch. Additionally, as part of the review
> process consider whether or not a patch [series] should be back ported
> into those type branches. That leaves upstream to be relatively fresh or
> at least fresh to some period of time chosen.

I don't think we want to use maint branches for that.

We should just keep doing regular releases and, once vendors have
lost interest in keeping their downstream libvirt builds updated
besides critical issues, move on - as they already have.

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Tue, Apr 03, 2018 at 01:23:15PM +0200, Andrea Bolognani wrote:
> On Tue, 2018-04-03 at 12:57 +0200, Peter Krempa wrote:
> > On Tue, Apr 03, 2018 at 11:45:19 +0100, Daniel Berrange wrote:
> > > On Fri, Mar 30, 2018 at 03:15:16PM +0200, Ján Tomko wrote:
> > > > It's been a while since we last bumped the minimum QEMU version.
> > > > Let's get rid of -help parsing and bring our test suite closer
> > > > to real world usage by implying lots of capabilities.
> > > 
> > > NACK, this is effectively dropping support for RHEL-6 without explicitly
> > > saying you're doing this.
> > 
> > Upstream libvirt does not support driving the RHEL-6 qemu anyways (at
> > least from the latest releases) as it diverged significantly from
> > upstream. Upstream will e.g. not be able to see that JSON monitor needs
> > to be used with that old version or that the downstream implementations
> > of some commands need to be used.
> > 
> > Using upstream libvirt on rhel6 without upstream qemu is nonsense. The
> > argument that you might want new features with the "stability" of the
> > old OS is wrong if you pull in bugs from upstream.
> 
> This makes sense to me. One of the (several) times the topic of
> dropping support for older OS, one of the arguments against it was
> that downstream vendors were building products on top of RHEL 6,
> but at the same time needed newer QEMU / libvirt features, so they
> pulled those in from upstream.
> 
> Bumping our minimum QEMU version wouldn't affect that kind of
> scenario, as long as we keep making sure libvirt itself builds on
> RHEL 6 - which we already do as part of the CI effort.

Building on RHEL-6  without supporting QEMU/KVM from RHEL-6 is pointless,
you might as well just drop the whole platform. It is not a compelling
story to tell users you can build on RHEL-6 but you won't be able to use
the hypervisor from RHEL-6, as the kernel+KVM+QEMU triple is the compelling
part from guest OS pov. 

> Honestly, who in the world absolutely needs the very last libvirt
> while at the same time being stuck with QEMU < 1.3.0? However you
> slice it, that doesn't sound like a remotely sane scenario.

The version of libvirt that ships with RHEL-6 is very old, lacking many
features and certainly hasn't had all relevant bug fixes backported.
It is certaily relevant to wish to use new libvirt with old QEMU for
"some" period of time. The question is how far back to go. Previously
we've said 2 major RHEL releases was the target

The tension is that the gap between RHEL-5 and RHEL-6 and RHEL-7 was
approx 3 years. If that pattern had carried on RHEL-8 would have arrived
in 2017, and we would have thus culled RHEL-6 support some time last
year. This is a sign that instead of saying 2 major releases, we should
instead define "NN" years of overlapping support for a value of NN
that is 2 or 3. ie drop RHEL-6 as a target after RHEL-7 has been released
for NN years.

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

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Tue, 2018-04-03 at 15:00 +0100, Daniel P. Berrangé wrote:
> On Tue, Apr 03, 2018 at 01:23:15PM +0200, Andrea Bolognani wrote:
> > Bumping our minimum QEMU version wouldn't affect that kind of
> > scenario, as long as we keep making sure libvirt itself builds on
> > RHEL 6 - which we already do as part of the CI effort.
> 
> Building on RHEL-6  without supporting QEMU/KVM from RHEL-6 is pointless,
> you might as well just drop the whole platform. It is not a compelling
> story to tell users you can build on RHEL-6 but you won't be able to use
> the hypervisor from RHEL-6, as the kernel+KVM+QEMU triple is the compelling
> part from guest OS pov.

Most of the compelling features introduced by any libvirt release
require the corresponding QEMU feature to be available. And, as
I've argued elsewhere in the thread, replacing the vendor QEMU and
libvirt with recent upstream releases is much easier than replacing
other components of the OS, most notably the kernel (and hence KVM).

> > Honestly, who in the world absolutely needs the very last libvirt
> > while at the same time being stuck with QEMU < 1.3.0? However you
> > slice it, that doesn't sound like a remotely sane scenario.
> 
> The version of libvirt that ships with RHEL-6 is very old, lacking many
> features and certainly hasn't had all relevant bug fixes backported.
> It is certaily relevant to wish to use new libvirt with old QEMU for
> "some" period of time. The question is how far back to go. Previously
> we've said 2 major RHEL releases was the target
> 
> The tension is that the gap between RHEL-5 and RHEL-6 and RHEL-7 was
> approx 3 years. If that pattern had carried on RHEL-8 would have arrived
> in 2017, and we would have thus culled RHEL-6 support some time last
> year. This is a sign that instead of saying 2 major releases, we should
> instead define "NN" years of overlapping support for a value of NN
> that is 2 or 3. ie drop RHEL-6 as a target after RHEL-7 has been released
> for NN years.

As I have argued elsewhere in the thread, I think we can still
support two major releases of the *base system*, but we should
drop support for the downstream virtualization stack (eg. QEMU)
a reasonable, short-ish time after the vendor itself has stopped
updating it.

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Tue, Apr 03, 2018 at 04:43:41PM +0200, Andrea Bolognani wrote:
> On Tue, 2018-04-03 at 15:00 +0100, Daniel P. Berrangé wrote:
> > On Tue, Apr 03, 2018 at 01:23:15PM +0200, Andrea Bolognani wrote:
> > > Bumping our minimum QEMU version wouldn't affect that kind of
> > > scenario, as long as we keep making sure libvirt itself builds on
> > > RHEL 6 - which we already do as part of the CI effort.
> > 
> > Building on RHEL-6  without supporting QEMU/KVM from RHEL-6 is pointless,
> > you might as well just drop the whole platform. It is not a compelling
> > story to tell users you can build on RHEL-6 but you won't be able to use
> > the hypervisor from RHEL-6, as the kernel+KVM+QEMU triple is the compelling
> > part from guest OS pov.
> 
> Most of the compelling features introduced by any libvirt release
> require the corresponding QEMU feature to be available. And, as
> I've argued elsewhere in the thread, replacing the vendor QEMU and
> libvirt with recent upstream releases is much easier than replacing
> other components of the OS, most notably the kernel (and hence KVM).

There are plenty of features we introduce that don't require new software
versions. They may not be as frequent, but there are still compelling.


> > > Honestly, who in the world absolutely needs the very last libvirt
> > > while at the same time being stuck with QEMU < 1.3.0? However you
> > > slice it, that doesn't sound like a remotely sane scenario.
> > 
> > The version of libvirt that ships with RHEL-6 is very old, lacking many
> > features and certainly hasn't had all relevant bug fixes backported.
> > It is certaily relevant to wish to use new libvirt with old QEMU for
> > "some" period of time. The question is how far back to go. Previously
> > we've said 2 major RHEL releases was the target
> > 
> > The tension is that the gap between RHEL-5 and RHEL-6 and RHEL-7 was
> > approx 3 years. If that pattern had carried on RHEL-8 would have arrived
> > in 2017, and we would have thus culled RHEL-6 support some time last
> > year. This is a sign that instead of saying 2 major releases, we should
> > instead define "NN" years of overlapping support for a value of NN
> > that is 2 or 3. ie drop RHEL-6 as a target after RHEL-7 has been released
> > for NN years.
> 
> As I have argued elsewhere in the thread, I think we can still
> support two major releases of the *base system*, but we should
> drop support for the downstream virtualization stack (eg. QEMU)
> a reasonable, short-ish time after the vendor itself has stopped
> updating it.

I don't think the "base" vs "virtualization" stack distinction is a good
thing to base our decisions on. In RHEL-5 there was no distinction in
this at all - virt was a core part of every RHEL subscription. In RHEL-7
meanwhile the base system includes an ancient version of QEMU (1.5.3)
that everyone gets, while another add-on gives you new QEMU. I'll bet
future RHEL will be different again.

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

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Tue, 2018-04-03 at 15:59 +0100, Daniel P. Berrangé wrote:
> On Tue, Apr 03, 2018 at 04:43:41PM +0200, Andrea Bolognani wrote:
> > Most of the compelling features introduced by any libvirt release
> > require the corresponding QEMU feature to be available. And, as
> > I've argued elsewhere in the thread, replacing the vendor QEMU and
> > libvirt with recent upstream releases is much easier than replacing
> > other components of the OS, most notably the kernel (and hence KVM).
> 
> There are plenty of features we introduce that don't require new software
> versions. They may not be as frequent, but there are still compelling.

How many of those would be compelling enough to convince users to
step outside of the comfort zone (and probably support terms) of
vendor-provided packages and roll their own virtualization stack
from upstream sources?  I reckon not that many. But if you add a
newer QEMU to the mix, then that's a wholly different value
proposition.

> > As I have argued elsewhere in the thread, I think we can still
> > support two major releases of the *base system*, but we should
> > drop support for the downstream virtualization stack (eg. QEMU)
> > a reasonable, short-ish time after the vendor itself has stopped
> > updating it.
> 
> I don't think the "base" vs "virtualization" stack distinction is a good
> thing to base our decisions on. In RHEL-5 there was no distinction in
> this at all - virt was a core part of every RHEL subscription. In RHEL-7
> meanwhile the base system includes an ancient version of QEMU (1.5.3)
> that everyone gets, while another add-on gives you new QEMU. I'll bet
> future RHEL will be different again.

My point is that QEMU and libvirt move much faster than eg. glibc,
so while it's very possible to target RHEL 6's userland without
bending over backwards and introducing or keeping around heaps of
compatibility code, the same is not necessarily true for RHEL 6's
QEMU, as evidenced by Jano's series.

RHEL 7's virtualization stack is still in a place where new
features are being introduced, as shown by the fact that every
minor release brings in a new libvirt release: that makes it a
reasonable target for the upstream project. RHEL 6 has been
standing still for a while now, so it's okay for us to move on.

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Tue, Apr 03, 2018 at 05:29:52PM +0200, Andrea Bolognani wrote:
> On Tue, 2018-04-03 at 15:59 +0100, Daniel P. Berrangé wrote:
> > On Tue, Apr 03, 2018 at 04:43:41PM +0200, Andrea Bolognani wrote:
> > > Most of the compelling features introduced by any libvirt release
> > > require the corresponding QEMU feature to be available. And, as
> > > I've argued elsewhere in the thread, replacing the vendor QEMU and
> > > libvirt with recent upstream releases is much easier than replacing
> > > other components of the OS, most notably the kernel (and hence KVM).
> > 
> > There are plenty of features we introduce that don't require new software
> > versions. They may not be as frequent, but there are still compelling.
> 
> How many of those would be compelling enough to convince users to
> step outside of the comfort zone (and probably support terms) of
> vendor-provided packages and roll their own virtualization stack
> from upstream sources?  I reckon not that many. But if you add a
> newer QEMU to the mix, then that's a wholly different value
> proposition.

The introduction of virtlogd was one such feature that was compelling
to upgrade libvirt for without any change in QEMU, as it fixed a long
term security problem in libvirt.

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

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Tue, Apr 03, 2018 at 12:57:45PM +0200, Peter Krempa wrote:
> On Tue, Apr 03, 2018 at 11:45:19 +0100, Daniel Berrange wrote:
> > On Fri, Mar 30, 2018 at 03:15:16PM +0200, Ján Tomko wrote:
> > > It's been a while since we last bumped the minimum QEMU version.
> > > Let's get rid of -help parsing and bring our test suite closer
> > > to real world usage by implying lots of capabilities.
> > 
> > NACK, this is effectively dropping support for RHEL-6 without explicitly
> > saying you're doing this.
> 
> Upstream libvirt does not support driving the RHEL-6 qemu anyways (at
> least from the latest releases) as it diverged significantly from
> upstream. Upstream will e.g. not be able to see that JSON monitor needs
> to be used with that old version or that the downstream implementations
> of some commands need to be used.

The scenario wrt JSON monitor support was also the case when RHEL-6.0 first
came out. It is easily addressed with a tweak to the version number check.
We eventually added that RHEL-6 custom check to libvirt upstream too, but
then later reverted it. Thus whether we have that tweaked version check in
upstream or not, doesn't change whether we should consider the RHEL-6
vintage to be a supported target or not IMHO. 

> Using upstream libvirt on rhel6 without upstream qemu is nonsense. The
> argument that you might want new features with the "stability" of the
> old OS is wrong if you pull in bugs from upstream.

Libvirt's goal has always been to enable developers to use new libvirt
with previous versions of QEMU. We have *never* said that when you deploy
new libvirt on a platform, you must also update QEMU. The only requirement
has been that you must have the minimum declared version number, never
latest upstream QEMU.

It is entirely reasonable to want to use a new libvirt without updating
the QEMU version, because the QEMU/KVM/kernel triple is what provides the
guest OS / driver compatibility testing & thus is the most compelling part
of the supported platform RHEL provides. 

That said we are of course not going to support RHEL-6 forever and it is
reasonable to consider when the cut-off point is for the platform as a
whole. Historically we have considered 2 major RHEL releases to be the
target. IOW drop RHEL-6 when RHEL-8 appears. Maybe that is too long and
we would be better saying we'll aim for an N year overlap of support for
major RHEL releases, for a value of N that's less than the time delta
between RHEL 7 & 8. 

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

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Tue, Apr 03, 2018 at 02:49:34PM +0100, Daniel P. Berrangé wrote:
> On Tue, Apr 03, 2018 at 12:57:45PM +0200, Peter Krempa wrote:
> > On Tue, Apr 03, 2018 at 11:45:19 +0100, Daniel Berrange wrote:
> > > On Fri, Mar 30, 2018 at 03:15:16PM +0200, Ján Tomko wrote:
> > > > It's been a while since we last bumped the minimum QEMU version.
> > > > Let's get rid of -help parsing and bring our test suite closer
> > > > to real world usage by implying lots of capabilities.
> > > 
> > > NACK, this is effectively dropping support for RHEL-6 without explicitly
> > > saying you're doing this.
> > 
> > Upstream libvirt does not support driving the RHEL-6 qemu anyways (at
> > least from the latest releases) as it diverged significantly from
> > upstream. Upstream will e.g. not be able to see that JSON monitor needs
> > to be used with that old version or that the downstream implementations
> > of some commands need to be used.
> 
> The scenario wrt JSON monitor support was also the case when RHEL-6.0 first
> came out. It is easily addressed with a tweak to the version number check.
> We eventually added that RHEL-6 custom check to libvirt upstream too, but
> then later reverted it. Thus whether we have that tweaked version check in
> upstream or not, doesn't change whether we should consider the RHEL-6
> vintage to be a supported target or not IMHO. 
> 
> > Using upstream libvirt on rhel6 without upstream qemu is nonsense. The
> > argument that you might want new features with the "stability" of the
> > old OS is wrong if you pull in bugs from upstream.
> 
> Libvirt's goal has always been to enable developers to use new libvirt
> with previous versions of QEMU. We have *never* said that when you deploy
> new libvirt on a platform, you must also update QEMU. The only requirement
> has been that you must have the minimum declared version number, never
> latest upstream QEMU.
> 
> It is entirely reasonable to want to use a new libvirt without updating
> the QEMU version, because the QEMU/KVM/kernel triple is what provides the
> guest OS / driver compatibility testing & thus is the most compelling part
> of the supported platform RHEL provides. 
> 
> That said we are of course not going to support RHEL-6 forever and it is
> reasonable to consider when the cut-off point is for the platform as a
> whole. Historically we have considered 2 major RHEL releases to be the
> target. IOW drop RHEL-6 when RHEL-8 appears. Maybe that is too long and
> we would be better saying we'll aim for an N year overlap of support for
> major RHEL releases, for a value of N that's less than the time delta
> between RHEL 7 & 8. 

That sounds reasonable, I would even vote for 2 year overlap, but
that would be probably way too strict so 3 year overlap is a good
compromise.  This would mean that we can drop support for RHEL < 7,
SLES < 12 and Debian < 8.

Pavel
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list