* You are viewing the archive for the ‘storage’ Category

Disabling MPxIO for onboard disks

I was configuring MPxIO on Sun Fire V490. After issuing stmsboot -e command and rebooting the server, internal disks were under MPxIO’s control.

This was not something I wanted and I needed to disable it. In order to do so I had to edit /kernel/drv/fp.conf file and tell Solaris not to enable MPxIO on internal disks. So I added the following line at the end of fp.conf file:

name="fp" parent="/pci@8,600000/SUNW,qlc@4" port=0 mpxio-disable="yes";

This line tells Solaris to disable MPxIO on port 0 for all devices whose parent device is /pci@8,600000/SUNW,qlc@4. Of course, similar line should be added for all HBA’s and ports you do not want to have under MPxIO’s control. You can get the parent device from your /var/adm/messages file or from device links pointing to the internal disks. Here is a partial list of device links:
<—————–SNIP—————->
lrwxrwxrwx 1 root other 70 Jun 12 11:50 c1t0d0s0 -> ../../devices/pci@8,600000/SUNW,qlc@4/fp@0,0/ssd@w2100002037c3e2ef,0:a
lrwxrwxrwx 1 root other 70 Jun 12 11:50 c1t0d0s1 -> ../../devices/pci@8,600000/SUNW,qlc@4/fp@0,0/ssd@w2100002037c3e2ef,0:b
lrwxrwxrwx 1 root other 70 Jun 12 11:50 c1t0d0s2 -> ../../devices/pci@8,600000/SUNW,qlc@4/fp@0,0/ssd@w2100002037c3e2ef,0:c
lrwxrwxrwx 1 root other 70 Jun 12 11:50 c1t0d0s3 -> ../../devices/pci@8,600000/SUNW,qlc@4/fp@0,0/ssd@w2100002037c3e2ef,0:d
lrwxrwxrwx 1 root other 70 Jun 12 11:50 c1t0d0s4 -> ../../devices/pci@8,600000/SUNW,qlc@4/fp@0,0/ssd@w2100002037c3e2ef,0:e
lrwxrwxrwx 1 root other 70 Jun 12 11:50 c1t0d0s5 -> ../../devices/pci@8,600000/SUNW,qlc@4/fp@0,0/ssd@w2100002037c3e2ef,0:f
lrwxrwxrwx 1 root other 70 Jun 12 11:50 c1t0d0s6 -> ../../devices/pci@8,600000/SUNW,qlc@4/fp@0,0/ssd@w2100002037c3e2ef,0:g
lrwxrwxrwx 1 root other 70 Jun 12 11:50 c1t0d0s7 -> ../../devices/pci@8,600000/SUNW,qlc@4/fp@0,0/ssd@w2100002037c3e2ef,0:h

<—————–SNIP—————-> Continue Reading

Gathering fibre channel info using fcinfo

I came across fcinfo command reading some man page. So, I decided to see what kind of useful fibre channel information it could give me. It turns out fcinfo knows quite a bit.

We can list all local fibre channel ports:

bash-3.00# fcinfo hba-port
HBA Port WWN: 21000003ba16dbd2
OS Device Name: /dev/cfg/c1
Manufacturer: QLogic Corp.
Model: 2200
Firmware Version: 2.1.144
FCode/BIOS Version: ISP2200 FC-AL Host Adapter Driver: 1.12 01/01/16
Type: L-port
State: online
Supported Speeds: 1Gb
Current Speed: 1Gb
Node WWN: 20000003ba16dbd2
HBA Port WWN: 2100001b320e3853
OS Device Name: /dev/cfg/c3
Manufacturer: QLogic Corp.
Model: QLA2462
Firmware Version: 4.0.27
FCode/BIOS Version: QLA2462 Host Adapter Driver(SPARC): 1.24 11/15/06
Type: N-port
State: online
Supported Speeds: 1Gb 2Gb 4Gb
Current Speed: 2Gb
Node WWN: 2000001b320e3853
HBA Port WWN: 2101001b322e3853
OS Device Name: /dev/cfg/c4
Manufacturer: QLogic Corp.
Model: QLA2462
Firmware Version: 4.0.27
FCode/BIOS Version: QLA2462 Host Adapter Driver(SPARC): 1.24 11/15/06
Type: N-port
State: online
Supported Speeds: 1Gb 2Gb 4Gb
Current Speed: 2Gb
Node WWN: 2001001b322e3853

