cloudstack-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <>
Subject [GitHub] mike-tutkowski commented on issue #2298: CLOUDSTACK-9620: Enhancements for managed storage
Date Thu, 01 Jan 1970 00:00:00 GMT
mike-tutkowski commented on issue #2298: CLOUDSTACK-9620: Enhancements for managed storage
   @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 = and = '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 an SR/VDI UUID 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:

With regards,
Apache Git Services

View raw message