| Return Code | Definition |
| 0x0000 | DG_SUCCESS |
| 0x0001 | DG_FAIL_NO_DG |
| 0x0002 | DG_FAIL_NO_DISK |
| 0x0003 | DG_FAIL_NO_MAJORITY |
| 0x0004 | DG_FAIL_START_RES |
| 0x0005 | DG_FAIL_STOP_RES |
| 0x0006 | DG_FAIL_STOP_THREAD |
| 0x0007 | DG_FAIL_IMPORT |
| 0x0008 | DG_FAIL_DEPORT |
| 0x0009 | DG_FAIL_DGNAME_EXISTED |
| 0x0010 | DG_FAIL_INVALID_DRIVE_LETTER |
| 0x0011 | DG_FAIL_NO_MEM |
| 0x0012 | DG_FAIL_UNEXPECTED |
| 0x0013 | DG_FAIL_INVALID_ARG |
| 0x0014 | DG_FAIL_INITIALIZE |
| 0x0015 | DG_FAIL_UNINITIALIZE |
| 0x0016 | DG_FAIL_VOL_LOCKED |
| 0x0017 | DG_FAIL_SHARING_VIOLATION |
| 0x0018 | DG_FAIL_VXIO_FAILURE |
| 0x0019 | DG_DEPORT_WITH_ACTIVE_IO |
| 0x0020 | DG_FAIL_REQ_RECOVERY |
| 0x0021 | DG_FAIL_NOT_CLUSTER_DG |
Import:
On import, the main codes seen are as follows:
0x0000 = Success
Import was successful
Example:
vxvm-OpLog: -- FINISH DGOP_IMPORT(2003) on veritas_cluster_service {e4be6aa0-cb41-4f12-8901-b6b5675d43f2}
vxvm-OpLog: -- Success(0)
0x0001 = No Diskgroup
This is mainly seen when the Diskgroup is imported on another node (and mainly with SCSI-2). Normally when this error is reported on an import, you can rescan in VEA and the Diskgroup will disappear (if SCSI-2) because the disks are reserved on another node. Since the passive nodes can still read the private region when SCSI-3 is being used, you normally don’t see this error with SCSI-3; instead, you will see the next error (0x0003).
Example:
vxvm-OpLog: -- FINISH DGOP_IMPORT(2001) on 39A-DG04 {36866b8a-82bb-416d-8416-9c60aa64d300}
vxvm-OpLog: -- Error(1) : Unknown
0x0003 = Unable to get SCSI Majority
In SFW, we must be able to reserve > 50% of the disks in a diskgroup. If we are unable to, we will report Error 3 in the log.
Example
vxvm-OpLog: -- FINISH DGOP_IMPORT(2003) on veritas_cluster_service {ff097cba-596f-40cf-8d67-f58b43763128}
vxvm-OpLog: -- Error(3) : Unknown
To further prove a reservation issue in this instance, try importing the Diskgroup as secondary, and if that works, it will prove a reservation issue and scsicmd can be used to investigate the reservation issue (Article: 100021389)
Deport:
On Deport, you will generally only see the following 3
0x0000 = Success
Deport was successful
Example:
vxvm-OpLog: -- FINISH DGOP_DEPORT(2003) on veritas_cluster_service {e4be6aa0-cb41-4f12-8901-b6b5675d43f2}
vxvm-OpLog: -- Success(0)
0x0001 = No Diskgroup
This is also seen on Deport when configured in a cluster. The Diskgroup will fail the import with Error 1, which result in an clean being called for the failed resource. This clean operation will call the deport, and since the Diskgroup is not seen on this server, it will fail with the same error:
Example:
vxvm-OpLog: -- FINISH DGOP_DEPORT(2001) on 39A-DG04 {36866b8a-82bb-416d-8416-9c60aa64d300}
vxvm-OpLog: -- Error(1) : Unknown
0x0019 = Deported with Active I/O
This is still a successful deport, but is indicating that the Diskgroup was deported with Active I/O. If the Active I/O are writes to disk, this could cause corruption. Normally it’s good to look for these on cases where a customer encounters file system corruption after performing a failover of a Diskgroup/volume.
vxvm-OpLog: -- FINISH DGOP_DEPORT(2001) on 39A-DG01 {811d62da-9537-46f5-a6ff-e581283e61cc}
vxvm-OpLog: -- Error(19) : Unknown
This article contains a list of possible return codes that may occur while importing and deporting disk groups in Storage Foundation for Windows (SFW).