cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan Rodriguez <ivan...@gmail.com>
Subject Re: KVM cloudstack createnewvm
Date Tue, 19 Aug 2014 04:45:46 GMT
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 <creategui@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 <ivanoch@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
>
>

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