We can take a look what remote ports are seen by particular local fibre channel port, in this case 2100001b320e3853:

bash-3.00# fcinfo remote-port -p 2100001b320e3853
Remote Port WWN: 100000e00216aef3
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 100000e01124b88f
Remote Port WWN: 50001fe15003b384
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 50001fe15037e759
Remote Port WWN: 100000e0022744f3
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 100000e0020744f3
Remote Port WWN: 50001fe150216de9
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 50001fe11025bb53
Remote Port WWN: 100000e00228f492
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 100000e00208f492
Remote Port WWN: 50001fe15076b59b
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 50001fe15037e759
Remote Port WWN: 50001fe150216ded
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 50001fe11025bb53

Here, we get link statistics for remote fibre channel device whose WWN is 100000e0020744f3:

bash-3.00# fcinfo remote-port -l -p 2100001b320e3853 100000e0020744f3
Remote Port WWN: 100000e0022744f3
Active FC4 Types: SCSI
SCSI Target: unknown
Node WWN: 100000e0020744f3
Link Error Statistics:
Link Failure Count: 0
Loss of Sync Count: 0
Loss of Signal Count: 0
Primitive Seq Protocol Error Count: 0
Invalid Tx Word Count: 0
Invalid CRC Count: 0

We can also get link statistics and SCSI target information for all remote fibre channel devices see on local port whose WWN is 2100001b320e3853:

bash-3.00# fcinfo remote-port -sl -p 2100001b320e3853
Remote Port WWN: 100000e00216aef3
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 100000e01124b88f
Link Error Statistics:
Link Failure Count: 0
Loss of Sync Count: 0
Loss of Signal Count: 0
Primitive Seq Protocol Error Count: 0
Invalid Tx Word Count: 0
Invalid CRC Count: 0
LUN: 0
Vendor: HP
Product: MSL6000 Series
OS Device Name: /devices/pci@8,600000/SUNW,qlc@1/fp@0,0/sgen@w100000e00216aef3,0
LUN: 1
Vendor: HP
Product: Ultrium 2-SCSI
OS Device Name: /dev/rmt/2n
Remote Port WWN: 50001fe15003b384
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 50001fe15037e759
Link Error Statistics:
Link Failure Count: 0
Loss of Sync Count: 0
Loss of Signal Count: 0
Primitive Seq Protocol Error Count: 0
Invalid Tx Word Count: 0
Invalid CRC Count: 0
LUN: 0
Vendor: COMPAQ
Product: HSV111 (C)COMPAQ
OS Device Name: Unknown
LUN: 1
Vendor: COMPAQ
Product: HSV111 (C)COMPAQ
OS Device Name: /dev/rdsk/c5t600508B4001031250000900000540000d0s2
Remote Port WWN: 100000e0022744f3
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 100000e0020744f3
Link Error Statistics:
Link Failure Count: 0
Loss of Sync Count: 0
Loss of Signal Count: 0
Primitive Seq Protocol Error Count: 0
Invalid Tx Word Count: 0
Invalid CRC Count: 0
LUN: 0
Vendor: HP
Product: MSL6000 Series
OS Device Name: /devices/pci@8,600000/SUNW,qlc@1/fp@0,0/sgen@w100000e0022744f3,0
LUN: 1
Vendor: HP
Product: Ultrium 2-SCSI
OS Device Name: /dev/rmt/1n
LUN: 2
Vendor: HP
Product: Ultrium 2-SCSI
OS Device Name: /dev/rmt/0n
Remote Port WWN: 50001fe150216de9
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 50001fe11025bb53
Link Error Statistics:
Link Failure Count: 0
Loss of Sync Count: 0
Loss of Signal Count: 0
Primitive Seq Protocol Error Count: 0
Invalid Tx Word Count: 0
Invalid CRC Count: 0
LUN: 0
Vendor: COMPAQ
Product: HSV111 (C)COMPAQ
OS Device Name: Unknown
LUN: 1
Vendor: COMPAQ
Product: HSV111 (C)COMPAQ
OS Device Name: /dev/rdsk/c5t600508B400011C370000C00003210000d0s2
Remote Port WWN: 100000e00228f492
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 100000e00208f492
Link Error Statistics:
Link Failure Count: 0
Loss of Sync Count: 0
Loss of Signal Count: 0
Primitive Seq Protocol Error Count: 0
Invalid Tx Word Count: 0
Invalid CRC Count: 0
LUN: 0
Vendor: HP
Product: Ultrium 2-SCSI
OS Device Name: /dev/rmt/4n
LUN: 1
Vendor: HP
Product: Ultrium 2-SCSI
OS Device Name: /dev/rmt/3n
Remote Port WWN: 50001fe15076b59b
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 50001fe15037e759
Link Error Statistics:
Link Failure Count: 0
Loss of Sync Count: 0
Loss of Signal Count: 0
Primitive Seq Protocol Error Count: 0
Invalid Tx Word Count: 0
Invalid CRC Count: 0
LUN: 0
Vendor: COMPAQ
Product: HSV111 (C)COMPAQ
OS Device Name: Unknown
LUN: 1
Vendor: COMPAQ
Product: HSV111 (C)COMPAQ
OS Device Name: /dev/rdsk/c5t600508B4001031250000900000540000d0s2
Remote Port WWN: 50001fe150216ded
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 50001fe11025bb53
Link Error Statistics:
Link Failure Count: 0
Loss of Sync Count: 0
Loss of Signal Count: 0
Primitive Seq Protocol Error Count: 0
Invalid Tx Word Count: 0
Invalid CRC Count: 0
LUN: 0
Vendor: COMPAQ
Product: HSV111 (C)COMPAQ
OS Device Name: Unknown
LUN: 1
Vendor: COMPAQ
Product: HSV111 (C)COMPAQ
OS Device Name: /dev/rdsk/c5t600508B400011C370000C00003210000d0s2

