[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Supporting QEMU/KVM in wheezy-lts


(no April's 1st joke):

For QEMU/KVM the codebase between the Wheezy version and current
upstream diverged that heavily that I did not find any help to support
the Wheezy versions any longer. The Wheezy version lacks support for
some modern OSes (e.g. newer Windows versions) as well. RedHat is
carrying vast amount of patches to support old versions to stay closer
to upstream.

So I basically see two alternatives: not supporting KVM/QEMU at all in
Wheezy LTS or switching to newer versions. I'd like to propose the

** Update QEMU/KVM and libvirt to the versions in jessie

The proposal is to use the these versions and update the needed
dependencies in wheezy-lts as well.

Due to the amount of work already done by the current package
maintainers a switch to the Jessie versions of QEMU/KVM/libvirt looks
quiet doable:

** Wheezy-backports already has recent versions

We already have recent versions of QEMU and libvirt in the backports

| Package  | jessie-p-u         | wheezy-pbo                    |
| qemu-kvm | 2.1+dfsg-12+deb8u4 | 1:2.1+dfsg-12+deb8u5a~bpo70+1 |
| libvirt  | 1.2.9-9+deb8u2     | 1.2.9-9~bpo70+1               |

Libvirt 1.2.9-9+deb8u2~bpo70+1 is currently waiting in backports-policy.

*** Depenedencies that need updates in wheezy-lts for qemu-kvm

The following packages would need to be updated in wheezy-lts. All
needed versions are already available in wheezy-backports. The table
shows the versions in wheezy, the versions in wheezy-backports and
information about reverse dependencies. If there are only limited rdeps
these are listed, the number of rdeps in wheezy is given otherwise:

| Package          | wheezy                       | wheezy-bpo                             | rdeps                  |
| libspice-server1 | 0.11.0-1+deb7u2              | 0.12.4-0nocelt2~bpo70+1                | xserver-xorg-video-qxl |
| openbios         | 1.0+svn1060-1                | 1.1+svn1306-2~bpo70+1                  | qemu-only              |
| libusb-1.0-0     | 2:1.0.11-1                   | 2:1.0.19-1~bpo70+1                     | 57                     |
| ipxe-qemu        | 1.0.0+git-20120202.f6840ba-3 | 1.0.0+git-20131111.c3d1e78-2.1~bpo70+1 | qemu-only              |
| seabios          | 1.7.0-1                      | 1.7.5-1~bpo70+1                        | qemu-only              |

*** Dependencies that need updates in wheezy-lts for libvirt

The following packages would need to be updated or introduced to
wheezy-lts for libvirt. The table again shows the versions already in
wheezy-backports and the number of rdeps.

| Package             | wheezy  | wheezy-bpo   | rdeps | Comment                     |
| init-system-helpers | -       | 1.18~bpo70+1 |     0 | not yet available in wheezy |
| polkit-1            | 0.105-3 | -            |    33 | for CVE-2013-4311           |

The polkit update is necessary to resolve CVE-2013-4311 which would
otherwise be "introduced" to Wheezy (the bug exists there already but
not in the default configuration). It would need patches from 0.105-4.

** Way forward
These tests should at least be done before updating the packages in

*** Figure out possible rdepends breackage
  - [ ] Test installer (libusb builds a udeb)
*** Upgrade testing
**** Possile Caveats/downsides
  - Libvirt 1.2.9 switched to policy-kit based auth (but membership of
    libvirt group still sufficient) - can be handled via release notes
**** Tested Szenarios
  Besides simple upgrades we should test
  - [X] Upgrading libvirt with VMs running
  - [X] Upgrading QEMU/KVM with VMs running
  - [ ] Test restoration of qcow2 snapshot taken prior to the QEMU upgrade

Szenarios marked [X] were already tested.

** Possible upgrade plan
*** Announce switch in Release Notes, Debian NEWS, debian-lts-announce two month in advance
  - Provide pinning configuration for people not wanting to upgrade
  When: Start of Wheezy-LTS on 2016-04-26
*** Upload pckages to wheezy-security
  When: 2016-06-26

I'm happy about any feedback if this looks like a good idea and time
well spent.
 -- Guido

Reply to: