JoaoJandre commented on PR #8911:
URL: https://github.com/apache/cloudstack/pull/8911#issuecomment-2162865871
> Hi @JoaoJandre, thanks for this suggestion.
>
> if we consolidate all link clone created VMs after migration, wouldn't
that create a massive overhead in storage as they will be all merged with the
template file? Sorry, maybe I'm not understanding this right, but here's my
thinking.
>
> If our storage pool is looking something like this:
>
> ```
> {template}{VM1}
> --{VM2}
> --{VM3}
> --{VM4}
> ```
>
> the physical size of the pool would be `{template} + 4 {vms}`. If we
consolidate all we'll endup with `4x template `existing on the storage? or
something like this:
>
> ```
> {template+VM1}
> {template+VM2}
> {template+VM3}
> {template+VM4}
> ```
>
> Please let me know if I misunderstood.
Hey @borisstoyanov,
Out of context, you are correct, if we create lots of small VMs with big
templates and migrate them, there will be lots of copies of the template after
migration. However, I find that this is usually not how operators run their
clouds. In most cases, operators only migrate VMs after quite some time after
creation, enough time that the template might have been completely overwritten,
in this case, consolidating the volume would not increase storage usage.
Furthermore, when using `qemu-img convert`, qemu will optimize storage usage
while doing the convert (empty sectors are detected and suppressed from the
destination image[^qemu-convert]), so this process might save us storage space.
Another point to consider is that for decently sized VMs (500GB+), a template
is usually around 1% or 2% of the VM's storage space, almost a rounding error.
As one last point, the proposed process is much more simple and less prone to
bugs.
[^qemu-convert]:https://qemu-project.gitlab.io/qemu/tools/qemu-img.html
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@cloudstack.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
