Setting NIC Speed and Duplex in Solaris

Below is the precise note how to change the interface settings in Solaris 10, below I have taken the example with bge0  interface in the below case. Where  adv_100fdx_cap  1  shows full duplex.

root# ndd -set /dev/bge0            adv_autoneg_cap           0

root# ndd -set /dev/bge0            adv_1000fdx_cap           0

root# ndd -set /dev/bge0            adv_1000hdx_cap         0

root# ndd -set /dev/bge0            adv_100fdx_cap             1   (This will set the NIC to Full 100 duplex)

Root# ndd -set /dev/bge0 adv_100hdx_cap          0

root# ndd -set /dev/bge0            adv_10fdx_cap              0

root# ndd -set /dev/bge0            adv_10hdx_cap             0

Though you can ensure the setting prior to change by kstat and dladm (Solaris 10) as below:

root#dladm show-dev

bge0            link: up        speed: 100   Mbps       duplex: half

bge1            link: unknown   speed: 0     Mbps       duplex: unknown

bge2            link: unknown   speed: 0     Mbps       duplex: unknown

bge3            link: unknown   speed: 0     Mbps       duplex: unknown

root # kstat -p bge:0 | grep parameters:link_

bge:0:parameters:link_autoneg   1      à  (autoneg is on)

bge:0:parameters:link_duplex    1       à (1=Half,2=Full Duplex)

bge:0:parameters:link_rx_pause  0

bge:0:parameters:link_speed     100

bge:0:parameters:link_status    1

bge:0:parameters:link_tx_pause  0

To ensure the what autoneg  setting’s we need to code on the host side we can check the link partner setting for our Switch/router  side which is currently NIC is bonded with as Below :

The cap_* parameters exist in the kernel statistics for  an Ethernet  device.  The parameters describe the maximum capability of a device. When the value of a statistic is 1,  the device  has  the  capability described. When the value is 0, the device does not have the capability.

root # kstat bge:::lp_cap_autoneg

module: bge                             instance: 0

name:   mac                             class:    net

        lp_cap_autoneg                  1

module: bge                             instance: 0

name:   mii                             class:    net

        lp_cap_autoneg                  1

If the lp_autoneg_cap is 1 (ie, auto-negotiate is enabled on the link partner), action should be taken to either disable autoneg_cap on the link partner, or enable autoneg_cap on the host, this is vice versa for statistic 1 & 0 or simple mean both side value should be same  for  link communication!

------ -------   snipped  ----------------------------

Manually determining NIC speed and duplex

If you have ce or bge interfaces, use kstat ce and kstat bge, respectively, to return NIC settings as we have shown above. All other interfaces may use ndd to determine NIC settings.

ndd example with bge0, assuming "instance" is 0:

root# ndd -get /dev/bge link_mode

Interpretation:

0 -- half-duplex

1 -- full-duplex

root# ndd -get /dev/bge link_speed

Interpretation:

0 -- 10 Mbit

1 -- 100 Mbit

1000 -- 1 Gbit

Note:

è  In some of the cases likewise bge/ce interfaces it doesn't set the instance yet it will give to show you the parameters  directly while using “ndd -get /dev/bge0 <parameter>”, Hence you can directly set the interface settings in this case.

è  Solaris is often unable to correctly auto-negotiate duplex settings with a link partner (e.g. switch), especially when the switch is set to 100Mbit full-duplex. You can force the NIC into 100Mbit full-duplex by disabling auto-negotiation and 100Mbit half-duplex capability.

è  Make kernel parameter changes to preserve the speed and duplex settings after a reboot. You can also put a file in /etc/rc?.d  including the” ndd” setting which you have invoked to set the settings permanent across the reboot. Below example for you reference:

root# vi /etc/rc3.d/S99ndd_set  (Before  creating this file Just cross check if  this already exists to avoid any ambiguity)

#!/bin/sh

ndd -set /dev/bge0 adv_autoneg_cap      0

ndd -set /dev/bge0 adv_1000fdx_cap      0

ndd -set /dev/bge0 adv_1000hdx_cap      0

