lex
>
>> -Original Message-
>> From: Marcus Sorensen [mailto:shadow...@gmail.com]
>> Sent: Tuesday, December 17, 2013 8:06 AM
>> To: dev@cloudstack.apache.org
>> Subject: Re: kvm - why just qcow2
>>
>> 1) Would it be OK to move VmdkProcessor to OVAP
ilto:shadow...@gmail.com]
> Sent: Tuesday, December 17, 2013 8:06 AM
> To: dev@cloudstack.apache.org
> Subject: Re: kvm - why just qcow2
>
> 1) Would it be OK to move VmdkProcessor to OVAProcessor, so we can use
> VmdkProcessor for native .vmdk files?
>
> 2) I also noticed in my
1) Would it be OK to move VmdkProcessor to OVAProcessor, so we can use
VmdkProcessor for native .vmdk files?
2) I also noticed in my testing that .ova is the one format so far
that doesn't work out of the box with minor code changes for KVM, and
it seems to be due to the fact that VmdkProcessor un
No. You have to do qcow2 for KVM and VHD for XenServer as it is now,
by the way. But if we allowes multiple types I think we'd want to
convert to a single 'preferred' format for each primary storage,
rather than messing with all different support between primary
storage, image formats, and their r
;> Marcus,
>>>>>
>>>>> When I refactored the template upload process ages ago, I left in an
>>>>> interface called Processor.java. The whole purpose of which was to
>>>>>allow
>>>>> others to add post processing of the te
On 16.12.2013 05:05, Marcus Sorensen wrote:
Actually, I'm wrong. It used to qemu-img convert qcow2 to qcow2, but
not any more. Qemu is actually just using vmdk natively.
Disappointment. I was going to build some "hv agnostic" templates, but
I really don't want my KVM to run vmdk files etc.
To
e template upload process ages ago, I left in an
>>>> interface called Processor.java. The whole purpose of which was to allow
>>>> others to add post processing of the template once its been uploaded. Such
>>>> conversions can be done there. Take a look and
to allow
>>> others to add post processing of the template once its been uploaded. Such
>>> conversions can be done there. Take a look and see if it suits your
>>> purposes.
>>>
>>> --Alex
>>>
>>> > -Original Message-
>>&g
rocessing of the template once its been uploaded. Such
>> conversions can be done there. Take a look and see if it suits your
>> purposes.
>>
>> --Alex
>>
>> > -Original Message-
>> > From: Marcus Sorensen [mailto:shadow...@gmail.com]
>>
gt; > Sent: Saturday, December 14, 2013 12:06 AM
> > To: dev@cloudstack.apache.org
> > Subject: Re: kvm - why just qcow2
> >
> > I suppose it would be best, and probably easiest, to accept templates in
> > vmdk, vdi, etc, but qemu-img convert to qcow2 during the
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 storag
your purposes.
--Alex
> -Original Message-
> From: Marcus Sorensen [mailto:shadow...@gmail.com]
> Sent: Saturday, December 14, 2013 12:06 AM
> To: dev@cloudstack.apache.org
> Subject: Re: kvm - why just qcow2
>
> I suppose it would be best, and probably easiest, to accep
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
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.
On
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 QemuImg.java was
written with other forma
15 matches
Mail list logo