Thanks 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
On 11/19/2018 10:43 AM, Andrija Panic wrote:
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ć