ndd -set /dev/bge0 adv_100fdx_cap        1

ndd -set /dev/bge0 adv_100hdx_cap       0

ndd -set /dev/bge0 adv_10fdx_cap          0

ndd -set /dev/bge0 adv_10hdx_cap         0

:wq!

Make this executable like below:

root# chmod +x /etc/rc3.d/S99ndd_set

Precautionary : While carrying this Change ,this need to be done from the console itself.

Karn Kumar(karn.itguy@gmail.com)

Mirroring Boot Drives with Veritas Volume Manager(VxVM)

This document is based upon the Sun Blueprints articles:

• Toward a Reference Configuration for VxVM Managed Boot Disks

Authors:  Gene Trantham, John S. Howard

• VxVM Private Regions: Mechanics & Internals of the VxVM Confiuration Database

Author: Gene Trantham

I highly recommend reading the above articles for a complete understanding of the process.   The purpose of this document is to provide a quick reference as well as additional methods for recovery and adittional best practices.

Introduction

Many administrators choose to use an alternative volume manager to mirror the boot drives because of the difficulties recovering from primary disk failure under VxVM.  Typically, Solsitce Disksuite(free product) is used to mirror the boot drive while VxVM is used for all other storage.  However, if VxVM is installed and configured correctly, the recovery process is greatly simplified.

The problems associated with recovery are associated in part by the way it encapsulates the boot disk(see above articles for details).  We must properly install and configure VxVM so that these issues are avoided.  In simple terms, we must first mirror the root disk.  Second, we will remove the rootdisk from rootdg and reinitialize the drive.  Third, we will add the root disk back into rootdg and re-attach the mirror.

Note:  You may be interested in determining if a system's boot drives have already been mirrored properly.  One method to identify if the rootdisk was properly mirrored is to look for the presence of the "rootdisk-B0" subdisk.  This subdisk is used to map out the boot block of the rootdisk.  Use the "vxprint -ht rootvol" command to verify if it exists.  If it does exist, the boot drive has NOT been mirrored according to these procedures.

Mirror the Drives using VxVM

Identify the root disk and mirror disk.  It is a good idea to have the drives on different controllers if possible for improved redundancy.

# format

Searching for disks...done

AVAILABLE DISK SELECTIONS:

       0. c0t0d0 <SUN9.0G cyl 4924 alt 2 hd 27 sec 133>       <===  Root

          /pci@1f,4000/scsi@3/sd@0,0

       1. c0t1d0 <SUN9.0G cyl 4924 alt 2 hd 27 sec 133>       <===  Root Mirror

          /pci@1f,4000/scsi@3/sd@1,0

Specify disk (enter its number): ^D

Install Veritas Volume Manger according to documentation.  Only encapsulate the root disk.  Do NOT encapsulate any other drives.

NOTE:  You may want to setup your PATH environment variable if you have not already done so.  If you installed in VxVM in the default location you can use the following:

# PATH=$PATH:/usr/lib/vxvm/bin; export PATH

Initialize the root mirror disk.  Add it to "rootdg" group and name the disk "rootmirror".

# vxdisksetup -i  c0t1d0

# vxdg -g rootdg adddisk rootmirror=c0t1d0

Mirror the root disk according to the partition layout. 

If you have /, swap, /var, /opt, and /home defined as partitions 0,1,3, 4, and 7 respectively, you must attach the mirrors in this same exact order.  If you are not sure, Veritas may have created notes in your /etc/vfstab which describe how the partitions were layed before VxVM encapsulated the boot disk.  It is very important to attach each mirror in the exact numerical order as it was originaly carved on the boot disk.

# vxrootmir rootmirror                                                   <=== partition 0

# vxassist -g rootdg mirror swapvol rootmirror                 <=== partition 1

# vxassist -g rootdg mirror var rootmirror                         <=== partition 3

# vxassist -g rootdg mirror opt rootmirror                        <=== partition 4

# vxassist -g rootdg mirror home rootmirror                     <=== partition 7

