On 07/21/11 15:47, Eric Blake wrote:
On 07/21/2011 02:40 AM, Jes Sorensen wrote:
>> The security goal of libvirt is to protect the host from a compromised
>> QEMU, therefore QEMU is, by definition, untrusted.
>
> Well that part goes both ways. By applying this model you are going to
> make it a hard requirement for libvirt to be upgraded with QEMU even for
> smaller updates.
Right now, libvirt only needs the name of the backing file and type. How
often has the qcow2 file format changed in such a way that that
particular information has been incompatibly moved around, so that
clients have to learn a new file format in order to parse the
information in its new location? The set of information that libvirt
needs out of a qcow2 image is relatively small and stable, compared to
any other changes being made in the rest of the file format, and the
libvirt folks are more than welcome to help review any qcow2 format
changes for stability impacts.
QED, QCOW3
either way, libvirt should be able to boot a guest with an upgraded
QEMU, even if it doesn't support all the features. In this case you are
going to provide a hard requirement on libvirt being upgraded in sync.
Furthermore, you are forgetting that libvirt already ends up
upgrading
to pick up new qemu features all the time, not just for qcow2 layout
changes. If you are okay with the feature set supported by an older
qemu, then you are also okay using an older libvirt that targets just
that feature set - you only have to upgrade libvirt when talking to a
newer qemu that requires the use of a newer feature set. Older libvirt
can generally talk to newer qemu if qemu made backwards-compatible changes.
There is a difference between upgrading to pick up additional features
and forced upgrade.
It is not just a question of libvirt possibly reviewing a file format,
it is also having two codebases that needs to be implemented and maintained.
Jes