rootdg disk device filenames changing

[Unix Team]

Hi All
We are moving a superdome partition from one cab to a cab in another complex, different cell boards. Hence the hardware paths on all hardware will change.

The partition boots from a disk in the VxVM rootdg. We have performed a number of moves like this with partitions that boot from a disk in LVM VG00 - booting into maintenance mode and then reinstancing using ioconfig.

However how do we perform a similar thing if the server boots from rootdg, and we cannot therefore enter hpux maintenance mode. We basically just need to access / so that we can feed an already created infile into ionit to re-instance the system.

Any help greatly appreciated.

[IT_2007]

It would be easier if you want to restore rootdg in the hardware move. All you have to do is vxdg with export options. See man page for vxdg.

A disk group can be renamed on deport by specifying a new
disk group name with -n newname. A lock can be assigned to
an alternate host by specifying the host ID (see vxdctl(1M))
of the alternate host. This allows the disk group to be
auto-imported when the alternate host reboots. For example,
the -n and -h options can be combined to export a disk group
to be used as the rootdg disk group for a new machine.

[IT_2007]

Here is the commands you can use it:

on the existing server:

vxdg -n rootdg.new deport rootdg

copy rootdg.new file to some other server as backup. Keep this file on the same server at / level so that you can import after hardware move.

Move hardware and the bring it up in single user mode and issue:

vxdg -n rootdg.new import rootdg

[Unix Team]

Hi IT_2007
If we bring up the server in single user mode, in order to execute a vxdg command, doesn't it mean that VxVM has already located the rootdg disks and enabled that disk group? In which case there is no need to import it...

What we are concerned with is that following the hardware move, since the rootdg disk device filenames will have changed, VxVM will not be able to locate and enable rootdg. Am I correct in assuming that this is how VxVM will behave?

[IT_2007]

No. Once you search for IPL at BCH and you would know what hardware path was supposed to be for primary and alternate rootdg disks. Boot into single user mode and then use /sbin/vxdg command to import rootdg.

[Alzhy]

VxVM rootdg as well as other VxVM DGs have no dependency on cXtYdZ names. This is the beauty of VxVM over LVM. I don't even believe you will need a re-instancing with VxVM. As long as VxVM sees all component disks for a diskgroup as present, it will import and activate the diskgroup.

[IT_2007]

quick note that you need to use -t option on the runnng system for deport.

vxdisk list
This command results in output that includes the following.


dgname: rootdg dgid: 774226267.1025.tweety

On the importing host, import and rename the rootdg disk group with this command:


# vxdg -tC -n newdg_name import diskgroup


where -t indicates a temporary import name; C clears import locks; -n specifies a temporary name for the rootdg to be imported (so it does not conflict with the existing rootdg); and diskgroup is the disk group ID of the disk group being imported (for example, 774226267.1025.tweety).

If a reboot or crash occurs at this point, the temporarily imported disk group becomes unimported and requires a reimport.

After the necessary work has been done on the imported rootdg, deport it back to its original host with this command:


# vxdg -h hostname deport diskgroup


where hostname is the name of the system whose rootdg is being returned (the system name can be confirmed with the command uname -n).

This command removes the imported rootdg from the importing host and returns locks to its original host. The original host then autoimports its rootdg on the next reboot.