NOTE:  Be sure to mirror any other volumes configured on the boot disk.  This may be the case if you have additional volumes configured on the boot drive.  Use the "vxprint" command to list all volumes.  You can also use "vxprint -p" to make sure there are 2 plexes associated with each volume.  Remember to modify the remaining commands to include these additional volumes.

Disassociate and remove the existing plexes from the rootdisk:

# vxplex -g rootdg dis rootvol-01 swapvol-01 var-01 opt-01 home-01

# vxedit -g rootdg -fr rm rootvol-01 swapvol-01 var-01 opt-01 home-01

# vxedit rm rootdiskPriv                        ### May not be in rootdg - Ignore if Error

Remove the rootdisk from rootdg:

# vxdg -g rootdg rmdisk rootdisk

Re-initialize the rootdisk and add back into rootdg:

# vxdisksetup -i c0t0d0

# vxdg -g rootdg adddisk rootdisk=c0t0d0

Re-attach the mirror in the correct order according to the partition layout:

# vxrootmir rootdisk

# vxassist -g rootdg mirror swapvol rootdisk

# vxassist -g rootdg mirror var rootdisk

# vxassist -g rootdg mirror opt rootdisk

# vxassist -g rootdg mirror home rootdisk

Create the underlying partitions on the rootdisk and mirrordisk - Optional Step - The benefits are worth the effort!

Update:  This step can be automated using the Veritas supplied program: vxbootsetup.  Simply execute the following command:

# vxbootsetup

Or you may do it the manual way as described below:

Notice how you did NOT create the disk partitions manually when you initialized the mirror disk.  This is because VxVM automatically does its partitioning for you.  This is also true for the root disk after it has been re-initialized and brought back into rootdg.  That is, the original rootdisk partition scheme has been replaced by Veritas's partition scheme.  This means that the underlying partitions for each volume(swap, /opt, /var, /home) are not physically layed out on the drives corresponding to the veritas volumes.  In some situations though, you might want to be able to access the partitions corresponding to each volume by manually mounting the slice.  In a recovery situation for example, you may want to boot from cdrom and access the /opt partition by manually mounting the slice without the veritas drivers loaded.  This is not possible unless you create the underlying partition mapping directly to the opt volume using the "vxmksdpart" command.  All underlying partitions except / should be created.  The / partition is automatically created and is mapped correctly to the corresponding veritas root volume. 

One Caveat, you cannot use partition 3 or 4 because this is typically where Veritas stores is private and public region.  The following is snipped from the "format" utility listing the Veritas partitions.  This shows that the root partition exists but the swap, /var, /opt, home partitions are not mapped on the drive(Veritas knows where they exist on the drive because of its private and public regions):

Part      Tag    Flag     Cylinders        Size            Blocks

  0       root    wm       1 - 2282        3.91GB    (2282/0/0)  8194662      <=== "/" exists

  1 unassigned    wm       0               0         (0/0/0)           0              <=== Unassigned

  2     backup    wm       0 - 4923        8.43GB    (4924/0/0) 17682084

  3          -    wu       0 -    0        1.75MB    (1/0/0)        3591                <=== Private Region

  4          -    wu       1 - 4923        8.43GB    (4923/0/0) 17678493         <=== Public Region

  5 unassigned    wm       0               0         (0/0/0)           0                <=== Unassigned

  6 unassigned    wm       0               0         (0/0/0)           0                <=== Unassigned

  7 unassigned    wm       0               0         (0/0/0)           0                <=== Unassigned

You may use the unassigned partitions which are 1, 5,6, and 7 to map to the veritas volumes.  Be sure to document which partitions map to the Veritas volumes for future reference. 

The "vxmksdpart" arguments are the subdisk(which maps directly to the volume), slice, tag and flag.  Be sure to use the correct tag and flag for you particular Solaris version.  Reference the man page for "fmthard" for correct options.  Use the "vxprint" command to get the correct subdisk names:

Rootdisk:

# vxmksdpart -g rootdg rootdisk-02 1 0x03 0x01             <=== swap

