Move VG to other node.

[RAC_1]

Setup - 11.11, L class-2 nos-say A & B.

I would like to move one VG from server A
to machine B. VG is from VA7400.
VG name will change on other node.
It is vg05 on server A, it will be vg09 on server B.

(No use of MCSG)

This is what I can think of--

1. vgexport -pvm /tmp/vg05.map vg05.

2. Vgreduce all pvs, vgchange -a n vg05 and then vgexport vg05- On server A.

3. Put file vg05.map on server B.

4. Check device files for vg05.-i.e device files as seen from server B. It may be on different controller.

5. mkdir /dev/vg09

6. mknod /dev/vg09/group c 64 0x090000

7. vgimport -v -m /tmp/vg05.map vg09 all_pvs

Is this OK? Any other way to do this?

Give details please.

Thanks in Advance.

[Steven E. Protter]

vgexport
vgimport

Is the accepted way of moving volume groups between systems on disk that are shared.

Assuming all the logical volumes are filesystems, you could also use fbackup to create a tape to move everything.

You method looks easier, but obviously, anyone that knows me knows I wouldn't conduct such an operation without a few backups in my back pocket.

SEP

[Michael Tully]

Hi I would generate the map files a little differently:

# vgexport -m /tmp/vg05.map -p -v -s /dev/vg05
# vgchange -a n /dev/05

On the new server B

# mkdir /dev/vg09
# mknod /dev/vg09/group c 64 0x0X0000 (assign the next available number)
# vgimport -v -m /tmp/vg05 -p -s /dev/vg09
if okay
# vgimport -v -m /tmp/vg05 -s /dev/vg09

Using the -s (shared) the VGID will be in the mapfile. So when you run the import the VGID is used to scan the hardware and will find the right disk devices to be used.

Once everything comes up run:
# vgchange -a y /dev/vg09

If you intend to mount filesystems on them you need to 'fcsk' each one.
Create the necessary mount point directories.
# mount .....
update /etc/fstab

Back to server A and vgexport the volume group
# vgexport /dev/vg05

[twang]

I did it before, steps for your reference:
On node A :

# vgexport -p -s -m /tmp/vg03.map /dev/vg03
# rcp /tmp/vg03.map nodeB:/tmp

On node B :
# mkdir /dev/vg03
# mknod /dev/vg03/group c 64 0x060000
# vgimport -s -m /tmp/vg03.map /dev/vg03

[James Murtagh]

Hi Anil,

Step 2 is wrong - you don't want to remove any pvs from the volume group. You wouldn't be able to do this anyway without removing all the lvols. Just deactivate and vgexport it. Other that this it should be fine. Just remember to remove the filesystem definitions in /etc/fstab from the server you are removing the vg from and vice versa for the new server.

cheers,

James.

[RAC_1]

Thanks SEP and Michal,

vgchange -s --> sharable options is only for SG. I do not want to make use of that, rather I can not.

I am talking abt VG export to other node without SG, without having same device files and same VG name on other node.

If I remember correctly, if vg name is to be same on other node and device files are also same-i.e coming from same controller then it is possible.

But my situation is different.

Please advise. Though I doubt this is not possible.

[Sunil Sharma_1]

Hi,
It's very simple and steps will be followed.
1. umount all FS belonging to vg05.
2. vgchange -an /dev/vg05
3. vgexport -vm

[Michael Tully]

shared mode is NOT just for MC/SG. It is used to capture the VGID.
You can safely use it, I do all the time mounting BCV's on secondary servers for testing. ALthough the man page may indicate this, (MC/SG) you can use it for this type of work.

[twang]

The device files minor number must be same on both systems. But I think device name could be different.

[RAC_1]

Thanks to everyone.

Seems that this has to be done using -s options or else it does not work.

Withous -s options it gives me following error.
Volume Group belongs to different CPU ID

Then vgimport goes fine. But I can not activate the vg, gives error as vg not in lvmtab and vgscan does not help in this regard.

I think it is possible only with -s options.

Gurus please confirm.

[James Murtagh]

That warning is normal, it shouldn't affect the import. What makes you think the import went ok? Do the device files get created for the VG? You are not specifying the -p option on the import are you? Is the minor number for the group file unique? Also, ensure the VG was properly deactivated and exported from the other server.

I don't know why everyone's getting so excited about the -s option - its just another way to do it, there is no right or wrong way in this regard, just personal preference. Hence using -s or specifying the correct disks on the command line is functionally equivalent.

[James Murtagh]

That warning is normal, it shouldn't affect the import. What makes you think the import went ok? Do the device files get created for the VG? You are not specifying the -p option on the import are you? Is the minor number for the group file unique? Also, ensure the VG was properly deactivated and exported from the other server.

I don't know why everyone's getting so excited about the -s option - its just another way to do it, there is no right or wrong way in this regard, just personal preference. Hence using -s or specifying the correct disks on the command line is functionally equivalent.

[Michael Tully]

yes it will work!

I do this particular task just about every week with BCV's onto a dev server, and it is done using -s option. In fact I am doing this right now. Only difference we have is that we use the same volume group.

Please advise exact syntax for all the commands you used and exactly where the error came up.

[RAC_1]

This is what I tried.

With -s option

1. vgexport -pvs -m /tmp/vg08.map vg08
No erros--
2. vgchange -a n vg08 - OK
3. put /tmp/vg08 on other server-B.
On server B
4. mkdir /dev/vg03
5. mknod /dev/vg03/group c 64 0x030000
6. vgimport -pvs -m /tmp/vg08.map vg03
was OK
7. vgimport -vs -m /tmp/vg08.map vg03
8. vgchange -a y vg03-OK

Without -s options

1. vgexport -pv -m /tmp/vg08.map vg08
No erros--
2. vgchange -a n vg08 - OK
3. put /tmp/vg08 on other server-B.
On server B
4. mkdir /dev/vg03
5. mknod /dev/vg03/group c 64 0x030000
6. vgimport -pv -m /tmp/vg08.map vg03
gave error - Volume Group belongs to different CPU ID
last message- vgimport completed successfully.

7. vgimport -vs -m /tmp/vg08.map vg03
gave error - Volume Group belongs to different CPU ID
last message- vgimport completed successfully.
8. vgchange -a y vg03-error
vg03 not in lvmtab file. Did vgscan -a, no change in errors.
can not do vgchange -a y vg03.
Tried
9. Also tried - vgimport -v -m /tmp/vg08.map vg03 /device_file--same errors.

[James Murtagh]

On the "without -s" try you then imported using the -s option and not by the correct procedure in specifying the disks after the volume group name.

[RAC_1]

For James,

Can you give exact steps-for doing it without -s option?

Thanks in advance. Points are coming.

[James Murtagh]

I think you pretty much had it the first time, without the vgreduce, hence I won't repeat all the steps. I notice you did actually try to import using the device files on the last step, which I missed before. However, I imagine you are just making a slight mistake. You must correctly identify and include all device files on the new host for importing. If you think you know the correct devices you can use the following to confirm the VGID :

# echo 0x2010?2X | adb /dev/dsk/cXtXdX | expand | tr -d " " | sed "s/2010:/VGID /"

This number should be the same for all disks within the volume group. Just be careful of the syntax and format of commands.

[RAC_1]

Tried everything that i know. Still not working without -s options.

James,

Even chekcing the vgid did not help. I will try it again with a fresh vg.

[V.Tamilvanan]

Hi,
You no need to specify the map file -m option when you know all the pvs belong to the volumegroup. The only difference is you get all the logical volumes under the vg as lvol1, lvol2 ....
The command is simple.

#vgimport -v vg09 all_pvs