Hi Run,
not sure what you mean (I did not quite understand your explanation) - but
here is an exercise from my side (just done it):
Loading Image...
Check the image - explanation below:
Centos55 minimal (builtin) template, spin new VM:
--- new volume created with UUID/PATH (name on NFS files
system): 021e8602-235b-4e0d-b9e4-04f0ff46399f
--it's backing file: backing file:
/mnt/63a3ae7b-9ea9-3884-a772-1ea939ef6ec3/93682641-e7f6-11e8-8f64-089e01d943be
Create snapshots via GUI - there is qcow2 snapshots created, whole snapshot
copied over (converted via qemu-img - "ps aux | grep qemu-img") tool to
Secondary NFS Storage - and snapshot REMOVED from original volume on
Primary NFS Storage (qemu-img snapshot -l
021e8602-235b-4e0d-b9e4-04f0ff46399f shows zero snaps after ACS has
finished creating snapshots)
Volume still points to it's backing file - no changes so far (as expected)
Then I restore volume from snapshots.
CloudStack will (my conclusions from the exercise), remove original volume
on NFS Primary Storage (021e8602-235b-4e0d-b9e4-04f0ff46399f), then it will
copy back (convert via qemu-img) a qcow2 file from Secondary Storage back
to Primary Storage - but it will use SAME NAME, so you again see
021e8602-235b-4e0d-b9e4-04f0ff46399f on your NFS mount point.
This time when you check the image with qemu-img info - it will show it has
NO backing file at all - since it's brand new volume/qcow2 image created
(as a copy fom Secondary Storage)
that is how it works
I assume the template will be again cleaned-up/removed from Primary Storage
if no other VMs/volume use it as it's backing (parent) image.
Makes sense ?
Cheers
Post by ran huangThanks Andrija, just tested myself with expunge and works as expected.
However, for KVM, when I revert a qcow disk from snapshot, which removes
the backing chain to template, the template will not be removed.
So it seems like despite the qcow disk is no longer backed by the
template, the template will still consider the disk as its children in
this case(revert from snapshot).
regards,
Ran
Post by Andrija Panicnew template, deployed new VM, destroyed VM (with Exunge option)...
up to 120sec later... (storage.cleanup.interval=120 sec, global config
option)
2018-11-19 19:35:59,525 DEBUGStorage pool garbage collector found 1
templates to clean up in storage pool: Primary-storage - NFS
2018-11-19 19:35:59,525 DEBUG [c.c.s.StorageManagerImpl]
(StorageManager-Scavenger-1:ctx-2c88c8e0) (logid:040f4ad1) Storage pool
garbage collector has marked template with ID: 219 on pool 4 for garbage
collection
Another 120sec later... (storage.cleanup.delay=120sec)
2018-11-19 19:37:59,598 DEBUG [c.c.s.StorageManagerImpl]
(StorageManager-Scavenger-2:ctx-f9dd338d) (logid:9ae40975) Storage pool
Primary-storage - NFS
...
2018-11-19 19:37:59,638 DEBUG [c.c.t.TemplateManagerImpl]
(StorageManager-Scavenger-2:ctx-f9dd338d) (logid:9ae40975) Evicting
TmplPool[37-219-4-563ea0f5-5164-4ac4-a183-728f418269b7]
2018-11-19 19:37:59,643 DEBUG [c.c.h.o.r.Ovm3HypervisorGuru]
(StorageManager-Scavenger-2:ctx-f9dd338d) (logid:9ae40975)
getCommandHostDelegation: class
com.cloud.agent.api.storage.DestroyCommand
Post by Andrija Panic...
2018-11-19 19:37:59,665 DEBUG [c.c.t.TemplateManagerImpl]
(StorageManager-Scavenger-2:ctx-f9dd338d) (logid:9ae40975) Successfully
evicted template andrija-test-tmpl from storage pool null
template "andrija-test-tmpl" deleted...
Hope that helps Run.
Cheers
Andrija
Post by Andrija PanicTrue (at least I'm sure for SolidFire) - but I believe in general also
(will test this now...)
Post by Dag SonsteboDevelopers please correct me... but as far as I remember there is a
garbage collector which does remove the templates from primary storage
once
controlled by
Post by Andrija PanicPost by Andrija PanicPost by Dag Sonstebothe global setting "storage.template.cleanup.enabled".
Regards,
Dag Sonstebo
Cloud Architect
ShapeBlue
Hi Andrija,
Thanks for the clarification and quick response
regards,
Ran
Post by Andrija PanicHi Ran,
templates stays on Primary Storage "forever", at least for NFS
(they are
Post by Andrija Panicmoved from Secondary to Primary when you deploy a very first VM
from
Post by Andrija PanicPost by Andrija PanicPost by Dag SonsteboPost by Andrija Panicspecific template). All VMs have this templates qcow2 as baking
(parent)
Post by Andrija Panicimage.
This template is a qcow2 copy of a file from Secondary Storage -
and is
Post by Andrija Panicconsidered a "parent" image, from which all child images (VM
volumes) are
Post by Andrija Paniccreated - as you stated baking file (qcow linked clones, in
official
file...)
Post by Andrija PanicPost by Andrija PanicPost by Dag Sonsteboto a
Post by Andrija Panictemplate qcow2 file.
So in other words, it's not supposed to be removed.
Does this make sense?
Cheers
www.shapeblue.com
Amadeus House, Floral Street, London WC2E 9DPUK
@shapeblue
Post by Andrija PanicPost by ran huangGreetings All,
For qcow2 format images, when creating a new VM in KVM, the
template
Post by Andrija PanicPost by ran huangimage is copied from secondary storage to primary storage, and
the
file.
template
the
--
Andrija PaniÄ