# vxmksdpart -g rootdg rootdisk-03 5 0x07 0x00             <=== /var          

# vxmksdpart -g rootdg rootdisk-04 6 0x06 0x00             <=== /opt

# vxmksdpart -g rootdg rootdisk-05 7 0x08 0x00             <=== /export/home

Specify the primary swap partition as the dump device:

# dumpadm -d /dev/dsk/c0t0d0s1

RootMirror:

# vxmksdpart -g rootdg rootmirror-02 1 0x03 0x01          <=== swap

# vxmksdpart -g rootdg rootmirror-03 5 0x07 0x00          <=== /var

# vxmksdpart -g rootdg rootmirror-04 6 0x06 0x00          <=== /opt

# vxmksdpart -g rootdg rootmirror-05 7 0x08 0x00          <=== /export/home

 

For maximum redundancy, configure all private regions to have a copy of rootdg database

# vxedit -g rootdg set nconfig=all rootdg

# vxedit -g rootdg set nlog=all rootdg

# vxdg flush rootdg

Configure VxVM to use host spare rather than hot relocation

# vi /etc/rc2.d/S95vxvm-recover

Comment out the "vxrelocd root &" and uncomment "vxsparecheck root &"

Create OBP device alias for rootdisk and rootmirror.  Set PROM to boot to the aliases.

# vxeeprom devalias rootdisk c0t0d0s0

# vxeeprom devalias rootmirror c0t1d0s0

# eeprom "boot-device=rootdisk rootmirror"

Verify the correct eeprom information:

# eeprom | grep disk

Update:  The previous "vxeeprom" commands may not work for all boot proms.  If you are unable to boot to the "rootdisk" device on reboot, you should set the device alias using the "nvalias" command at the boot prom.  This can be done by first doing a "devalias" to display the PATH of each disk, and use the "nvalias" command to set the rootdisk and rootmirror alias manually.  The following is an example:

ok devalias

…

disk                     /pci@1f,4000/scsi@3/disk@0,0                       <=== disk is "rootdisk"

disk0                    /pci@1f,4000/scsi@3/disk@0,0

disk1                    /pci@1f,4000/scsi@3/disk@1,0                       <=== disk1 is "rootmirror"

…

ok nvalias rootdisk /pci@1f,4000/scsi@3/disk@0,0

ok nvalias rootmirror /pci@1f,4000/scsi@3/disk@1,0

ok boot

How to Recover from Primary Disk Failure

Grab your backup drive from the spare parts shelf with the same exact geometry as the failed drive. You do have one; don't you?

Configure system to see drive

# devfsadm     ### Prior to Solaris 8 try "# drvconfig; disks; devlinks"

Initialize the new drive, add to rootdg as "newdisk", and replace old "rootdisk" with "newdisk":

# vxdisksetup -i c0t0d0

# vxdg -g rootdg adddisk newdisk=c0t0d0

# vxdg repldisk rootdisk=newdisk

Parition the new drive exactly the same as rootmirror:

I have not figured out a way to do this automatically instead of using format.  The fmthard command will not work because it does not allow overlapping partitions.  The dd command should not be used as it also copies over the Veritas diskid.  In which case, there will be duplicate diskid's on each disk causing the system not to boot.  Please use the following procedure instead:

# format

; Enter 0 for the new drive

; Enter p for partition

; Enter p to view current partition layout

; Enter s to select the partition table of rootmirror

; Enter 1 to copy partition table of rootmirror onto new drive

; Enter l to label disk

; Enter y to continue

; Enter q to quit partition menu

; Enter q to quit format utility

Re-attach the mirror for each volume:

# vxplex att rootvol rootvol-01

# vxplex att swapvol swapvol-01

# vxplex att var var-01

# vxplex att opt opt-01

# vxplex att home home-01

 

How to Recover from Mirror Disk Failure

Grab your backup drive from the spare parts shelf with the same exact geometry as the failed drive. You do have one; don't you?

Configure system to see drive

# devfsadm     ### Prior to Solaris 8 try "# drvconfig; disks; devlinks"

