You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cloudstack.apache.org by Ivan Rodriguez <iv...@gmail.com> on 2014/08/19 03:14:54 UTC
KVM cloudstack createnewvm
Hi there,
One of our templates in secondary storage needs some minor changes,
I was able to track down the path from the secondary storage getting the
reference from
vm_template (unique_name)
Then look for the template id on the properties
find . -name "*.properties" -exec grep -il
"2d1f46882-755a-3239-a9b8-019eca89e86b" {} \;
I believe I have the right qcow2 image when I open it up with guestfish
I can see that is actually my template so I do my changes save the image
then provision a new vm from that template and my changues are not there so
I'm wondering if cloudstack is copying the template from secondary storage
into primary storage for fast provisioning.
Later on I bump into the script createvm.sh which is basically using
qemu-img to create the new root disk I've been checking this process and I
can't figure out who is actually provisioning the new root disk.
I don't think is the secondary storage since it doesn't look like its
mounting primary storage, and also on the compute hypervisor side
it doesn't look like its mounting the secondary storage to copy the
template.
Any advise will be really appreciate it.
Also is there a place where internal process for cloudstack are explained ?
or you gotta jump in the source code and try to figure it out ?
Pd. I know I can destroy the template and upload it again with the changes
but it would be nice if I can understand the cloudstack process.
Thanks in advance
Ivan
Re: KVM cloudstack createnewvm
Posted by Ivan Rodriguez <iv...@gmail.com>.
Hi Carlos,
Thanks for your help, I can confirm the same with kvm and qcow2 the
template is copied from secondary storage to primary storage and all the
vm's deployed using that template are incremental from the original
# qemu-img info ./70142163-1082-4cf2-836f-97ea52629e34
image: ./70142163-1082-4cf2-836f-97ea52629e34
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 18G
cluster_size: 65536
backing file:
/mnt/5ffe8656-f987-3fcb-b71d-7dd1ed19e839/1c7c6f89-8fee-44d9-bfb0-39396cf5f548
Also the table involved for this id is template_spool_ref and vm_template
has the reference to the template name on the primary storage
select tr.local_path, tr.install_path, vt.name, vt.id, vt.display_text,
vt.unique_name,vt.uuid from vm_template as vt, template_spool_ref as tr
where vt.name like '%MYTEMNAME%' and tr.template_id = vt.id;
Moreover you can't do online changes on the template image.
Cheers
On Tue, Aug 19, 2014 at 1:31 PM, Carlos Reátegui <cr...@gmail.com>
wrote:
> I’m not familiar with KVM, but on XenServer with NFS shared storage what I
> see is the following which may explain what you are seeing.
>
> When I first use a template it is copied over from secondary to primary
> and the root disk for my new instance is created as a differencing VHD
> pointing to the template copy as the parent. All other instances that use
> that same template will simply create new child VHD files pointing to the
> original parent VHD.
>
> Assuming qcow2 files in CS with KVM are used in the same way, I think this
> may explain what you are seeing.
>
> With VHDs I can use the vhd-util command to scan files and see the parent
> child relationships. With qcow2 files give "qemu-img info" a try to see if
> it will give you similar info on the files in your primary store.
>
> Cheers,
> -Carlos
>
> On Aug 18, 2014, at 6:14 PM, Ivan Rodriguez <iv...@gmail.com> wrote:
>
> > Hi there,
> >
> >
> > One of our templates in secondary storage needs some minor changes,
> > I was able to track down the path from the secondary storage getting the
> > reference from
> > vm_template (unique_name)
> >
> >
> > Then look for the template id on the properties
> >
> > find . -name "*.properties" -exec grep -il
> > "2d1f46882-755a-3239-a9b8-019eca89e86b" {} \;
> >
> > I believe I have the right qcow2 image when I open it up with guestfish
> > I can see that is actually my template so I do my changes save the image
> > then provision a new vm from that template and my changues are not there
> so
> > I'm wondering if cloudstack is copying the template from secondary
> storage
> > into primary storage for fast provisioning.
> >
> >
> > Later on I bump into the script createvm.sh which is basically using
> > qemu-img to create the new root disk I've been checking this process and
> I
> > can't figure out who is actually provisioning the new root disk.
> >
> > I don't think is the secondary storage since it doesn't look like its
> > mounting primary storage, and also on the compute hypervisor side
> > it doesn't look like its mounting the secondary storage to copy the
> > template.
> >
> > Any advise will be really appreciate it.
> >
> > Also is there a place where internal process for cloudstack are
> explained ?
> > or you gotta jump in the source code and try to figure it out ?
> >
> > Pd. I know I can destroy the template and upload it again with the
> changes
> > but it would be nice if I can understand the cloudstack process.
> >
> >
> > Thanks in advance
> > Ivan
>
>
Re: KVM cloudstack createnewvm
Posted by Carlos Reátegui <cr...@gmail.com>.
I’m not familiar with KVM, but on XenServer with NFS shared storage what I see is the following which may explain what you are seeing.
When I first use a template it is copied over from secondary to primary and the root disk for my new instance is created as a differencing VHD pointing to the template copy as the parent. All other instances that use that same template will simply create new child VHD files pointing to the original parent VHD.
Assuming qcow2 files in CS with KVM are used in the same way, I think this may explain what you are seeing.
With VHDs I can use the vhd-util command to scan files and see the parent child relationships. With qcow2 files give "qemu-img info" a try to see if it will give you similar info on the files in your primary store.
Cheers,
-Carlos
On Aug 18, 2014, at 6:14 PM, Ivan Rodriguez <iv...@gmail.com> wrote:
> Hi there,
>
>
> One of our templates in secondary storage needs some minor changes,
> I was able to track down the path from the secondary storage getting the
> reference from
> vm_template (unique_name)
>
>
> Then look for the template id on the properties
>
> find . -name "*.properties" -exec grep -il
> "2d1f46882-755a-3239-a9b8-019eca89e86b" {} \;
>
> I believe I have the right qcow2 image when I open it up with guestfish
> I can see that is actually my template so I do my changes save the image
> then provision a new vm from that template and my changues are not there so
> I'm wondering if cloudstack is copying the template from secondary storage
> into primary storage for fast provisioning.
>
>
> Later on I bump into the script createvm.sh which is basically using
> qemu-img to create the new root disk I've been checking this process and I
> can't figure out who is actually provisioning the new root disk.
>
> I don't think is the secondary storage since it doesn't look like its
> mounting primary storage, and also on the compute hypervisor side
> it doesn't look like its mounting the secondary storage to copy the
> template.
>
> Any advise will be really appreciate it.
>
> Also is there a place where internal process for cloudstack are explained ?
> or you gotta jump in the source code and try to figure it out ?
>
> Pd. I know I can destroy the template and upload it again with the changes
> but it would be nice if I can understand the cloudstack process.
>
>
> Thanks in advance
> Ivan