vgextend io error

[Chad Brindley]

Hi,

We have an old HP VA, Surestore 7410 I believe the model is.

A long time ago we had some LUNS created for us by a 3rd party and presented to one of our Servers. The LUNS are 0% used and the disks show as Unused when looking at disk devices in SAM.

I tried to run a vgextend yesterday and it returned an io error on physical device.

I ran an ioscan and the device files are present in /dev/dsk and /dev/rdsk but as stated when running a vgextend that pv to volume group it returns an io error on physical device.

I went into SAM and tried to extend the volume group in there when I receive the following warning;

At least one of the disks you have chosen is larger than the disk size allowed by volume group vgdbDBW (102396 Mbytes). These disks can still be used, but any capacity beyond the volume group limit will be wasted.

Do you want to use these disks anyway?.


-----------------

I cancelled the operation by selection No.

I am not overly confident on HPUX and my skillset is limited so any help or advice would be appreciated. I have got this far without assistance and other than a vgextend I dont think there is much more for me to do.

I didnt want to run the vgextend forcibly just incase my workings out were incorrect on the LUN front even though the pv shows as Unused.

Chad

[ani007]

which file system you want to extend?pls let us know the o/p of #vgdisplay

Regards,
Ani

[Chad Brindley]

Hi,

Please see attached output from vgdisplay of the volume I want to extend.

Chad

[ani007]

Hi,
Please check whether online JFS is installed or not. #swlist -l product | grep -i jfs.
If you have online JFS then you can extend the file system online(without unmount the file system).
PE Size (Mbytes) 4
Total PE 25596
Alloc PE 20500
Free PE 5096

you have(5096*4)=19.90GB free space.so how much space you want to extend.which file system you want to extend.please put the o/p of #bdf .If you want to extend more then 19GB then you need to assign lun.For that pls tell me know the lun cXtXdX no.

regards,
Ani

[Chad Brindley]

Hi,

Yes it has onlineJFS installed but I want to extend the Volume Group in readiness for future data growth. I have done an lvextend before and it works fine.

The issue I have is when I run a vgextend (as below) it returns an IO error on physical device.

vgextend /dev/vgdbDBW /dev/dsk/c4t2d5

I worked out that device is LUN number 21 using SAM > Disk Devices, it shows that device as being Unused and not part of LVM.

ioscan displays for that device:

disk 5 0/3/1/0.1.4.0.0.2.5 sdisk CLAIMED DEVICE HP A6218A
/dev/dsk/c4t2d5 /dev/rdsk/c4t2d5

If I try to extend via SAM it pops up with this;

At least one of the disks you have chosen is larger than the disk size allowed by volume group vgdbDBW (102396 Mbytes). These disks can still be used, but any capacity beyond the volume group limit will be wasted.

So I clicked No to cancel the operation.

Basically;
-I need to confirm that this pv is definately Unused?

-If unused how do I extend the Volume Group without error. Have I missed a step as the pv looks to have been created in /dev/dsk and /dev/rdsk.

Regards,

Chad

[Manix]

Hello Guys ,

This is pretty simple i guess

Max PE per PV 25599
VGDA 2
PE Size (Mbytes) 4

=103 Gigs ( 25999 *4 )

You have defined maximum PE/PV (-e) & PE size (-s ) while VG creation so this is the max size of PV that VG can capture.

You can bypass the warning.

Or you need vgcfgmodify to change max PE/PV
for that OS needs to be 11.31 or 11.23 ( with patching.

You need to deactivate the VG to run "vgcfgmodify"

Other wise just bypass if the disk is not much larger then 103 Gigs.

Hope this helps.

Thanks

Manix

[Chad Brindley]

Thanks Manix, that makes sense. I'd only lose a small amount then.

I really don't have enough time on HPUX or any flavours of unix to understand it. That makes sense now, pretty simple.

Do you have any thought's on the other issues I described in the thread?

The vgextend io error being one and determining that the PV is definately Unused?

As always, thanks again for the help thus far.

Chad

[Torsten.]

>> I tried to run a vgextend yesterday and it returned an io error on physical device.



Nobody knows what command you run exactly and if the command was wrong or not...

[Chad Brindley]

Torsten,

It was in one of my later reponses, this is the command I had run.

vgextend /dev/vgdbDBW /dev/dsk/c4t2d5

Chad

[Torsten.]

OK, you cannot vgextend it if pvcreate was not run.


Any more questions?

[Chad Brindley]

Thanks Torsten.

The system was built in 2005 and the LUNS created then and presented to the Server, they have since been sitting there unused.

The device file c4t2d5 has files created in /dev/dsk/ and /dev/rdsk/ which made me think pvcreate has been run?

Am I wrong to think this?

Chad

[Torsten.]

>> The device file c4t2d5 has files created in /dev/dsk/ and /dev/rdsk/ which made me think pvcreate has been run?


No, you cannot assume this.

/dev/dsk/c4t2d5 and /dev/rdsk/c4t2d5 are the device files for this disk (LUN in this case);
pvcreate will create the LVM structure on this disk, you need to use "pvdisplay" to see them.

You cannot add a disk to a VG if there are no LVM structures on it.

[Chad Brindley]

Torsten thats fantastic, learning as we go here.

So I will need to run pvcreate so LVM knows about it otherwise the vgextend does not recognise it as a device it can use.

I was told previously with some math you can work out the LUN number from the device name
e.g. c4t2d5.

Is this correct? If so what's the algorithm? I just wanted to ensure the device is linked to the LUN I think it is.

[Manix]

Hello Chad !!

whats your other query ,related to PV size must been solved ..hope so -)).