Initialize the new drive, add to rootdg as "newdisk", and replace old "rootmirror" with "newdisk"

# vxdisksetup -i c0t1d0

# vxdg -g rootdg adddisk newdisk=c0t1d0

# vxdg repldisk rootmirror=newdisk

Parition the new drive exactly the same as rootdisk:

I have not figured out a way to do this automatically instead of using format.  The fmthard command will not work because it does not allow overlapping partitions.  The dd command should not be used as it also copies over the Veritas diskid.  In which case, there will be duplicate diskid's on each disk causing the system not to boot.  Please use the following procedure instead:

# format

; Enter 1 for the new drive

; Enter p for partition

; Enter p to view current partition layout

; Enter s to select the partition table of rootdisk

; Enter 0 to copy partition table of rootdisk onto new drive

; Enter l to label disk

; Enter y to continue

; Enter q to quit partition menu

; Enter q to quit format utility

Re-attach the mirror for each volume:

# vxplex att rootvol rootvol-02

# vxplex att swapvol swapvol-02

# vxplex att var var-02

# vxplex att opt opt-02

# vxplex att home home-02


Prof..... Karn 

Solaris Q Depth Setting & Associated factors

Queue Depth - SCSI storage arrays present storage to a host in the form of a LUN. LUNs have a finite set of resources available, such as the amount of data that can be stored, as well as the number of active commands that a device or LUN can process at one time. The number of active commands that can be issued before a device blocks further I/O is know as queue depth.  

Modifying the “HBA Queue Depth” is a performance tuning tip for servers that are connected to Storage Area Networks (SAN’s).  A Host Bus Adapter (HBA) is the storage equivalent of a network card and the Queue Depth parameter controls how much data is allowed to be “in flight” on the storage network from that card.

 

By default most cards default to a queue depth of 32 which is perfect for a general purpose server and prevents the SAN from getting too busy.  However, as SQL is so I/O dependent you can gain a performance boost by increasing the Queue Depth on your HBA’s to allow more I/O requests to be in-flight from that server.

Points which are need to concern in regards with Q-Depth in solaris::: 

Detecting bottlenecks in SAN and NAS

The location of a bottleneck depends upon many factors, including LUN's sharing common I/O buffers and a LUN mapped to a device with few controllers.

Solaris LUN bottlenecks

The sd_max_throttle variable sets the maximum number of commands that the SCSI sd driver will attempt to queue to a single HBA driver. The default value is 256. This variable must be set to a value less than or equal to the maximum queue depth of each LUN connected to each instance of the sd driver. If this is not done, then commands may be rejected because of a full queue condition and the sd driver instance that receives the queue full message will throttle down sd_max_throttle to 1.

LUN queue depth 

The LUN queue depth determines how many commands the HBA is willing to accept and process per LUN, if a single virtual machine is issuing IO, the QD setting applies but when multiple VM’s are simultaneously issuing IO’s to the LUN, the Disk.SchedNumReqOutstanding (DSNRO) value becomes the leading parameter.

Calculating the queue depth\Execution Throttle value

To prevent flooding the target port queue depth, the result of the 
combination of number of host paths + execution throttle value + number 
of presented LUNs through the host port must be less than the target 
port queue depth. In short T => P * q * L

T = Target Port Queue Depth

P = Paths connected to the target port

Q = Queue depth

L = number of LUN presented to the host through this port 

We can check the current "QD" settings as below::

# grep -i "max_throttle" /etc/system
set ssd:ssd_max_throttle=8
 

OR

# echo "ssd_max_throttle/D" |mdb -k
ssd_max_throttle:
ssd_max_throttle:               64

acsd102#> echo "sd_max_throttle/D" |mdb -k
sd_max_throttle:
sd_max_throttle:               256

Solaris Fiber Channel Storage

This chapter provides an overview of the Solaris Fibre Channel (FC) and Storage Multipathing software. This information will prove helpful during installation and configuration of the software.