This command is quite handy when troubleshooting fibre channel. Very cool… Continue Reading

Mirroring root disk using SVM

There are about 487359 documents on the Internet about how to mirror root disk in Solaris. So, here is 487360th.

The assumptions are following: the first disk has Solaris already installed, root slice is slice 1, and the disks are identical with the same size and geometry. If they have different cylinder, head, sector count or different size you will have to fiddle with sizing slices more.

The first step is to recreate the same slice arrangement on the second disk:

bash-3.00# prtvtoc /dev/rdsk/c1t0d0s2 | fmthard -s - /dev/rdsk/c1t1d0s2
fmthard: New volume table of contents now in place.

You can check both disks have the same VTOC using prtvtoc command

bash-3.00# prtvtoc /dev/rdsk/c1t0d0s2
* /dev/rdsk/c1t0d0s2 partition map
*
* Dimensions:
* 512 bytes/sector
* 424 sectors/track
* 24 tracks/cylinder
* 10176 sectors/cylinder
* 14089 cylinders
* 14087 accessible cylinders
*
* Flags:
* 1: unmountable
* 10: read-only
*
* First Sector Last
* Partition Tag Flags Sector Count Sector Mount Directory
0 3 01 0 4100928 4100927
1 2 00 4100928 20484288 24585215
2 5 00 0 143349312 143349311
3 8 00 24585216 118672512 143257727
7 0 00 143257728 91584 143349311

Now we have to create state database replicas on slice 7. We will be adding two replicas to each slice:

bash-3.00# metadb -a -f -c3 /dev/dsk/c1t0d0s7
bash-3.00# metadb -a -f -c3 /dev/dsk/c1t1d0s7

Database replicas are crucial part of SVM. Here is some important information about how they work, how many you need, etc.

Since the database replicas are in place we can start creating metadevices. The following commands will create metadevice d31 from slice c1t0d0s3, and metadevice d32 from slice c1t1d0s3. Then we create mirror d30 with d31 attached as a submirror. Finally we will attach submirror d32 to mirror d30. Once d32 is attached, the mirror d30 will automatically start syncing.

bash-3.00# metainit -f d31 1 1 c1t0d0s3
d31: Concat/Stripe is setup
bash-3.00# metainit -f d32 1 1 c1t1d0s3
d32: Concat/Stripe is setup
bash-3.00# metainit d30 -m d31
d30: Mirror is setup
bash-3.00# metattach d30 d32
d30: submirror d32 is attached

The procedure is the same for all other mirrors you might want to create. Root filesystem is slightly different. First you will have to create your submirrors. Then you will have to attach submirror with existing root filesystem, in this case d11, to the new mirror metadevice d10. Then you will have to run metaroot command. It will alter / entry in /etc/vfstab. Finally, you flush the filesystem using lockfs command and reboot.

