On Tue, 2006-07-04 at 11:23 +0200, Fabrice Bellard wrote:
> Hi,
>
> I am not sure it is interesting to store the configuration of the VM in
> the disk image (there can be several disk images for a given VM).
> Moreover, extensions to the qcow header must be added at its end.
Storing the config in the disk image does not preclude:
1. using multiple disk images with a vm
2. using multiple vm's with a single disk image
Nor does it make it more difficult to do any of the above. All it does
is make it easier for the use case of one VM with one image, which is
the vast majority of VM's out there.
In addition, it definitely is interesting to store other random data in
the image. Here is a second proposal:
We have a key/value section that replaces the backing store section:
typedef struct QCowHeader {
uint32_t magic;
uint32_t version;
uint64_t key_val_offset; /* was backing_file_offset */
uint32_t key_val_size; /* was backing_file_size */
uint32_t mtime;
uint64_t size;
uint8_t cluster_bits;
uint8_t l2_bits;
uint32_t crypt_method;
uint64_t l1_table_offset;
} QCowHeader;
The above does not change the size of the header. And as such, you can
still read the header off the file and determine how to interpret it
based on the version number.
The key_val section is pairs of null terminated (UTF-8?) strings. The
first string in the pair is the key, the second is the value.
It could handle the current backing store design like this:
"backing_store": "<filename>"
> Regarding my current plans, the next qcow evolution will be the support
> for multiple snapshots. Each snapshot will be tagged by a label.
I assume you'll do this with multiple backing stores:
"num_backing_stores" : "2"
"backing_store_0" : "<filename>"
"backing_store_0_label": "<label>"
"backing_store_1" : "<filename>"
"backing_store_1_label": "<label>"
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
