Creating secondary swap on 11.31 - swapon errors

[Eric Yruegas]

This procedure has been used many times in my environment on 11.31 servers - but I have to newer ones that are giving me bizarre errors.

Below is a capture of the session... swapon error is at the bottom.

Any input is welcomed - I've got to be missing something here... this has worked on many other 11.31 machines...



# mkdir /dev/vg01
# mknod /dev/vg01/group c 64 0x010000
# pvcreate -f /dev/rdsk/c6t8d5
Physical volume "/dev/rdsk/c6t8d5" has been successfully created.
# vgcreate -s 64 /dev/vg01 /dev/dsk/c6t8d5
Volume group "/dev/vg01" has been successfully created.
Volume Group configuration for /dev/vg01 has been saved in /etc/lvmconf/vg01.conf
# lvcreate -C y -D n -s y -r n -L 32768 /dev/vg01
Logical volume "/dev/vg01/lvol1" has been successfully created with
character device "/dev/vg01/rlvol1".
Logical volume "/dev/vg01/lvol1" has been successfully extended.
Volume Group configuration for /dev/vg01 has been saved in /etc/lvmconf/vg01.conf
# swapon -p 1 -t dev /dev/vg01/lvol1
swapon: The device /dev/vg01/lvol1 is a VxVM or LVM disk,
which prevents paging there.

[Steven E. Protter]

Shalom,

lvcreate -C y -D n -s y -r n -L 32768 /dev/vg01

This command did not specify a disk. That should not be a problem so long as there is only one disk in vg01.

vgdisplay -v vg01

lvdisplay -v /dev/vg1/lvol1

Looks like you used lvm striping. You can not if I am correct do that for swap. device swap is better than file system swap.

The problem is the lvcreate options.

SEP

[James R. Ferguson]

Hi:

@ SEP: Looks like you used lvm striping.

No, he didn't. Re-read the manpages for 'lvcreate" and you will see that he specified (C)ontiguous allocation, _no_ (D)istributed allocation, (s)trict alloction and no (r)elocation of bad blocks. This is correct for device swap.

Regards!

...JRF...

[Patrick Wallek]

What happens if you omit the '-t' option to your swapon command?

swapon -p 1 /dev/vg01/lvol1

[P Arumugavel]

Your steps are seems to be right which I evaluated on my test server and found worked out.

I could suggest, if you destroy the VG, rmsf the device file of disk and recreate the same and test.

Rgds...

[Eric Yruegas]

Steven: per your request-
--- Volume groups ---
VG Name /dev/vg01
VG Write Access read/write
VG Status available
Max LV 255
Cur LV 1
Open LV 1
Max PV 16
Cur PV 1
Act PV 1
Max PE per PV 1016
VGDA 2
PE Size (Mbytes) 64
Total PE 544
Alloc PE 512
Free PE 32
Total PVG 0
Total Spare PVs 0
Total Spare PVs in use 0
VG Version 1.0
VG Max Size 1016g
VG Max Extents 16256

--- Logical volumes ---
LV Name /dev/vg01/lvol1
LV Status available/syncd
LV Size (Mbytes) 32768
Current LE 512
Allocated PE 512
Used PV 1


--- Physical volumes ---
PV Name /dev/dsk/c6t8d5
PV Status available
Total PE 544
Free PE 32
Autoswitch On
Proactive Polling On


# lvdisplay -v /dev/vg01/lvol1
--- Logical volumes ---
LV Name /dev/vg01/lvol1
VG Name /dev/vg01
LV Permission read/write
LV Status available/syncd
Mirror copies 0
Consistency Recovery MWC
Schedule parallel
LV Size (Mbytes) 32768
Current LE 512
Allocated PE 512
Stripes 0
Stripe Size (Kbytes) 0
Bad block off
Allocation strict/contiguous
IO Timeout (Seconds) default

--- Distribution of logical volume ---
PV Name LE on PV PE on PV
/dev/dsk/c6t8d5 512 512

--- Logical extents ---
LE PV1 PE1 Status 1
00000 /dev/dsk/c6t8d5 00000 current
00001 /dev/dsk/c6t8d5 00001 current
00002 /dev/dsk/c6t8d5 00002 current
00003 /dev/dsk/c6t8d5 00003 current
00004 /dev/dsk/c6t8d5 00004 current
{snip}
00509 /dev/dsk/c6t8d5 00509 current
00510 /dev/dsk/c6t8d5 00510 current
00511 /dev/dsk/c6t8d5 00511 current

[Eric Yruegas]

Patrick-

Omitting the "-t" option gives same error message.

[Eric Yruegas]

Mr Arumugavel-

Removal of device files/VG and recreating have no effect.

[Eric Yruegas]

To followup - one point I didn't mention (and turns out to be relevant) was that the disks were SAN LUNs... not local-attached SCSI disks.

Turns out there were some HBA flags that were not set when the mapping/masking of the LUNs to the server.

Once that was fixed, all was well.

[Eric Yruegas]

SAN HBA mapping/masking flags not properly set during allocation of SAN LUNs used.