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.
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.
--
Eric Blake eblake@xxxxxxxxxx +1-801-349-2682
Libvirt virtualization library http://libvirt.org
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list