[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] storing machine data in qcow images?

From: Max Reitz
Subject: Re: [Qemu-devel] storing machine data in qcow images?
Date: Tue, 29 May 2018 11:23:14 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

On 2018-05-28 21:09, Kevin Wolf wrote:
> Am 28.05.2018 um 20:44 hat Max Reitz geschrieben:
>> On 2018-05-28 20:38, Kevin Wolf wrote:
>>> Am 28.05.2018 um 20:30 hat Richard W.M. Jones geschrieben:
>>>> On Mon, May 28, 2018 at 08:10:32PM +0200, Max Reitz wrote:
>>>>> As someone who is just naive and doesn't see the big picture, I don't
>>>>> see what's wrong with using a tar file that contains the image and
>>>>> additional data.
>>>> FWIW an OVA file is exactly this: an uncompressed tar file containing
>>>> disk image(s) and metadata.
>>> If we combine VM configuration and the disk image this way, I would
>>> still want to directly use that combined thing without having to extract
>>> its components first.
>>> Just accessing the image file within a tar archive is possible and we
>>> could write a block driver for that (I actually think we should do
>>> this), but it restricts you because certain operations like resizing
>>> aren't really possible in tar. Unfortunately, resizing is a really
>>> common operation for non-raw image formats.
>>> And if I think of a file format that can contain several different
>>> things that can be individually resized etc., I end up with qcow2 in the
>>> simple case or a full file system in the more complex case.
>> Well, you end up with VMDK.
> I don't think VMDK can save several different objects? It can have some
> metadata in the descriptor, and it can spread the contents of a single
> object across multiple files (with extents), but I don't think it has
> something comparable to e.g. qcow2 snapshots, which are separate objects
> with an individual size that can dynamically change.

Right, I tried to be funny and was over-simplifying in the process.

What I meant is: You end up with an image format that is spread on a
filesystem, like VMDK is (usually).  Then you have some metadata
descriptor file that describes the rest and multiple data object files.

(For completeness's sake: And you can use an external or an internal
filesystem, that is, use multiple files (like VMDK) or have an internal
filesystem (like tar, except tar doesn't allow fragmentation).)


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]