1836605
Members
2011
Online
110102
Solutions
Just stop and be careful here...
How have you estableshed that they are the same disks between the two cluster nodes... simply having the same device file name does not mean they are the same disk.
Better to post the output of:
ioscan -funCdisk
and let us figure out which disks are which...
HTH
Duncan
I am an HPE Employee
How have you estableshed that they are the same disks between the two cluster nodes... simply having the same device file name does not mean they are the same disk.
Better to post the output of:
ioscan -funCdisk
and let us figure out which disks are which...
HTH
Duncan
I am an HPE Employee
Les,
OK, looking at these outputs, you need to look at the part of the hardware path that comes after the FC HBA.
From this I can determine that these boxes each have 2 FC ports connected to 2 ports on your DMX.
SO I can see that:
- disk devices which are presented from a port on the DMX which has hardware path 108.102.19 all start with c14 on server 1 and c12 on server 2.
- disk devices which are presented from a port on the DMX which has hardware path 107.110.19 all start with c16 on server 1 and c14 on server 2.
I'd imagine that the two paths are to the same sets of LUNs.
The disks you mention certainly have the highest instance number (77 and 78 on server 1 and 70 and 71 on server 2), so they certainly look like the last 2 that were added - maybe they have already been presented somehwere else before. You can check they're not already in use on these machines by running:
on server 1:
pvdisplay -v /dev/dsk/c14t2d0
pvdisplay -v /dev/dsk/c16t2d0
strings /etc/lvmtab
on server 2:
pvdisplay -v /dev/dsk/c12t2d0
pvdisplay -v /dev/dsk/c14t2d0
strings /etc/lvmtab
Even if they're not in use on these systems, if they already appear to have an LVM structure on them (as the pvcreate serror suggests), I'd at least have your SAN team check again that they haven't presented you with a LUN from another HPUX box.
HTH
Duncan
I am an HPE Employee
OK, looking at these outputs, you need to look at the part of the hardware path that comes after the FC HBA.
From this I can determine that these boxes each have 2 FC ports connected to 2 ports on your DMX.
SO I can see that:
- disk devices which are presented from a port on the DMX which has hardware path 108.102.19 all start with c14 on server 1 and c12 on server 2.
- disk devices which are presented from a port on the DMX which has hardware path 107.110.19 all start with c16 on server 1 and c14 on server 2.
I'd imagine that the two paths are to the same sets of LUNs.
The disks you mention certainly have the highest instance number (77 and 78 on server 1 and 70 and 71 on server 2), so they certainly look like the last 2 that were added - maybe they have already been presented somehwere else before. You can check they're not already in use on these machines by running:
on server 1:
pvdisplay -v /dev/dsk/c14t2d0
pvdisplay -v /dev/dsk/c16t2d0
strings /etc/lvmtab
on server 2:
pvdisplay -v /dev/dsk/c12t2d0
pvdisplay -v /dev/dsk/c14t2d0
strings /etc/lvmtab
Even if they're not in use on these systems, if they already appear to have an LVM structure on them (as the pvcreate serror suggests), I'd at least have your SAN team check again that they haven't presented you with a LUN from another HPUX box.
HTH
Duncan
I am an HPE Employee
Les,
So now I'm glad I had you check this out - as you can see from the output from server2, plus the other commands people have asked you to run, the LUN in question is already in use and already part of a different volume group on server2.
It's actually part of the volume group vgclwss on server2. It isn't part of the configuration on server1 - this means you're cluster is currently broken and wouldn't failover correctly.
Luckily the pvdisplay also indicates that there aren't any actual logical volumes on those disks so fixing the problem should be reasonably straightforward. But before going any further you need to tell us which cluster package vgclwss is part of, and on which node that package is running. Once we have that info, we should be able to fix this issue...
HTH
Duncan
I am an HPE Employee
So now I'm glad I had you check this out - as you can see from the output from server2, plus the other commands people have asked you to run, the LUN in question is already in use and already part of a different volume group on server2.
It's actually part of the volume group vgclwss on server2. It isn't part of the configuration on server1 - this means you're cluster is currently broken and wouldn't failover correctly.
Luckily the pvdisplay also indicates that there aren't any actual logical volumes on those disks so fixing the problem should be reasonably straightforward. But before going any further you need to tell us which cluster package vgclwss is part of, and on which node that package is running. Once we have that info, we should be able to fix this issue...
HTH
Duncan
I am an HPE Employee
Les,
OK so the volume group is atcive on the same node where the disk has been incorrectly added to the wrong VG - this makes life easier. To make this LUN available for adding to the other volume group, you just need to take it out of the existing volume group. You do this by vgreduce'ing both paths out of the volume group as follows:
vgreduce /dev/vgclwss /dev/dsk/c12t2d0
vgreduce /dev/vgclwss /dev/dsk/c14t2d0
AFter that the disk is available to be added to the other volume group - -ypu will still have to use "pvcreate -f" on the disk before adding it to the other VG though.
HTH
Duncan
I am an HPE Employee
OK so the volume group is atcive on the same node where the disk has been incorrectly added to the wrong VG - this makes life easier. To make this LUN available for adding to the other volume group, you just need to take it out of the existing volume group. You do this by vgreduce'ing both paths out of the volume group as follows:
vgreduce /dev/vgclwss /dev/dsk/c12t2d0
vgreduce /dev/vgclwss /dev/dsk/c14t2d0
AFter that the disk is available to be added to the other volume group - -ypu will still have to use "pvcreate -f" on the disk before adding it to the other VG though.
HTH
Duncan
I am an HPE Employee