new 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 garbage collector found 1 templates to clean up in 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 ... 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 On Mon, 19 Nov 2018 at 19:11, Andrija Panic <andrija.pa...@gmail.com> wrote: > True (at least I'm sure for SolidFire) - but I believe in general also > (will test this now...) > > On Mon, 19 Nov 2018 at 18:51, Dag Sonstebo <dag.sonst...@shapeblue.com> > wrote: > >> Developers please correct me... but as far as I remember there is a >> garbage collector which does remove the templates from primary storage once >> they are not needed (i.e. have no more "child VMs"). This is controlled by >> the global setting "storage.template.cleanup.enabled". >> >> Regards, >> Dag Sonstebo >> Cloud Architect >> ShapeBlue >> >> >> On 16/11/2018, 22:51, "ran huang" <ran.huang...@gmail.com> wrote: >> >> Hi Andrija, >> >> Thanks for the clarification and quick response >> >> regards, >> Ran >> >> On 11/16/2018 02:15 PM, Andrija Panic wrote: >> > Hi Ran, >> > >> > templates stays on Primary Storage "forever", at least for NFS >> (they are >> > moved from Secondary to Primary when you deploy a very first VM from >> > specific template). All VMs have this templates qcow2 as baking >> (parent) >> > image. >> > >> > This template is a qcow2 copy of a file from Secondary Storage - >> and is >> > considered a "parent" image, from which all child images (VM >> volumes) are >> > created - as you stated baking file (qcow linked clones, in official >> > terminology) >> > >> > you can have i.e. 100 VMs all linking (having it's backing file...) >> to a >> > template qcow2 file. >> > So in other words, it's not supposed to be removed. >> > >> > Does this make sense? >> > >> > Cheers >> > >> > >> > >> >> dag.sonst...@shapeblue.com >> www.shapeblue.com >> Amadeus House, Floral Street, London WC2E 9DPUK >> @shapeblue >> >> >> >> > On Fri, 16 Nov 2018 at 22:38, ran huang <ran.huang...@gmail.com> wrote: >> > >> >> Greetings All, >> >> >> >> For qcow2 format images, when creating a new VM in KVM, the >> template >> >> image is copied from secondary storage to primary storage, and the >> root >> >> volume image is created with the template image as a backing file. >> >> >> >> But when I break this backing chain on primary(expunge VM or >> revert to a >> >> snapshot previously created on the root volume image), the template >> >> image is not deleted. >> >> >> >> Might I ask how is the template image going to be cleaned from the >> >> primary storage? >> >> >> >> >> >> addendum: >> >> CS ver 4.9.2 on CentOS 7.2 >> >> >> >> regards, >> >> Ran >> >> >> > >> >> >> >> > > -- > > Andrija Panić > -- Andrija Panić
