cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Sorensen <>
Subject Re: kvm - why just qcow2
Date Sat, 14 Dec 2013 15:59:38 GMT
Yeah. I don't think it would be so bad, since we already do qemu-img
convert on any non-file based storage, or at least a copy. I think the
impact would be negligible or none going from a vmdk template to raw
compared to the existing qcow2 to raw, but definitely be felt on file based
primary storage that normally just copies the template file.
On Dec 14, 2013 4:35 AM, "Wido den Hollander" <> wrote:

> On 12/14/2013 09:05 AM, Marcus Sorensen wrote:
>> I suppose it would be best, and probably easiest, to accept templates in
>> vmdk, vdi, etc, but qemu-img convert to qcow2 during the copy to primary
>> storage, to keep the agent code from dealing with many formats. There's a
>> lot of code that would need rework to deal with non-qcow2 file based
>> disks.
> I ran into this when implementing RBD. Since the code made all kinds of
> assumptions when it came to the format. RBD uses RAW (how KVM sees it).
> That's why I wrote to abstract most of that work.
> But I agree with you, we shouldn't force ourselfs into QCOW2, but we
> should be aware that the hypervisors could be doing a lot of converting
> work.
> Wido
>  On Dec 13, 2013 10:39 PM, "Marcus Sorensen" <> wrote:
>>  Is there any reason why we only support qcow2 format on KVM? It seems
>>> like it would be fairly simple to support other formats, qemu-img can
>>> handle going from VMDK to RAW for example, and qemu-kvm can even use
>>> VMDK, QED, and other formats. It even seems like was
>>> written with other formats in mind. It seems like it wouldn't be a lot
>>> of work to simply let other formats come through, we might have to
>>> change LibvirtVMDef a bit so it can make the proper XML.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message