On Thu, May 24, 2018 at 12:32:51PM +0100, Richard W.M. Jones wrote:
> There is however a seed of a good idea in the thread:
>
> > I don't think QEMU needs to use this information automatically,
> > necessarily. I think the first step is to simply make QEMU save
> > this information in the disk image, and making qemu-img able to
> > read and write this information.
>
> It would be nice if qcow2 added arbitrary data sections (which would
> always be ignored by qemu) for storing additional data. This could be
> used to create a compact qcow2 + metadata format to rival OVA for
> management layers to use, and there are various other uses too.
>
> Rich.
I think this part is pretty uncontroversial.
But can we add data without changing the verion?
typedef struct QCowHeader {
uint32_t magic;
uint32_t version;
uint64_t backing_file_offset;
uint32_t backing_file_size;
uint32_t mtime;
uint64_t size; /* in bytes */
uint8_t cluster_bits;
uint8_t l2_bits;
uint16_t padding;
uint32_t crypt_method;
uint64_t l1_table_offset;
} QEMU_PACKED QCowHeader;
How about changing mtime to a flags bitmap?
E.g. 0x1 would mean there's an extended header.
And then:
struct QCowExtHeader {
uint64_t meta_data_offset;
uint32_t meta_data_size;
uint32_t meta_data_format; /* 0x0 - UTF-8 NULL-terminated string */
};
Thanks!
--
MST