The Solaris FC and Storage Multipathing software is integrated in the Solaris 10 OS. Whether the system that is being upgraded has prior version of the Solaris FC and Storage Multipathing software installed or not, there is no need to separately install the software package during or after the Solaris 10 OS installation. That applies to the Solaris 10 OS new (initial) install as well.

In Solaris 10 OS, fabric-connected devices are configured and made available to the host automatically during install and boot time.

---

Note - If performing an upgrade and if you want to make any FC devices unavailable after upgrade, those devices have to be manually unconfigured using "cfgadm -c unconfigure" commands. However, to make those devices permanently unavailable to the system, you may want to consider using switch zoning and/or LUN masking. The changes made by cfgadm unconfigure will not persist after a reboot unless manual configuration for fabric-connected devices has been turned on. To disable the fabric devices discovery during boot or install, please refer to Appendix A titled, Manual Configuration for Fabric Connected Devices.

---

This chapter contains the following sections:

• Software Features
• Supported Standards

---

Software Features

In general, the Solaris Fibre Channel and Storage Multipathing software enables FC connectivity for the Solaris hosts. The software resides on the server and identifies the storage and switch devices on your SAN. It allows you to attach either loop or fabric SAN storage devices while providing a standard interface with which to manage them.

Fibre Channel Software Features

The Solaris FC and Storage Multipathing software provides the following key features:

• Dynamic Storage Discovery - The Solaris FC and Storage Multipathing software automatically recognizes devices and any modifications made to device configurations. This makes devices available to the system without requiring you to reboot or manually change information in configuration files.
• Persistent Device Naming - Devices that are configured within the Solaris FC and Storage Multipathing software maintain their device naming through reboots and/or reconfiguration. The only exception to this are tape devices, found in /dev/rmt, will not change unless they are removed and later regenerated.
• FCAL Support - OpenBoot Prom (OBP) commands that are used on servers can access Fibre Channel-Arbitrated Loop (FCAL) attached storage for scanning the FC loop.
• Fabric Booting - Sun supports booting from fabric devices as well as non-fabric Fibre Channel devices. Fabric topologies with Fibre Channel switches provide higher speed, more connections, and port isolation.
• FC-HBA Library - What was previously known as the Storage Networking Industry Association (SNIA) Fibre Channel HBA(FC-HBA) library is now known as the FC-HBA library. The FC-HBA library application programming interface (API) enables management of FC HBAs and provides a standards-based interface for other applications (such as Sun StorEdge Enterprise Storage Manager) that can be used to gather information about FC HBAs.

Man pages for common FC-HBA APIs are included in the Solaris 10 Operating System. For additional information on FC specifications refer to http://www.t11.org.

Multipathing Software Features With Fibre Channel Storage

The Solaris 10 OS contains the Solaris FC and Storage Multipathing software. This is enabled by default for x86-based platforms and optional for SPARC-based platforms. The software contains the following features:

• Path Management - The Solaris FC and Storage Multipathing software dynamically manages the paths to any storage devices it supports. The addition or removal of paths to a device is done automatically when a path is brought online or removed from a service. This allows hosts configured with the Solaris FC and Storage Multipathing software to begin with a single path to a device and add more host controllers, increasing bandwidth and RAS, without changing device names or modifying applications. For Sun storage, there are no configuration files to manage or databases to keep current. For Storage other than Sun, contact your storage vendor for methods to enable support and to ensure it is qualified with the multipathing software.
• Single Device Instances - Unlike other multipathing solutions, the Solaris FC and Storage Multipathing software is fully integrated with the Solaris 10 OS. This allows the Solaris FC and Storage Multipathing software to display multipath devices as single device instances instead of as one device, or device link, per path. This reduces the cost of managing complex storage architectures, since it enables utilities, such as format(1M) or higher level applications such as the Solaris Volume Manager, to "see" one representation of a storage device instead of a separate device for each path.
• Failover Support - Implementing higher levels of RAS requires redundant host connectivity to storage devices. The Solaris FC and Storage Multipathing software manages the failure of storage paths while maintaining host I/O connectivity through available secondary paths.
• Symmetrical/Asymmetrical Device Support - The Solaris FC and Storage Multipathing software support the following disk storage devices.
• All Sun disk storage - both symmetric and asymmetric
• All T10/T11 standards complaint non-Sun symmetrical disk devices
• Many non-Sun Asymmetrical disk arrays.