bash-3.00# metainit -f d11 1 1 c1t0d0s1
d31: Concat/Stripe is setup
bash-3.00# metainit -f d12 1 1 c1t1d0s1
d32: Concat/Stripe is setup
bash-3.00# metainit d10 -m d11
d30: Mirror is setup
bash-3.00# metaroot d10
bash-3.00# lockfs -fa
bash-3.00# reboot

When the system reboots, you can attach the second submirror to d10 as follows:

bash-3.00# metattach d10 d12

You can check the sync progress using metastat command. Once all mirrors are synced up the next step is to configure the new swap metadevice, in my case d0, to be crash dump device. This is done using dumpadm command:

bash-3.00# dumpadm
Dump content: kernel pages
Dump device: /dev/dsk/c1t0d0s0 (dedicated)
Savecore directory: /var/crash/ultra
Savecore enabled: yes
bash-3.00# dumpadm -d /dev/md/dsk/d0

The final step is to modify PROM. First we need to find out which two physical devices c1t0d0 and c1t1d0 refer to:

bash-3.00# ls -l /dev/dsk/c1t0d0s1
lrwxrwxrwx 1 root root 43 Mar 4 14:38 /dev/dsk/c1t0d0s1 -> ../../devices/pci@1c,600000/scsi@2/sd@0,0:b
bash-3.00# ls -l /dev/dsk/c1t1d0s1
lrwxrwxrwx 1 root root 43 Mar 4 14:38 /dev/dsk/c1t1d0s1 -> ../../devices/pci@1c,600000/scsi@2/sd@1,0:b

The physical device path is everything starting from /pci…. Please make a note of sd towards the end of the device string. When creating device aliases below, sd will have to be changed to disk.

Now we create two device aliases called root and backup_root. Then we set boot-device to be root and backup_root. The :b refers to slice 1(root) on that particular disk.

bash-3.00# eeprom "use-nvramrc?=true"
bash-3.00# eeprom "nvramrc=devalias root /pci@1c,600000/scsi@2/disk@0,0 devalias backup_root /pci@1c,600000/scsi@2/disk@1,0"
bash-3.00# eeprom "boot-device=root:b backup_root:b net"

Now we can test that the system boot from both root and backup_root devices.

There is one more optional step. Adding two kernel tunables to /etc/system file. The first one is md_mirror:md_resync_bufsz which will speed up mirror resync. The second one is md:mirrored_root_flag. When this flag is enabled the system will boot even if less than majority of database replicas is available. Personally, I do not use the second tunable. More on these can be found in Solaris Tunable Parameters Reference Guide. Continue Reading

Moving boot disk to a different target or controller

I had a need for a system that can boot two different versions of Solaris from two different disks. Both disks were on target 0 when Solaris was installed on them. But when I moved one of the disks to be target 1, obviously there was going to be a problem with booting from that disk.

There is a simple way to get the disk booting from the new target. Here are the steps to take:

  1. Boot the system off a DVD or CD or jumpstart server in single user mode
  2. Mount the root filesystem on the disk in question and edit vfstab to reflect the new controller/target setup

The last step is to regenerate /etc/path_to_inst and device links in /dev. Searching the internet for some unrelated info I found out devfsadm has an undocumented -p switch that recreates path_to_inst file. The -r switch specifies location of root filesystem.

bash-3.00# devfsadm -r /mnt -p /mnt/etc/path_to_inst

Now you can reboot and the drive should be bootable again. Continue Reading

Moving LUN's between hosts using metarecover

Sometimes you might need to move a LUN between hosts X and Y on a SAN. Solaris has cool command, metarecover, that lets you do just that. First, you will need to stop all processes on X that might be using the given LUN. Then unmount the LUN and present it to the host Y. Now you can use metarecover to recover metadevice information from the LUN. Couple of things to remember:

There is -n switch that will cause dry run, i.e. metarecover will output what it would do – it will not actually perform recovery operation. Also, be careful about metadevice names on host Y and the ones you are trying to recover. I have not tried it so I am not sure what would happen. It would probably bomb out. You could use metarename to rename Y’s existing metadevices and try to eliminate possible conflict before recovery.

