mike-tutkowski commented on issue #2298: CLOUDSTACK-9620: Enhancements for managed storage URL: https://github.com/apache/cloudstack/pull/2298#issuecomment-356746715 @rafaelweingartner Yeah, sorry if I wasn't clear about that back when we were looking at your PR. For XenServer + managed storage, there are two approaches to taking volume snapshots: 1) The volume snapshot resides on primary storage. 2) The volume snapshot goes through a SAN snapshot and ends up on secondary storage. In use case one, a snapshot is created on the SAN (fast and space efficient, but it's not technically a backup). To make use of it (i.e. to create a volume from a volume snapshot or a template from a volume snapshot) on XenServer, we can leverage UUID resigning (if the applicable XenServer service pack is installed). If UUID resigning is not available (because the service pack isn't installed), then we just perform a copy of the snapshot when creating a volume or a template from the snapshot. XenServer has a UUID for each SR and each VDI. You cannot mount two SRs or VDIs with the same UUID at the same time. If you're interested, here's a video of mine demoing this feature: https://www.youtube.com/watch?v=YQ3pBeL-WaA&index=13&list=PLqOXKM0Bt13DFnQnwUx8ZtJzoyDV0Uuye&t=1362s In any event, use case 2 allows you to temporarily use a SAN snapshot, but end up with a standard volume snapshot on secondary storage when all is said and done. It is this use case that is failing. I believe if you just look at the hypervisor type of the volume snapshot and pick any host in the applicable zone of the volume snapshot to perform the operation that all should be well.
---------------------------------------------------------------- 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
