rootdg restoring

[yosyp]

I have two-nodes OPS cluster. First I create a new LUN and VG at the external Disk Array. Later I delete this LUN but don't delete VG. Probably it was my mistake. During starting of VxVM restore daemon I have such error on the 1-st Node:
===============================================
VxVM starting in boot mode...
NOTICE: vxvm:vxdmp: added disk array 00SG247J0116, datype = VA7400

NOTICE: vxvm:vxdmp: added disk array 00SG247J0050, datype = VA7400
vxvm:vxconfigd: ERROR: enable failed: Error in disk group configuration copies
Disk group has no valid configuration copies; transactions are disabled.
vxvm:vxconfigd: FATAL ERROR: Rootdg cannot be imported during boot
vxvm:vxconfigd: ERROR: enable failed: Error in disk group configuration copies
Disk group has no valid configuration copies; transactions are disabled.
vxvm: Vold is not enabled for transactions
No volumes started
===============================================
Are you know way how to restore (rebuild) rootdg VG on the 1-st Node? Rootdg is at the LUN of VA and I have not its backup.
2-nd Node of cluster is healthy.

[Prashanth.D.S]

Hi,

I would suggest you to check the Rootdg permissions



The VxVM rootdg disk group must be present in order for the VxVM vxconfigd(1M)
process to run. When you install VxVM on an HP-UX 11i system, rootdg is created.
You cannot access any VxVM objects without rootdg and the vxconfigd process.

If rootdg fails, the vxconfigd(1M) process is disabled, and no configuration
changes can be made to any VxVM disk group on the system. When the system is
rebooted, the vxconfigd(1M) daemon will be disabled because of the rootdg
failure.

Use the following procedure to recover from a VxVM 3.1 rootdg failure on an
HP-UX 11i system:

1. Check the state of vxconfigd as follows:

# vxdctl mode

Output:

mode: disabled

2. Re-initialize the rootdg disk group as follows:

# vxdg init rootdg

3. Check to be sure that rootdg is enabled:

# vxdg list

Output is similar to:

NAME STATE ID
rootdg enabled 977341694.1040.chsd350b

4. Determine which system disks are not under VxVM control. Disks that are
not under VxVM or LVM control have a status of "online invalid":

# vxdisk list

Output is similar to:

DEVICE TYPE DISK GROUP STATUS
c0t5d0 simple - - LVM
c0t8d0 simple - - LVM
c0t9d0 simple - - online invalid
c010d0 simple - - online
c0t11d0 simple - - online

Note that c0t9d0 has an "online invalid" status--this indicates that the disk is
not controlled by VxVM or LVM.

5. List information about disk c0t9d0 as follows:

# vxdisk list c0t9d0

Output does not show any VxVM data, as follows:

Device: c0t9d0
devicetag: c0t9d0
type: simple
flags: online ready private autoconfig invalid
pubpaths: block=/dev/vx/dmp/c0t9d0 char==/dev/vx/rdmp/c0t9d0
Multipathing information:
numpaths: 1
c0t9d0 state=enabled

6. Re-initialize the invalid disk:

# vxdisksetup -i c0t9d0

7. Add the disk to rootdg:

# vxdg adddisk c0t9d0

No disk group name is specified; by default, the disk goes into rootdg.

8. Display disk information again:

# vxdisk list

Output is similar to:

DEVICE TYPE DISK GROUP STATUS
c0t5d0 simple - - LVM
c0t8d0 simple - - LVM
c0t9d0 simple c0t9d0 rootdg online
c0t10d0 simple - - online
c0t11d0 simple - - online

Note that c0t9d0 is now online and in the rootdg disk group.

9. List information about disk c0t9d0:

# vxdisk list c0t9d0

Output now includes VxVM data and is similar to:

Device: c0t9d0
devicetag: c0t9d0
type: simple
hostid: chsd350b
disk: name=c0t9d0 id=977343788.1041.chsd350b
timeout: 30
group: name=rootdg id=977343728.1040.chsd350b
info: privoffset=128
flags: online ready private autoconfig autoimport imported
pubpaths: block=/dev/vx/dmp/c0t9d0 char=/dev/vx/rdmp/c0t9d0
version: 2.1
iosize: min=1024 (bytes) max=64 (blocks)
public: slice=0 offset=1152 len=2081484
private: slice=0 offset=128 len=1024
update: time=977343799 seqno=0.5
headers: 0 248
configs: count=1 len=727
logs: count=1 len=110
Defined regions:
config priv 000017-000247[000231]: copy=01 offset=000000 enabled
config priv 000249-000744[000496]: copy=01 offset=000231 enabled
log priv 000745-000854[000110]: copy=01 offset=000000 enabled
lockrgn priv 000855-000919[000065]: part=00 offset=000000
Multipathing information:
numpaths: 1
c0t9d0 state=enabled

10. Restart vxconfigd:

# vxdctl enable

11. Other existing VxVM disk groups are then imported automatically. You can
check as follows:

# vxdg list

Output will be similar to:

NAME STATE ID
rootdg enabled 977343728.1040.chsd350b
newname enabled 976303103.1068.chsd350b

12. Restore the rootdg configuration to the disk group in order to access
objects that were present before rootdg failed.

NOTE: When rootdg is re-created, it has no objects, such as volumes or subdisks.
To restore the previous rootdg configuration, you can use one of the following
commands:

dgcfgrestore(1M) -- Restores configuration data to a disk that is in a
single-disk disk group or in a multiple-disk group where no other disks
have a copy of the configuration data.

vxdg(1M) with the adddisk option -- Add a disk to a multiple-disk group
where other disks in the group have a copy of the disk group
configuration. The disk being added must not belong to an existing disk
group.


Best Regards,
Prashanth