KGPSA-CA PCI Fibre Channel adapter
Table of Contents
General description
CHARON-AXP supports emulation of DEC-KGPSA-CA PCI Fibre Channel adapter.
Every instance of KGPSA-CA works in one of the three following modes:
- KGPSA-CA PCI Fibre Channel adapter#Fabric virtualization mode (mapping to disk images and host/SAN physical disks). This is default mode.
- Usage of "presentation mode" of external storage controllers to automatically configure KGPSA-CA disks correspondent to the LUNs provided by the external storages
- KGPSA-CA PCI Fibre Channel adapter#Pass Through mode (using a specific CHARON PCI Pass Through driver to work through the EMULEX LightPulse PCI/PCI-X/PCIe FC adapter plugged into host)
Loading KGPSA storage adapter
Syntax for loading KGPSA-CA storage adapter:
load KGPSA <name> |
Example:
load KGPSA FGA |
In AlphaStation 400 configuration use the following syntax for KGPSA-CA storage adapter loading:
load KGPSA FGA irq_bus = isa
The adapter instance name ("FGA" in the example above) is used then for parametrization, for example:
set FGA container[100]="C:\My disks\vms_distributive.vdisk" |
Numbers in the square brackets represent KGPSA-CA units. They can be in the range 0..32766, but no more than 255 units can be configured on a single controller.
By default KGPSA-CA adapter uses first available PCI slot. If instead some particular slot is needed, refer to this section for details of specific placement of PCI peripherals on CHARON Virtual Machine (VM) PCI bus.
Configuration parameters
The KGPSA-CA PCI FC adapter emulation has the following configuration parameters:
storage_controller_path_id
Parameter | storage_controller_path_id |
---|---|
Type | Text String |
Value | Instructs CHARON-AXP to create a set of virtual FC devices and connect to the virtual system through the virtual KGPSA FC Adapter. In this mode WWID and UDID values are taken from the storage controller directly. Note that some storage controllers may not support aquiring UDID, in this case this way of mapping cannot be used in case of OpenVMS (Tru64 Unix is Ok)! Syntax:
where the "Storage controller path ID" parameter is a storage (for example SAN) controller path ID. This ID can be obtained from the "Host Device Check" utility ("Storage Controllers" section). Once specified, all the disks attached to the storage are automatically mapped as disk units to CHARON-AXP. Example:
It is also possible to use wildcards for specifying the ID number: Example:
In this case CHARON will collect the LUNs from all the matching paths. This syntax works disregarding whether Windows MPIO is active or not. If it is active, CHARON-AXP uses "active" path (because it works through Windows), if Windows MPIO is OFF, CHARON-AXP selects the first matching path (and warns you in the LOG file). Note that LUNs obtained by usage of "storage_controller_path_id" parameter is not re-enumerated on reboot, so this mode is possible to use in case of shared disks clusters. |
host_bus_location
Parameter | host_bus_location |
---|---|
Type | Text String |
Value | Establish connection between virtual DEC-KGPSA-CA PCI FC adapter and physical EMULEX LightPulse PCI/PCI-X/PCIe FC adapter (pass through mode) Syntax:
where X, Y, and Z describe location of physical EMULEX LightPulse PCI/PCI-X/PCIe FC adapter in the host computer (see KGPSA-CA PCI Fibre Channel adapter#Pass Through mode for details). Example:
|
wwid
Parameter | wwid[N] N is 0..32766 (no more than 255 units) |
---|---|
Type | Text String |
Value | Sets WWID for emulated KGPSA adapter unit in case if the WWID can not be obtained directly from the device CHARON-AXP is mapped to. For example in case of disk images or local physical drives CHARON-AXP cannot get its WWID from the the host system, so it is automaticaly introduce some generated WWID. In case if this WWID is not acceptable it can be replaced with the custom one using the "wwid" parameter. Syntax:
Example:
|
container
Parameter | container[N] N is 0..32766 (no more than 255 units) |
---|---|
Type | Text String |
Value | Possible values of the parameter are strings in one of the following forms:
This parameter is initially not set, thus creating NO storage elements on the controller.. |
media_type
Parameter | media_type[N] N is 0..32766 (no more than 255 units) |
---|---|
Type | Text String |
Value | Instructs CHARON-AXP to use the supplied value as the PRODUCT field in the FC INQUIRY data returned to a software running on virtual HP Alpha system in response to FC INQUIRY command. If not specified, CHARON-AXP attempts to guess the FC INQUIRY data based on virtual FC device type and underlying container (which is specified in the corresponding container configuration parameter). Initially is not specified. Example: |
removable
Parameter | removable[N] N is 0..32766 (no more than 255 units) |
---|---|
Type | Boolean |
Value | When set to "true", the removable configuration parameter instructs CHARON-AXP to report the corresponding virtual FC device as removable. By default the removable configuration parameter is set to "false". Example: |
geometry
Parameter | geometry [N] N is 0..32766 (no more than 255 units) |
---|---|
Type | Text String |
Value | This formatted string value specifies the explicit geometry of the disk storage element. The string format is <X>”/”<Y>[“/”<Z>][“/”<B>] or <X>”,”<Y>[“,”<Z>][“,”<B>] where:
If this parameter is not set, CHARON-AXP will configure the geometry based on the most probable disk type. Initially not set. Example:
It is possible to specify each parameter independently of another one. The following syntax is used for that:
|
use_io_file_buffering
Parameter | use_io_file_buffering[N] N is 0..32766 (no more than 255 units) |
---|---|
Type | Text String |
Value | Instructs CHARON-AXP to enable host operating system I/O cache on reading/writing operations. The following values are possible:
Note this caching has a significant effect only in case of mapping to disk containers, not physical drives. When enabled, host operating system I/O cache may significantly improve I/O performance of the virtual system. At the same time maintaining I/O cache requires additional host resources (CPU and memory) which may negatively affect overall performance of the virtual system. Initially is set to "false". Example:
|
io_queue_depth
Parameter | io_queue_depth[N] N is "XXYY" number, where:
|
---|---|
Type | Numeric |
Value | Specifies KZPBA I/O requests (read or write) for a given unit in a range 2..128 Setting this parameter enables KZPBA instance to run up-to the specified numbers of I/O requests (read or write) for unit N in parallel, thus improving the performance. The default value set by controller is optimal for most of the cases. It may be needed to enlarge this number if guest OS I/O queue for a certain unit contains too much pending entries. In this case the value should be equal to an average size of the queue, collected statistically. Please do not set this parameter without clear understanding the purpose. By default parallel execution of I/O requests is disabled. Example:
|
min_n_of_threads
Parameter | min_n_of_threads |
---|---|
Type | Numeric |
Value | Instructs KZPBA I/O to reserve a given number of working threads in a range 1..64, thus improving the performance. All units of KZPBA instance share the I/O threads. The default value is equal to number of units plus 2. For optimization it is possible to set this parameter to sum of the "io_queue_depth" parameters for each unit plus 2. This assumption seems optimal for most of the cases. Please do not set this parameter without clear understanding the purpose. Example:
|
Empty disk images are created with the "MkDisk" utility.
CHARON-AXP is able to boot from disk images of any OpenVMS/Alpha and Tru64 version.
Mapping to host resources
There are 3 modes of KGPSA-CA mapping to system resources:
Mode | Description | Pros | Cons |
---|---|---|---|
KGPSA-CA PCI Fibre Channel adapter#Fabric virtualization mode | Virtual KGPSA-CA PCI FC adapter is mapped to physical disks (both local, FC and iSCSI) and disk images This is default mode, suitable for most cases |
|
|
"Presentation" mode | CHARON-AXP automatically creates/removes a set of virtual FC devices on a virtual KGPSA-CA FC adapter correspondent to available external SAN LUNs This mode is recommended in case of working with SAN that may change LUN configuration - so CHARON-AXP will reflect it on-fly w/o reconfiguration and restarting. |
|
|
This mode allows connection between virtual KGPSA-CA FC adapter and physical EMULEX LightPulse PCI/PCI-X/PCIe FC adapter plugged into host’s PCI/PCI-X/PCIe slot This mode is recommended for cluster setups that include HW Alphas |
|
|
All the described modes can be used in case of a cluster including HW Alphas and shared SAN, but pay attention that all the disks must look absolutely the same to the operating systems on all the cluster nodes, including CHARON: same WWID, same UDID (in case of OpenVMS), same size, same geometry etc.
Fabric virtualization mode
In this mode KGPSA-CA PCI FC adapter can be directly mapped to physical disks (both local and iSCSI) and disk images as shown in the following example:
|
Use only "Mapping by WWID" and "Mapping iSCSI disks" syntax in case of the mapped physical disk located on some external disk controller (SAN, etc) since the "\\.\PhysicalDrive<N>" re-enumeration may happen on CHARON host reboot.
Note that WWID and UDID is generated by CHARON-AXP in its mode. It may be important in case of shared disks cluster configurations.
See the "KGPSA-CA PCI Fibre Channel adapter#Containers" section for details.
Usage of "presentation mode"
CHARON-AXP can utilize so called "presentation mode" of the storage controller it maps to.
In this mode CHARON-AXP creates a set of virtual FC devices and connects to the SAN system through the virtual KGPSA FC adapter.
The main benefit of this mode is a flexible way of CHARON-AXP virtual disks management depending on the mapped storage controller configuration. LUN parameters of any available to CHARON host storage controller specified in CHARON-AXP configuration file via "storage_controller_path_id" parameter are automatically scanned and then assigned as ‘virtual’ FC drives which guest OS can see, no need to manually change/redefine/modify virtual LUN parameters in emulator.
For example if an extra disk has been added to the storage controller it will automatically appear as a new disk unit on the corresponding virtual KGPSA-CA virtual controller mapped to that storage controller.
In "presentation mode" CHARON-AXP supports the following operations with FC disks (similar to ones supported in KGPSA FC Pass Through mode) w/o need of CHARON-AXP restart:
- Dynamically allocation (retranslation) of new created SAN LUN to virtual Alpha configuration
- Scan and translation of SAN LUN parameters to virtual Alpha’s KGPSA DGxx: virtual drive parameters
- Propagation of SAN LUN size change to virtual Alpha’s KGPSA virtual drive parameters
- Automatically deallocation from virtual Alpha deleted SAN LUN
Example of configuration:
|
The ID number specified in the example above is a storage (for example SAN) controller path ID. This ID can be obtained from the "Host Device Check" utility ("Storage Controllers" section):
Once specified, all the disks attached to the storage are automatically mapped as disk units to CHARON-AXP.
It is also possible to use wildcards for specifying the ID number:
load KGPSA FGA storage_controller_path_id = 5008-05F3-0005-2950-*-05F3-0005-* |
In this case CHARON-AXP will collect the LUNs from all the matching paths.
This syntax works disregarding whether Windows MPIO is active or not. If it is active, CHARON-AXP uses "active" path (because it works through Windows), if Windows MPIO is OFF, CHARON-AXP selects the first matching path (and warns you in the LOG file).
Usage of LUNs in cluster configuration:
Note that PATHs (on OpenVMS level) do not affect OpenVMS cluster. What really makes sense is LUN size, geometry, WWI, etc. CHARON-AXP obtains these properties from the LUN (within the limits established by Windows), so LUNs should appear similar to all cluster members.
Note that LUNs obtained by usage of "storage_controller_path_id" parameter is not re-enumerated on reboot, so this mode is possible to use in case of shared disks clusters.
Note that the WWID and UDID are automatically obtained from disk server (SAN) in this mode - it is very convenient in case of shared disks cluster configurations. Also note that some storage controllers may not support aquiring UDID - in this case this way of mapping cannot be used in case of OpenVMS (Tru64 Unix is Ok)!
See the "Presentation mode" section for details.
Pass Through mode
The CHARON PCI Pass Through mode allows connection between virtual DEC-KGPSA-CA PCI FC adapter and physical EMULEX LightPulse PCI/PCI-X/PCIe FC adapter plugged into host’s PCI/PCI-X/PCIe slot.
Syntax:
load <controller name> host_bus_location="PCI bus X, device Y, function Z" |
Example:
load KGPSA FGA host_bus_location="PCI bus 3, device 1, function 0" |
The "host_bus_location" parameter addresses the host EMULEX LightPulse PCI/PCI-X/PCIe FC adapter in the following way:
Parameters | Description |
---|---|
"PCI bus X" | PCI bus number of the host EMULEX LightPulse PCI/PCI-X/PCIe FC adapter |
"device Y" | PCI bus device number of the host EMULEX LightPulse PCI/PCI-X/PCIe FC adapter |
"function Z" | The "function" parameter of the the host EMULEX LightPulse PCI/PCI-X/PCIe FC adapter |
The following is a list of EMULEX LightPulse PCI/PCI-X/PCIe FC adapters supported by CHARON PCI Pass Through driver and suitable for emulation of KGPSA-CA PCI FC adapter in CHARON PCI Pass Through mode:
Supported | Not Supported | Not tested |
---|---|---|
LP8000 | LPe1150 (FC2142SR, A8002A) | LPe11000 |
Also see the "host_bus_location" section for details
Installation of EMULEX LightPulse PCI/PCI-X/PCIe FC adapter driver
- Install the EMULEX LightPulse PCI/PCI-X/PCIe FC adapter (see below for a list of supported models) to some spare PCI/PCI-X/PCIe slot of the host system
- Boot a Windows operating system
- Install the EMULEX LightPulse PCI/PCI-X/PCIe FC adapter driver from the following directory "C:\Program Files\CHARON\Drivers\EMULEX_X.X.0.XXXXX" by choosing the "Install from a list or specific location (Advanced)" option and then selecting the "emulex_lp_ppt_amd64.inf" file.
- Direct Windows to use this custom driver instead of the default one:
- Type "gpedit.msc" in the "Search programs and files" field under "Start" menu, press "Enter"
- In the appearing applet choose: Administrative Templates -> System -> Device Installation -> Device Installation Restrictions -> Prevent Installation of Devices not described by other policy settings
Change the default "Not configured" to "Disabled"; press "Ok" to apply,
- Reboot the host
Collecting the parameters for mapping
There are 2 ways of getting the required parametrs for mapping virtual KGPSA-CA to EMULEX LightPulse PCI/PCI-X/PCIe FC adapter plugged into host’s PCI/PCI-X/PCIe slot:
- Usage of "HOST Device Check" utility. Follow the link for details.
- Collecting the parameters directly using "Device Manager" applet
To collect the parameters directly using "Device Manager" applet, open “Computer Management” application and select “Device Manager”:
In the right panel select desired physical EMULEX LP FibreChannel adapter under "CHARON PCI Pass Through":
Open its properties sheet by double-clicking on the selected adapter:
The “Location:” on the above picture gives X, Y, and Z for the "host_bus_location" parameter, for example:
|
Non-US-EN installations of Windows may present “Location:” string in local language, but "host_bus_location" parameter requires English notation, so the words “PCI”, “bus”, “device”, and “function” must be specified in English.
Configuration of KGPSA-CA in pass through mode
FCMGR utility description
To configure KGPSA-CA adapter in pass through mode a special SRM console utility "FCMGR" is used (it has the same functionality as the "WWIDMGR" utility of the native HP Alpha hardware).
It provides the following functionality:
Command | Description |
---|---|
| Scans connected SAN using FC adapters, discovers FC ports, storage controllers, logical units and then builds volatile FC database. The "/verbose" qualifier enables FC communication trace on console (for diagnostic and troubleshooting). |
| Displays corresponding part of volatile FC database. |
| Fills the environment variables wwid0..wwid3 and n1..n4 to identify path(s) to logical unit with the specified UDID. These variables are later used by "INIT" to create device database entries and by OpenVMS/Tru64 to get access to boot and dump disks. This command does NOT make any change to other environment variables. |
fc set {boot | dump} wwid <X> | Fills the environment variables wwid0..wwid3 and n1..n4 to identify path(s) to logical unit with the specified WWID. These variables are later used by "INIT" to create device database entries and by OpenVMS/Tru64 to get access to boot and dump disks. This command does NOT make any change to other environment variables. This parameter is useful if UDID is absent. Only right part of the displayed WWID is used for specification, for example:
|
| Clears environment variables wwid0..wwid3 and n1..n4, which automatically disable (but do NOT delete) device database entries representing FC attached devices. This command does NOT affect volatile FC database. |
Example of usage:
|
Configuration steps using FCMGR utility
Once the configuration steps described above are done, start the CHARON-AXP and wait for the P00>>> prompt.
Please refer to the following example with two FC adapters PGA and PGB defined:
|
The next step is to configure paths for the FC storage:
|
© Stromasys, 1999-2024 - All the information is provided on the best effort basis, and might be changed anytime without notice. Information provided does not mean Stromasys commitment to any features described.
Warning: links damaged, do not edit page at the moment. Atlassian support should have a look at it.