Re: [Qemu-devel] Re: KVM call agenda for Jan 25

[Kevin Wolf <kwolf@redhat.com>]

Am 14.03.2011 16:13, schrieb Dushyant Bansal:
>>
>> Nice that qemu-img convert isn't that far out by default on raw :).
>>
>> About Google Summer of Code, I have posted my take on applying and
>> want to share that with you and qemu-devel:
>>
>> http://blog.vmsplice.net/2011/03/advice-for-students-applying-to-google.html
>>    
> Thanks for sharing your experiences.
> 
> After reading about qcow2 and qed and how they organize data (thanks to 
> the newly added qcow2 doc and discussions on the mailing list), this is 
> what I understand.
> 
> So, the main difference between qed and qcow2 is the absence of 
> reference count structure in qed(means less meta data).
> It improves performance due to:
> 1. For write operations, less or no metadata to update.
> 2. Data write and metadata write can be in any order
> 
> This also means these features are no longer supported:
> 1. Internal snapshots,
> 2. CPU/device state snapshots,
> 3. Compression,
> 4. Encryption
> 
> Now, coming to qed<-->qcow2 conversion, I want to clarify some things.
> 
> 1. header_size: variable in qed, equals to cluster size in qcow2:
> When will it be larger than 1 cluster in qed? So, what will happen to 
> that extra data on qed->qcow2 conversion.

If you have an feature that is used in the original image, but cannot be
represented in the new format, I think you should just get an error.

> 2. L2 table size: equals to L1 table size in qed, equals to cluster size 
> in qcow2:
> we need to take it into account during conversion.

Right. I think we'll have to rewrite all of the metadata.

I wonder if we can manage to have a nice block driver interface for
in-place image conversions so that we don't only get a qed<->qcow2
converter, but also can implement the interface in e.g. VMDK and get
VMDK<->qcow2 and VMDK<->qed as well.

> 3. refcount table:
> qcow2->qed:we do not keep refcount structure
> qed->qcow2: initialize refcount structure

Yes, refcounts can be rebuilt after the mapping has been converted.

> So, a qcow2->qed->qcow2 conversion means if earlier, qcow2 image was 
> using additional features{1-4}, all information related to that will be 
> lost.

We shouldn't lose anything but just abort if a conversion isn't
possible. The user can still use qemu-img convert for the more
complicated cases, for example for removing encryption or compression.

Kevin