cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Makrand <makrandsa...@gmail.com>
Subject Mess after volume migration.
Date Mon, 08 Aug 2016 10:54:29 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message