Am 24.05.2018 um 16:56 hat Michael S. Tsirkin geschrieben:
> 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?
Yes. Don't worry about where to store it, we'll solve this. Do worry
about what to store.
> 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.
You're looking at the qcow1 header. qcow2 has mechanisms to extend the
metadata, including compatible and incompatible feature flags and a
header_length field.
Kevin
