Dec 2 17:41:52 systemA vxvm:vxconfigd[50357]: V-5-1-16253 Disk group import of nbudg failed with error 373 - SCSI-3 PR operation failed
Dec 2 17:41:52 systemA AgentFramework[90146]: VCS ERROR V-16-10031-1503 DiskGroup:VVR_dg:online:** ERROR: vxdg import (force) failed on Disk Group nbudg.
Dec 2 17:41:55 systemA vxvm:vxconfigd[50357]: V-5-1-0 dg_name_to_dgid: Found dgid = 1606921216.15.systemA
Dec 2 17:41:55 systemA1 vxvm:vxconfigd[50357]: V-5-1-11401 : dg import with I/O fence enabled
Dec 2 17:41:55 systemA vxvm:vxconfigd[50357]: V-5-1-11401 nbudg: dg import with I/O fence enabled
Dec 2 17:41:55 systemA vxvm:vxconfigd[50357]: V-5-1-18406 Disk 'sdb' does not support SCSI-3 PR, skipping PGR operations for this disk.
Dec 2 17:41:55 systemA vxvm:vxconfigd[50357]: V-5-1-18406 Disk 'sdc' does not support SCSI-3 PR, skipping PGR operations for this disk.
Dec 2 17:41:55 systemA vxvm:vxconfigd[50357]: V-5-1-18406 Disk 'sdd' does not support SCSI-3 PR, skipping PGR operations for this disk.
Dec 2 17:41:55 systemA vxvm:vxconfigd[50357]: V-5-1-16253 Disk group import of nbudg failed with error 373 - SCSI-3 PR operation failed
Dec 2 17:41:55 systemA AgentFramework[90146]: VCS ERROR V-16-10031-1504 DiskGroup:VVR_dg:online:** ERROR: vxdg import failed on Disk Group nbudg after vxdctl enable.
It turned out that when fencing was being configured, disk-based fencing was accidentally chosen although CP servers were being used. So whilst the cluster configuration was only showing CP servers in the fencing configuration and the CP servers were reachable, VCS still seemed to think that SCSI3 disks were being used.
After re-configuring fencing and this time answering 'no' to using SCSI3 disks, everything worked fine.