Anthony Liguori wrote: > Avi Kivity wrote: >> Anthony Liguori wrote: >> >>> I don't think adding annotations as snapshots is the right approach. I >>> think proper support should be added in the header. I wouldn't be too >>> concerned with breaking compatibility in qcow2. That's why it's qcow2 >>> and not just an updated version of qcow, qcow2 is still, AFAIK, open for >>> breakage. >>> >>> >> Are all the users' images open for breakage too? >> > > FWIW, you can extended the header without causing a breakage. Just bump > the version, add the field, and add appropriate code. Of course, this > is technically qcow v3 but it's a good opportunity to make things a bit > sanier such that instead of check version == QCOW_VERSION that version > >= QCOW_VERSION.
It's funny, we had the same kind of discussion about ext3/ext4 some months
ago...
The problem with changing qcow version is you prevent people using unmodified
version of qemu to use this disk image.
IMHO, I think the best thing to do is to introduce the command line option in
empty snapshot in current version of qcow2 (so an unmodified version of qemu is
able to use the image, ignoring the command line, and a modified version can use
this new feature). And then, after, thinking about QCOW3 we can define a set of
new functionalities we want to introduce and add "command line in qcow header"
in this set of functionalities.
Regards,
Laurent
--
------------- [EMAIL PROTECTED] --------------
"Software is hard" - Donald Knuth
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