You wrote when you were running SAM the only
error you got was due to size and nothing else!!

I think SAM would run pvcreate itself before
vgextend.

If you are doing it through command line
you need to run pvcreate first.

Regarding LUN no you need to look at the full
HW address as shown in ioscan -fnC disk.

Depends upon version and SAN topology as well to be precise.

cxtxdx --> controller ,target ,lun.

Thanks

Manix

[Torsten.]

A calculation from the device file is not possible (well, most of the times the result is right, but it is not sure at all), but you can calculate it from the hardware path.

0/3/1/0.1.4.0.0.2.5

2 in binary is 0010

5 in binary is 101 (only 3 digits here!)

so path 2.5 is 0010.101 converted to binary.


This is already your LUN number.

10101 (bin) = 15 (hex) = 21 (dec)


Your LUN number is 21.

[Chad Brindley]

Thanks Torsten,

So using that logic;

0/3/1/0.1.4.0.0.5.1 = LUN 41
0/3/1/0.1.4.0.0.4.3 = LUN 35

I have managed to extend one of the Volume groups I need to by running a pvcreate first.

Do I need to do anything for the alternate links or is this handled by LVM?

Once I have completed this task I will of course assign points accordingly as you have all been most helpful.

Chad

[Torsten.]

Your calculation is correct.


If you don't run 11.31, you need to add the alternate pathes to the VG using vgextend.

[Chad Brindley]

We are on 11.23.

So do I just run (as below).

Assuming I dont need to pvcreate?

vgextend /dev/volumegroup /dev/dsk/c6t2d5
vgextend /dev/volumegroup /dev/dsk/c9t2d5
vgextend /dev/volumegroup /dev/dsk/c11t2d5

I have attached the ioscan just to clarify.

When I ran the pvcreate on c4t2d5 I just ran it on /dev/rdsk/c4t2d5 which worked okay, again is this correct?

Apologies for so many questions, I feel I have learn't a lot with just your help on this today.

[Torsten.]

You are right, do pvcreate only once, otherwise you delete your data.

Just vgextend the other paths and check with vgdiosplay -v ...


For this VA hardware you can use the "armtopology" command to get more information.

[Chad Brindley]

Thanks, I added those alternate paths in fine.

Just trying to extend one of our other volume groups and it says Volume Group extended successfully then just appears to hang. 15 minutes later it gave the following error message;

vgcfgbackup: IO error on Physical Volume device /dev/rdsk/c4t2d7: I/O error

It has not written to /etc/lvmconf/vgdbQBW.conf as the time and date stamp are old.

vgdisplay shows it has extended the volume group.

c4t2d7 looks like it is an alternate path setup when the volume group was created.

Chad

[Manix]

check if disk is bad ..
run the command "dd if=/dev/rdsk/c4t2d7 of=/dev/null bs=1024 count=1000"

keep the count high if the command passes.

Hope you are adding the disks running pvcreate.

[Torsten.]

Forget "dd" here, it is an array!

[Torsten.]

First I would check the array health.
If commandview sdm is installed, run

# armdsp -a

and check if it is "ready", without errors and warnings.

[Chad Brindley]

Hi Torsten,

I checked the array with the armdsp command and it reports back as ready and the enclosures + disks report back as Good.

I have ran the vgextend for one of the alternate paths and it seems to be doing the same again with the IO timeout.

The vgextend command works but it times out with an io error once again when trying to run the vgcfgbackup (as below).

vgcfgbackup: IO error on Physical Volume device /dev/rdsk/c4t2d7: I/O error

I can run the pvdisplay and diskinfo to the disk with the command.

pvdisplay -v /dev/dsk/c4t2d7
diskinfo /dev/rdsk/c4t2d7

c4t2d7 looks like the primary path on the other LUN which is presented to this Server and extended to this same Volume group.

And there are no array issues as confirmed above. Strange.

I am not sure on the LVM patch levels but as this worked on a previous vgextend it would be strange if it was that.

Would a reboot of the Server help? Maybe something is locking that file, nothing in syslog.

What is the syntax to run a vgcfgbackup manually?

Regards,

Chad

[Torsten.]

Secure Manager in use?

Try to get the table like this

armsecure â r â f lun_security.txt -p AUTORAID array_alias

where AUTORAID is the password. Adjust password and alias.