[libvirt] [Qemu-devel] live snapshot wiki updated

[Jes Sorensen]

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