JoaoJandre commented on PR #8911: URL: https://github.com/apache/cloudstack/pull/8911#issuecomment-2165706362
Hi, @rohityadavcloud , @borisstoyanov , @weizhouapache > My 2-cents - we shouldn't break the design; migration to any storage shouldn't break linked-clone VMs. Nor any templates should be allowed to be removed which has any VMs (or VM/volume snapshots...). The current design is to consolidate the volume. In every case, except for NFS to NFS migration, the volume is consolidated. > Thanks @JoaoJandre, I got your point. I'm not sure about the space saving part, but I do believe the default behaviour should remain a proper link clone implementation, further as you identified it's already consolidating on other storage types, maybe we should look into fixing their cases to utilise link clone instead of consolidating and turning it into de facto full clone. The default behavior is to consolidate, NFS to NFS is the exception, which has no reason to exist. > to build a consensus, may I suggest we have this as alternative behaviour toggled by a global setting, with the idea that the default behaviour would refer to using link clones with backing files as a user would normally assume. Therefore it will serve both cases, since we don't want to assume how operators run their clouds. Creating this configuration would be change the default behavior for most cases. Furthermore, I'm against creating a configuration for this behavior as I don't see any real gains behind giving the user this option, 99% of users will not touch this configuration as it doesn't directly impact them in 99% of cases. Moreover, adding this configuration would add even more complexity to the code, whereas this PR is removing complexity. > I agree with @borisstoyanov full clone will not save space, especially there are many vms having the same base image. this is probably why vms are deployed with linked clone, not full clone. it should be good to have a global setting to let users to determine if linked clone or full clone the volume during vm migration. Bear in mind that this is only changing the migration, not creation of VMs. I agree that creating VMs with linked-clone saves space (and time!!) during creation. However, as I explained, it makes no sense to create VMs and then immediately move them to another storage (as a general procedure); thus, VMs that are migrated have been around for some time, enough that the original template is probably already overwritten. 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. > If linked clone is chosed, it is also feasible (I've done it some years ago) > > * copy the base image (template) from the original storage pool to new storage pool, if it is not present on the new pool > > * live-migrate the vm > > * change the base image of the volume after migration , by "qemu-img rebase -u -b " > > * just note the base image might be removed during vm migration by storage cleanup. be sure base image are not removed. Finally, if we are to change the behavior for most cases, I'd rather not introduce a configuration and make it so that the VMs are always migrated with linked clone. But again, this is not the current behavior for most cases, and is not beneficial in a lot of situations. [^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
