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
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
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
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
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
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]
>>
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
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
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
;> 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
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
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
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
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
14 matches
Mail list logo
