Comment 12 for bug 656173

Jamin, that is why there will be a release note. There isn't much else that can be done. Applications change with new versions and people need to adapt the applications that use the changed applications appropriately. The tools that most people use are either already adjusted or are going to be as I mentioned in the other bug. If someone is going to be creating machines with raw XML, he/she is going to have to create the correct XML.

The implication of your comments suggests that you believe the behavior should somehow change. The default (which is the same for upstream and also an upcoming lucid security update) should not change, but people who require the old behavior can adjust /etc/libvirt/qemu.conf accordingly (but why not just fix the script/template that creates the XML?). The changed behavior fixes an important security flaw in libvirt. Imagine a VM with 2 raw disks and a libvirt that probes the disk for its format. A privileged user *in the guest* could write to the beginning of the second disk the necessary (and widely known) qemu disk structure, declare some arbitrary file on the system as its backing store, then wait for a reboot. On reboot, the guest now can access that file because libvirt probes the 2nd disk, discovers it is a qcow2 with backingstore, and calls the AppArmor (or SELinux, or DAC, it doesn't matter) security driver to add it to its list of allowed files, and the attacker has access to that data (the AppArmor driver will protect against some parts of the host, such as /etc, but most of the system is available to an attacker still-- including other virtual machine's disks). Granted it is a one shot deal since the attacker won't be able to modify the disk structure once qemu recognizes it as a qcow2, but the impact is potentially very high if she gets it right.