Guys, My setup:- ACS 4.4.2. Hypervisor: XENserver 6.2.
I tried moving a volume in running VM from primary storage A to primary storage B (using GUI of cloudstack). Please note, primary storage A LUN (LUN7)is coming out of one storage box and primary storage B LUN (LUN14) is from another. For VM1 with 250GB data volume (51 GB used space), I was able to move this volume without any glitch in about 26mins. But for VM2 with 250Gb data volume (182 GB used space), the migration continued for about ~110 mins and then failed with follwing exception in very end with message like:- 2016-08-06 14:30:57,481 WARN [c.c.h.x.r.CitrixResourceBase] (DirectAgent-192:ctx-5716ad6d) Task failed! Task record: uuid: 308a8326-2622-e4c5-2019-3beb 87b0d183 nameLabel: Async.VDI.pool_migrate nameDescription: allowedOperations: [] currentOperations: {} created: Sat Aug 06 12:36:27 UTC 2016 finished: Sat Aug 06 14:30:32 UTC 2016 status: failure residentOn: com.xensource.xenapi.Host@f242d3ca progress: 1.0 type: <none/> result: errorInfo: [SR_BACKEND_FAILURE_80, , Failed to mark VDI hidden [opterr=SR 96e879bf-93aa-47ca-e2d5-e595afbab294: error aborting existing process]] otherConfig: {} subtaskOf: com.xensource.xenapi.Task@aaf13f6f subtasks: [] So cloudstack just removed the JOB telling it failed, says the mangement server log. A) But when I am checking it at hyeprvisor level, the volume is on new SR i.e. on LUN14. Strange huh? So now the new uuid for this volume from XE cli is like [root@gcx-bom-compute1 ~]# xe vbd-list vm-uuid=3fcb3070-e373-3cf9-d0aa-0a657142a38d uuid ( RO) : f15dc54a-3868-8de8-5427-314e341879c6 vm-uuid ( RO): 3fcb3070-e373-3cf9-d0aa-0a657142a38d vm-name-label ( RO): i-22-803-VM vdi-uuid ( RO): cc1f8e83-f224-44b7-9359-282a1c1e3db1 empty ( RO): false device ( RO): hdb B) But luckily I had the entry taken before migration and it shows like:- uuid ( RO) : f15dc54a-3868-8de8-5427-314e341879c6 vm-uuid ( RO): 3fcb3070-e373-3cf9-d0aa-0a657142a38d vm-name-label ( RO): i-22-803-VM vdi-uuid ( RO): 7c073522-a077-41a0-b9a7-7b61847d413b empty ( RO): false device ( RO): hdb C) Since this failed at cloudstack, the DB is still holding old value. Here is current volume table entry in DB id: 1004 > account_id: 22 > domain_id: 15 > pool_id: 18 > last_pool_id: NULL > instance_id: 803 > device_id: 1 > name: > cloudx_globalcloudxchange_com_W2797T2808S3112_V1462960751 > uuid: a8f01042-d0de-4496-98fa-a0b13648bef7 > size: 268435456000 > folder: NULL > path: 7c073522-a077-41a0-b9a7-7b61847d413b > pod_id: NULL > data_center_id: 2 > iscsi_name: NULL > host_ip: NULL > volume_type: DATADISK > pool_type: NULL > disk_offering_id: 6 > template_id: NULL > first_snapshot_backup_uuid: NULL > recreatable: 0 > created: 2016-05-11 09:59:12 > attached: 2016-05-11 09:59:21 > updated: 2016-08-06 14:30:57 > removed: NULL > state: Ready > chain_info: NULL > update_count: 42 > disk_type: NULL > vm_snapshot_chain_size: NULL > iso_id: NULL > display_volume: 1 > format: VHD > min_iops: NULL > max_iops: NULL > hv_ss_reserve: 0 > 1 row in set (0.00 sec) > So the path variable shows value as 7c073522-a077-41a0-b9a7-7b61847d413b and pool id as 18. The VM is running as of now, but I am sure the moment I will reboot, this volume will be gone or worst VM won't boot. This is production VM BTW. D) So I think I need to edit volume table for path and pool_id parameters and need to place new values in place and then reboot VM. Do I need to make any more changes in DB in some other tables for same? Any comment/help is much appreciated. -- Best, Makrand