Please contact your storage vendor to see if your device is supported.

In addition, T10 ALUA support has been added for those asymmetrical devices that support this T10 standard.

• I/O Load Balancing - In addition to providing simple fail over support, the Solaris FC and Storage Multipathing software can use any active paths to a storage device to send and receive I/O. With I/O routed through multiple host connections, bandwidth can be increased by the addition of host controllers. The Solaris FC and Storage Multipathing software uses a round-robin load-balancing algorithm, by which individual I/O requests are routed to active host controllers in a series, one after the other.
• Queue Depth - SCSI storage arrays present storage to a host in the form of a LUN. LUNs have a finite set of resources available, such as the amount of data that can be stored, as well as the number of active commands that a device or LUN can process at one time. The number of active commands that can be issued before a device blocks further I/O is know as queue depth. When the Solaris FC and Storage Multipathing software is enabled, a single queue is created for each LUN regardless of the number of distinct or separate paths it may have to the host.This allows the disk driver to maintain and balance 1 queue to the LUN, effectively managing queue depth. No other multipathing softwares available for the Solaris 10 OS can claim this.
• stmsboot Command - The Solaris 10 OS cannot be installed initially onto the Solaris multipathing software devices. However, the stmsboot command, which is included with the Solaris FC and Storage Multipathing software, allows you to enable the Solaris Multipathing software on the boot device after the installation has been completed for SPARC devices.
• Dynamic Reconfiguration - The Solaris FC and Storage Multipathing Software supports the Solaris 10 OS Dynamic Reconfiguration (DR).

Set / update kernel parameters in Solaris 10

Task ::

PROB_DESC: Please update kernel parameters required for MQ v7.

1. System V Semaphores- max-sem-ids : 1024, required by IBM MQV7 .  

2. System V Shared Memory- max-shm-ids: 1024, required by IBM MQV7.

3. max-file-descriptors - 10000, required by IBM MQV7 .

Solution::

Note : We have a User existing on the Server that is "mqm" , so we need to create the project by any name conventionally  with user name what I have did in Below example ie "group.mqm" & additionally we can set the unique Project ID (we have opted "100") as Solaris OS reserves 1-99 by default. Below is what  we can do easly on the fly without any reboot & it will servive across the reboot nothing is going to purge. After you have done you can list this either with "cat /etc/project" or in particular "projects -l group.mqm" .

$ projadd -U mqm -c "Kernel Setting's for MQM" -p 100 group.mqm

$ /usr/sbin/projmod -a -K "process.max-file-descriptor=(basic,10000,deny)" group.mqm

$ /usr/sbin/projmod -a -K "project.max-shm-ids=(priv,1024,deny)" group.mqm

$ /usr/sbin/projmod -a -K "project.max-sem-ids=(priv,1024,deny)" group.mqm

============Additional Switched with projadd & projmod==================

--> U Implies to set User name.

--> a

    Specify that the users, groups, attributes, or attribute

    values  specified  by the -U, -G or -K options should be

    added to the project, rather than replacing the existing

    member or attribute list.

--> c comment