root@ultra# metarecover -v c3t600508B400011C370000C00002970000d0s2 -p -d
Verifying on-disk structures on
c3t600508B400011C370000C00002970000d0s2.
The following extent headers were found on
c3t600508B400011C370000C00002970000d0s2.
Name Seq# Type Offset
Length
d100 0 ALLOC 205635593
25165825
d110 0 ALLOC 16384
32769
d120 0 ALLOC 49153
32769
d130 0 ALLOC 81922
32769
d140 0 ALLOC 114691
41943041
d150 0 ALLOC 42057732
146800641
d160 0 ALLOC 188858373
2097153
d170 0 ALLOC 190955526
6291457
d180 0 ALLOC 197246983
6291457
d190 0 ALLOC 203538440
2097153
NONE 0 END 251609087
1
NONE 0 FREE 230801418
20807669
Found 10 soft partition(s) on c3t600508B400011C370000C00002970000d0s2.
Checking sequence numbers.
mp->c.un_type: 5
mp->c.un_size: 136
mp->c.un_self_id: 100
mp->un_status: 5
mp->un_numexts: 1
mp->un_length: 25165824
mp->un_dev: 30933010
mp->un_key: 43
Ext# voff poff Len
0 0 205635594 25165824
mp->c.un_type: 5
mp->c.un_size: 136
mp->c.un_self_id: 110
mp->un_status: 5
mp->un_numexts: 1
mp->un_length: 32768
mp->un_dev: 30933010
mp->un_key: 43
Ext# voff poff Len
0 0 16385 32768
mp->c.un_type: 5
mp->c.un_size: 136
mp->c.un_self_id: 120
mp->un_status: 5
mp->un_numexts: 1
mp->un_length: 32768
mp->un_dev: 30933010
mp->un_key: 43
Ext# voff poff Len
0 0 49154 32768
mp->c.un_type: 5
mp->c.un_size: 136
mp->c.un_self_id: 130
mp->un_status: 5
mp->un_numexts: 1
mp->un_length: 32768
mp->un_dev: 30933010
mp->un_key: 43
Ext# voff poff Len
0 0 81923 32768
mp->c.un_type: 5
mp->c.un_size: 136
mp->c.un_self_id: 140
mp->un_status: 5
mp->un_numexts: 1
mp->un_length: 41943040
mp->un_dev: 30933010
mp->un_key: 43
Ext# voff poff Len
0 0 114692 41943040
mp->c.un_type: 5
mp->c.un_size: 136
mp->c.un_self_id: 150
mp->un_status: 5
mp->un_numexts: 1
mp->un_length: 146800640
mp->un_dev: 30933010
mp->un_key: 43
Ext# voff poff Len
0 0 42057733 146800640
mp->c.un_type: 5
mp->c.un_size: 136
mp->c.un_self_id: 160
mp->un_status: 5
mp->un_numexts: 1
mp->un_length: 2097152
mp->un_dev: 30933010
mp->un_key: 43
Ext# voff poff Len
0 0 188858374 2097152
mp->c.un_type: 5
mp->c.un_size: 136
mp->c.un_self_id: 170
mp->un_status: 5
mp->un_numexts: 1
mp->un_length: 6291456
mp->un_dev: 30933010
mp->un_key: 43
Ext# voff poff Len
0 0 190955527 6291456
mp->c.un_type: 5
mp->c.un_size: 136
mp->c.un_self_id: 180
mp->un_status: 5
mp->un_numexts: 1
mp->un_length: 6291456
mp->un_dev: 30933010
mp->un_key: 43
Ext# voff poff Len
0 0 197246984 6291456
mp->c.un_type: 5
mp->c.un_size: 136
mp->c.un_self_id: 190
mp->un_status: 5
mp->un_numexts: 1
mp->un_length: 2097152
mp->un_dev: 30933010
mp->un_key: 43
Ext# voff poff Len
0 0 203538441 2097152
The following soft partitions were found and will be added to
your metadevice configuration.
Name Size No. of Extents
d100 25165824 1
d110 32768 1
d120 32768 1
d130 32768 1
d140 41943040 1
d150 146800640 1
d160 2097152 1
d170 6291456 1
d180 6291456 1
d190 2097152 1
WARNING: You are about to add one or more soft partition
metadevices to your metadevice configuration. If there
appears to be an error in the soft partition(s) displayed
above, do NOT proceed with this recovery operation.
Are you sure you want to do this (yes/no)? yes
c3t600508B400011C370000C00002970000d0s2: Soft Partitions recovered
from device.
root@ultra#
Continue Reading

Page 2 of 3123