How to rename the hostid in a LSM controlled disk

[Joseph Luk]

Is a way to rename the hostid and the hostid part in the volumne ID in a LSM managed disk.

I had a diskgroup created by other host but I need to connect the whole disk group to other host. but when the system stary up it refust to use the disks " disk is unusable" also form the voldisk list output it is claim the status is "online alias" . If I use "vold -k -x noautoconfig" then "voldg -fC import diskgroup" then it work but every time I restart the system I need to do the same thing again. I guess if I can change the hostin in the disk it may fix this problem.

Thanks in adance.
Joseph

[Ralf Puchner]

Requirements and Prerequisites

· ALL devices in a given LSM must be cloned at the same time
o It is NOT supported to clone individual/selected LSM volumes for a
given LSM disk group
· volsave(8) must be run as part of every clone process
· Before running volrestore(8) on the target system the up-to-date information generated by volsave(8) must be copied from the source host to the target host
· Once the cloning and volsrestore(8) operation has been finished on the target host ALL filesystems must be verified using either
o verify(8) for AdvFS filesystems
o fsck(8) for UFS file

Supported only with 5.1A

[Joseph Luk]

Thanks for your information, However I am unable to run the volsave before hand as the system is totally dead!

Is any other way to force this change?

[Johan Brusche]

One of the possibilities is that the importing system already had a dskXX, and that this same diskname is present in the diskgroup to be imported.

If the hostid is the problem....Once you forced the import with voldg -fC, deport the group again an use "voldg deport -h newhostid".

Johan.

[Han Pilmeyer]

You can use the "voldisk clearimport" to clear the hostid from the disks.

The correct procedure to use Business Copies is actually through the "volclonedg" command (which uses volsave and volrestore under the hood).

If voldisk lists the disks as "alias", then that means that the WWID recorded in the disk meta data does not match the WWID of the LUN. volclonedg would take care of that situation, but you have to wonder how that happened in the first place.

Note that sys_check also does a "volsave". So if you ran sys_check recently, you may be able to revive the LSM configuration using that volsave information (possibly retrieved from a backup).