weizhouapache commented on PR #8911:
URL: https://github.com/apache/cloudstack/pull/8911#issuecomment-2165779806

   > 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
   
   
   If you ensure that linked-clone is used between NFS/local and NFS/local vm 
migration, it looks good to me that volume is consolidated in other cases. Can 
you confirm?
   
   


-- 
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

Reply via email to