If you use truecopy or similar storage cloning methods ...
You have situation that source VG and destination VG have the same LVM id (that's why vgimport will fail), and the disks are presented on all nodes of SG.
Because of the same LVM id, HPUX will not import, but will warn you there are same ID's on multiple sets of disk.
That's where vgchgid comes into play, allowing you to have 'same/cloned' volume group on any of the SG cluster member.
So you clone the disks via storage method, then vgexport the cloned volume group, change the LVM ID and import.
If you just want to extend the SG clustered volume group with new luns (your case), you just extend on the node where the package is (as you did), export preview of that volume group ( -p -m -s switches, easy to remember , then on secondary node you make vgexport of that group (plain and simple no switches),mknod, vgimport using map file from primary node.
If you are adding additional LVOLS you will need to modify the /etc/cmcluster/package/package.sh script (where package is the name of the package you are modifying).
If those luns were used on any of the cluster nodes before the above action (extending on the primary node), you will need to run pvremove on every node for specifed disk(s) (to remove LVM information).
Hi,
I am working on device drivers.Once If register a device i'll get one major no. If i unregister and register again i'll get a different major no.What i have to do to get same major no. each time :( (0 Replies)
Hello, I have 2 hp-ux both running 11.23, I have move one of a harddisk from "UNIX A" to "UNIX B", so how can I read back the data in "UNIX B"?
Thanks (5 Replies)
I have a list of LUN ID, my task is to find if disk has been added or not. How do I do that? I have been searching the forum and not able to find answer.
thanks (4 Replies)
Hi.
I have these two variables:
My objective here is to reuse that $file_name variable again and again by resetting the $cv value.
for example, if i reissue the cv="$(print 'CV01')" command, thus $file_name is now should be "CP99978_CV01.TXT", not "CP99978_CV01.TXT" anymore.
How I'm... (7 Replies)
I'm currently using zsh. Sometimes I find myself wishing to reuse an argument from earlier in the command.
I know that I can, of course, assign an argument to a variable ahead of time, and then easily use that variable more than once.
I know about the ability to reuse arguments from previous... (0 Replies)
Hello everyone.
I'm trying to create a conf file with variables that my other scripts will use.
I have several scripts that use the same variables, and since I don't know how to read them from an external file, i define them in each script (and then if i want to change one's value i need to... (4 Replies)
Hi
I am trying to write a shell script and wanted to re-use the value which I have entered already.
Here is the sample code.
echo "Enter Value : \c" ; read val
echo "Enter number: $val\c" ; read num
Now I wanted to change the value as showing in 2nd Line or if I will use enter, it... (15 Replies)
I have a collection of format strings for sscanf, such as
"%02d%*1s%02d%*1s%02d"
to read in certain formatted strings, such as dates, times, etc.
I wonder if there is a way to use them in printf without some changes? The example above would not work - at least I can't think of any ways to... (4 Replies)
Discussion started by: migurus
4 Replies
LEARN ABOUT HPUX
vgmove
vgmove(1M)vgmove(1M)NAME
vgmove - move data from an old set of disks in a volume group to a new set of disks
SYNOPSIS
autobackup] diskmapfile vg_name
autobackup] diskfile diskmapfile vg_name
DESCRIPTION
The command migrates data from the existing set of disks in a volume group to a new set of disks. After the command completes successfully,
the new set of disks will belong to the same volume group. The command is intended to migrate data on a volume group from old storage to
new storage. The diskmapfile specifies the list of source disks to move data from, and the list of destination disks to move data to. The
user may choose to list only a subset of the existing physical volumes in the volume group that need to be migrated to a new set of disks.
The format of the diskmapfile file is shown below:
source_pv_1 destination_pv_1_1 destination_pv_1_2 ....
source_pv_2 destination_pv_2_1 destination_pv_2_2 ....
....
source_pv_n destination_pv_n_1 destination_pv_n_2 ....
If a destination disk is not already part of the volume group, it will be added using see vgextend(1M). Upon successful completion of the
source disk will be automatically removed from the volume group using see vgreduce(1M).
After successful migration, the destination disks are added to the LVM configuration files; namely, or The source disks along with their
alternate links are removed from the LVM configuration files.
A sample diskmapfile is shown below:
/dev/disk/disk1 /dev/disk/disk51 /dev/disk/disk52
/dev/disk/disk2 /dev/disk/disk51
/dev/disk/disk3 /dev/disk/disk53
The diskmapfile can be manually created, or it can be automatically generated using the diskfile and diskmapfile options. The argument
diskfile contains a list of destination disks, one per line such as the sample file below:
/dev/disk/disk51
/dev/disk/disk52
/dev/disk/disk53
When the option is given, reads a list of destination disks from diskfile, generates the source to destination mapping, and saves it to
diskmapfile.
The volume group must be activated before running the command. If the command is interrupted before it completes, the volume group is in
the same state it was at the beginning of the command. The migration can be continued by running the command with the same options and
disk mapping file.
Options and Arguments
The command recognizes the following options and arguments:
vg_name The path name of the volume group.
Set automatic backup for this invocation of
autobackup can have one of the following values:
Automatically back up configuration changes made to the volume group.
This is the default.
After this command executes, the command is executed for the volume group; see vgcfgbackup(1M).
Do not back up configuration changes this time.
Specify the name of the file containing the
source to destination disk mapping. If the option is also given, will generate the disk mapping and save it to
this filename. (Note that if the diskmapfile already exists, the file will be overwritten). Otherwise, will
perform the data migration using this diskmapfile.
Specify the name of the file containing the
list of destination disks. This option is used with the option to generate the diskmapfile.
When the option is used, no volume group data is moved.
Preview the actions to be taken but do not
move any volume group data.
Shared Volume Group Considerations
For volume group version 1.0 and 2.0, cannot be used if the volume group is activated in shared mode. For volume groups version 2.1 (or
higher), can be performed when activated in either shared, exclusive, or standalone mode.
Note that the daemon must be running on all the nodes sharing a volume group activated in shared mode. See lvmpud(1M).
When a node wants to share the volume group, the user must first execute a if physical volumes were moved in or out of the volume group at
the time the volume group was not activated on that node.
LVM shared mode is currently only available in Serviceguard clusters.
EXTERNAL INFLUENCES
Environment Variables
determines the language in which messages are displayed.
If is not specified or is null, it defaults to "C" (see lang(5)).
If any internationalization variable contains an invalid setting, all internationalization variables default to "C" (see environ(5)).
EXAMPLES
Move data in volume group from to After the migration, remove from the volume group:
Generate a source to destination disk map file for where the destination disks are and
SEE ALSO lvmpud(1M), pvmove(1M), vgcfgbackup(1M), vgcfgrestore(1M), vgextend(1M), vgreduce(1M), intro(7), lvm(7).
vgmove(1M)
08-22-2012
, then on secondary node you make vgexport of that group (plain and simple no switches),mknod, vgimport using map file from primary node.