qcow image created in precise is not usable

According to our IRC discussion detecting the local qemu version and - in case it is too old - adding a safety option to not enable lazy-refcounts - would be a solution.

We have to balance that effort vs. the remaining time precise will be supported in the face of uvtool being only a ppa there.

Document latest thoughts before context switching:

[15:54] <rbasak> cpaelzer: it looks like it can all be done in the XML - https://libvirt.org/formatstorage.html#StorageVolTarget has the definition, and the compat and feature/lazy_refcounts tags look relevant.
[15:55] <rbasak> cpaelzer: then in uvtool, uvtool/libvirt/kvm.py:create_cow_volume_by_path would be the function to change.
[15:55] <rbasak> I'm not sure how to decide on whether to enable compatiblity mode or not.
[15:56] <cpaelzer> I found the function, thanks for the spec pointer above
[15:57] <cpaelzer> rbasak: I'll hack it in locally to see if it even fixes the issue
[15:57] <cpaelzer> then we can think/decide further

Created image can be checked without starting a VM

qemu-img check /var/lib/uvtool/libvirt/images/kvmguest-precise.qcow
qemu-img: '' uses a qcow2 feature which is not supported by this qemu version: QCOW version 3
qemu-img: Could not open '/var/lib/uvtool/libvirt/images/kvmguest-precise.qcow': Operation not supported

This even happens with a Compat 0.10 XML on creation:
<volume>
  <name>kvmguest-precise.qcow</name>
  <allocation>0</allocation>
  <capacity unit="G">8</capacity>
  <target>
    <format type="qcow2"/>
    <compat>0.10</compat>
  </target>
  <backingStore>
    <path>/var/lib/uvtool/libvirt/images/x-uvt-b64-Y29tLnVidW50dS5jbG91ZC5kYWlseTpzZXJ2ZXI6MTIuMDQ6YW1kNjQgMjAxNjA4Mjk=</path>
    <format type="qcow2"/>
  </backingStore>
</volume>

A qemu-img created image works
qemu-img create -f qcow2 /tmp/test.qcow2 10M
Formatting '/tmp/test.qcow2', fmt=qcow2 size=10485760 encryption=off cluster_size=65536

qemu-img check /tmp/test.qcow2
Leaked cluster 0 refcount=2 reference=1
Leaked cluster 1 refcount=2 reference=1
Leaked cluster 2 refcount=2 reference=1
Leaked cluster 3 refcount=2 reference=1

4 leaked clusters were found on the image.
This means waste of disk space, but no harm to data.

I found it, the reason this still failed is that the backing file had the new option as well.
That was on a shared storage and synced on trusty before.

So "inside" an "only precise" scope -> no-bug.

Given the time precise will still be around and this only being an ppa I think we can keep it as wont fix.

The LP bug might serve anyone else running into it as a helper to understand what is going on.