mike-tutkowski commented on issue #2298: CLOUDSTACK-9620: Enhancements for managed storage URL: https://github.com/apache/cloudstack/pull/2298#issuecomment-356727735 @rhtyd @rafaelweingartner Let me provide a bit more background on this use case. 1) This only applies to XenServer (for the time being). 2) Normally when you create a volume snapshot on managed storage, it is simply stored on primary storage as a SAN snapshot. However, there is a second option when using managed storage with XenServer: You can temporarily create the volume snapshot as a SAN snapshot and then the SAN snapshot gets copied to secondary storage to remain on secondary storage like any other volume snapshot. This is called a SAN-assisted snapshot. The purpose is so we are not copying data from the virtual disk to secondary storage and having the host write new data to the virtual disk simultaneously as that can lead to performance issues. Instead, we take a SAN snapshot of the volume housing the virtual disk. We then mount the SAN snapshot and copy the hypervisor snapshot to secondary storage. The original VDI's performance is therefore not impacted during this process, but we still end up with a volume snapshot (albeit a full copy) on secondary storage. Now, let's say you then go to create a template from this volume snapshot. As we can see in my previous comment, the logic from that PR can't find a host to perform the copy from secondary storage to primary storage and, as such, the operation fails. I've looked in the cloud.storage_pool_host_ref table and there is, in fact, a reference for every host in my zone to my primary storage. Aside from this concern, I wonder what would happen (for managed or non-managed) storage if the storage pool the volume snapshot originated from was later removed. I think we would fail to find a host in that case, as well. Also, looking at HostDaoImpl.createSqlFindHostConnectedToStoragePoolToExecuteCommand, I see code that is not correct: if (storagePoolVO.isManaged()) { joinForManagedStorage = " join cluster_details cd on cd.cluster_id = c.id and cd.name = 'supportsResign' and cd.value = 'true' "; } It is not necessary to meet this restriction in this particular case. We only need to check this value if we want to perform a UUID/VDI resignature operation on XenServer (which we don't here).
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