-K name[=value[,value...]

Multiple -K options can be specified to set, add, remove, or substitute values on multiple keys, such as: -K key1=value1 -K "key2=(value2a),(value2b)"

Karn !!!

Creating a volume on specific disks Veritas

Creating a volume on specific disks

VxVM automatically selects the disks on which each volume resides, unless you specify otherwise. If you want a volume to be created on specific disks, you must designate those disks to VxVM. More than one disk can be specified.

To create a volume on a specific disk or disks, use the following command:

Specify the -b option if you want to make the volume immediately available for use. 

For example, to create the volume myvol01 with length 5 gigabytes on disks disk03 and disk04, use the following command:

# vxassist -b -g mydg make myvol01 5g disk03 disk04

The vxassist command allows you to specify storage attributes. These give you control over the devices, including disks and controllers, which vxassist uses to configure a volume. For example, you can specifically exclude disk mydg05:

# vxassist -b -g mydg make myvol 5g !disk05

or exclude all disks that are on controller scsi2:

# vxassist -b -g mydg make myvol1 5g !ctlr:scsi2

If you want a volume to be created using only disks from a specific disk group, use the -g option to vxassist, for example:

# vxassist -g oradg -b make oravol 20g disk10 disk11

or alternatively, use the diskgroup attribute:

# vxassist -b make appvol 20g diskgroup=appdg disk10 \   disk11

Any storage attributes that you specify for use must belong to the disk group. Otherwise, vxassist will not use them to create a volume.

You can also use storage attributes to control how vxassist uses available storage, for example, when calculating the maximum size of a volume, when growing a volume or when removing mirrors or logs from a volume. The following example excludes disks dgrp07 and dgrp08 when calculating the maximum size of RAID-5 volume that vxassist can create using the disks in the disk group dg:

# vxassist -b -g appdg maxsize layout=raid5 nlog=2 !disk07 \   !disk08

It is also possible to control how volumes are laid out on the specified storage.

Conversion of volume from one usage type to another (gen to fsgen)

Conversion of volume from one usage type to other cannot be done on the fly, it requires a volume downtime.   Lets take

a look at this output…

# vxprint -htg pstz0595-oradg -v fs01

V  NAME         RVG/VSET/CO  KSTATE   STATE    LENGTH   READPOL   PREFPLEX UTYPE

PL NAME         VOLUME       KSTATE   STATE    LENGTH   LAYOUT    NCOL/WID MODE

SD NAME         PLEX         DISK     DISKOFFS LENGTH   [COL/]OFF DEVICE   MODE

SV NAME         PLEX         VOLNAME  NVOLLAYR LENGTH   [COL/]OFF AM/NM    MODE

SC NAME         PLEX         CACHE    DISKOFFS LENGTH   [COL/]OFF DEVICE   MODE

DC NAME         PARENTVOL    LOGVOL

SP NAME         SNAPVOL      DCO

EX NAME         ASSOC        VC                       PERMS    MODE     STATE

v  fs01         -            ENABLED  ACTIVE   46137344 SELECT    fs01-01  fsgen

pl fs01-01      fs01         ENABLED  ACTIVE   46137344 STRIPE    4/256    RW

sd oraarch01-01 fs01-01      oraarch01 0       11534336 0/0       emc5_3819 ENA

sd oraarch02-01 fs01-01      oraarch02 0       11534336 1/0       emc5_3829 ENA

sd oraarch03-01 fs01-01      oraarch03 0       11534336 2/0       emc5_3816 ENA

sd oraarch04-01 fs01-01      oraarch04 0       11534336 3/0       emc5_3815 ENA

vxprint -g pstz0595-oradg  -rhmvps fs01 > fsvol.vxout

/etc/vx/bin/vxconfigbackup  pstz0595-oradg

umount/ stop / remove the volume

umount /zones/pstz0595_mounts/oraarch/fs01

vxvol -g pstz0595-oradg stop fs01

vxedit -g pstz0595-oradg -rf rm fs01

vxmake -g pstz0595-oradg  -d fsvol.vxout

vxvol -g pstz0595-oradg  start fs01

fsck -y /dev/vx/rdsk/pstz0595-oradg/fs01

mount /zones/pstz0595_mounts/oraarch/fs01

VxVM gen vs fsgen volume type

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

The usage types allow VM to make assumptions on the volume contents. fsgen assumes that there the volume contains a filesystem and gen does not. When using VM snapshots, VM will issue sync commands when its breaking a mirror off a fsgen volume. It will not do this for a gen type. Usually there is no real harm in having a file system on a gen type volume but some VM commands will use this field. With vxassist the default is fsgen. 

Also check out the contents of /usr/lib/vxvm/type.

Between, you cannot change the usage type on the fly.