From cth@sac.sfbay.sun.com Mon Jun 25 09:10:46 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5PGAjB7015463 for ; Mon, 25 Jun 2007 09:10:45 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l5PG8xNB028282; Tue, 26 Jun 2007 00:09:03 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JK700B078UZN100@brm-avmta-1.central.sun.com>; Mon, 25 Jun 2007 10:08:59 -0600 (MDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JK700IDO8UZA7E0@brm-avmta-1.central.sun.com>; Mon, 25 Jun 2007 10:08:59 -0600 (MDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l5PG8wWK007134; Mon, 25 Jun 2007 09:08:58 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5PGAdxA015458; Mon, 25 Jun 2007 09:10:39 -0700 (PDT) Received: (from cth@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l5PGAdv1015454; Mon, 25 Jun 2007 09:10:39 -0700 (PDT) Date: Mon, 25 Jun 2007 09:10:39 -0700 (PDT) From: Christopher Horne Subject: MPXIO/scsi_vhci failover-ops configuration - revisited [PSARC/2007/379 FastTrack timeout 07/05/07] To: PSARC-ext@sun.com Cc: mpxio-iteam@sun.com Message-id: <200706251610.l5PGAdv1015454@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 22297 I am sponsoring the following fasttrack for myself, requesting patch binding and a timeout of 07/05/2007. This proposal is being driven by the desire to opensource the scsi_vhci part of MPxIO. -Chris Template Version: @(#)sac_nextcase 1.63 06/14/07 SMI This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: MPXIO/scsi_vhci failover-ops configuration - revisited 1.2 Name of Document Author/Supplier: Author: Chris Horne 1.3 Date of This Document: 25 June, 2007 4. Technical Description 4.0 Background For a device that has a GUID [1] discovered on a pHCI with MPxIO enabled [2], vHCI access still depends on one of the scsi_vhci failover implementations accepting the device. The default way this occurs is for a failover implementation's "probe" function to indicate the device is supported. The scsi_vhci code needs a flexible mechanism to: A) Define the "probe" order of the failover implementations. B) Override the default probe-oriented configuration in order to: 1) establish support for a device not currently accepted under scsi_vhci or 2) override the implementation selected by "probe" or 3) disable scsi_vhci support for a device. The scsi_get_device_type_scsi_options(9F) interface defined by PSARC/1995/445 [3] provides a way to define SCSI vendor and product identification (VID/PID) specific scsi-options values. The mechanism is based on driver.conf(4) definition of a "device-type-scsi-options-list" property. In PSARC/2002/229 [4], scsi_vhci private scsi-options bit values were defined, and the "device-type-scsi-options-list" mechanism was used, to implement a failover override mechanism. This is documented in scsi_vhci(7D). As an example, to force vendor FOO product BAR to plumb with the "symmetric" failover ops and to disable support for vendor FOO product GOO, a user needs to define the following properties in scsi_vhci.conf: device-type-scsi-options-list = "FOO BAR", "symmetric-option", "FOO GOO", "disable-option"; symmetric-option=0x1000000; disable-option=0x7000000; An effort to opensource MPxIO is underway, called step0. The major goal of step0 is to make as much of the scsi_vhci source available as possible to the OpenSolaris community in order to increase awareness, encourage use, and leverage community involvement in later steps. For step0, most of the scsi_vhci source moves to the opensolaris side of the source tree, with the encumbered failover modules from EMC and LSI staying closed. The source for the following failover plugin modules will be open from the start: scsi_vhci_f_sym, scsi_vhci_f_tpgs, scsi_vhci_f_asym_sun. The following modules, which contain encumbered code, will remain on the /closed/ side of the source tree: scsi_vhci_f_asym_lsi, scsi_vhci_f_asym_emc, scsi_vhci_f_sym_emc. Decoupled from step0 delivery, we will contact EMC and LSI to try to convince them to open source the currently encumbered code. Independent of source location, a separate kernel modules is used for each failover implementation. These kernel modules are installed in the appropriate `isainfo -k` directory below the /kernel/misc/scsi_vhci. The file names used reflect the implementation provided by the kernel module. The plumbing of modules is dynamic, using ddi_modopen [5]. While full support for scsi_vhci plugins is further off, it is still a step0 goal to allow a 'motivated' OpenSolaris developer to deliver a new failover plugin by changing only scsi_vhci.conf. 4.1 Problem As part of the MPxIO opensource effort, related to the requirements above, it was noted that: A] The "probe" order is compiled in. This is not extensible. In addition, we currently need to preload failover modules on sparc platforms when the root device uses mpxio. B] Using "device-type-scsi-options-list" as an override mechanism is problematic because it requires a fixed mapping between scsi-option bit values and specific failover modules. The current mechanism is obtuse, with its indirect "symmetric-option" property reference, and it is not extensible without changing code - it requires the core scsi_vhci code to understand the scsi-options bits associated with each new failover module. PSARC/2002/229 did not specify a way to disable mpxio support (B3). The putback for PSARC/2002/229 included a SCSI_OPTIONS_DISABLE_DEV_TYPE scsi-options value of 0x7000000 for this purpose, but this was not mentioned in the case. 4.2 Proposal To establish "probe" order for (A), the proposal is to add a 'ddi-forceload' [6] definition to scsi_vhci.conf. The scsi_vhci.conf use of ddi-forceload is not part of the interface table for this case, its use is private. We are not proposing full support for third-party failover modules at this time. # NOTE: Correct operation depends on the value of # 'ddi-forceload', this value should not be changed. The # ordering of entries is from most-specific failover modules # (with a "probe" implementation that is completely VID/PID # table based), to most generic (failover modules that are # based on T10 standards like TPGS). By convention the last # part of a failover module path, after "/scsi_vhci_", is # called the "failover-module-name", which begins with "f_" # (like "f_asym_sun"). The "failover-module-name" is also used # in the override mechanism below. ddi-forceload = "misc/scsi_vhci/scsi_vhci_f_asym_sun", "misc/scsi_vhci/scsi_vhci_f_asym_lsi", "misc/scsi_vhci/scsi_vhci_f_asym_emc", "misc/scsi_vhci/scsi_vhci_f_sym_emc", "misc/scsi_vhci/scsi_vhci_f_sym", "misc/scsi_vhci/scsi_vhci_f_tpgs"; In addition to establishing "probe" precedence order, until new-boot sparc [7] delivers, the ddi-forceload definition resolves a sparc boot issue by ensuring that all failover modules are loaded prior to 'lights-out': the time when the kernel can no longer call OBP for IO services, yet the root is not mounted. To provide an override mechanism for (B), the proposal is to switch to a failover override mechanism based on the new scsi_get_device_type_string(9F) interface defined by PSARC/2006/710 [8]. This provides the same type of tuple-oriented VID/PID match as PSARC/1995/445, but permits *direct* identification of a failover module. For each tuple, the first part provides basic device identity information (vid/pid) and the second part selects the failover module by "failover-module-name". If you want to disable scsi_vhci support for a device, you can specify the special failover-module-name "NONE". This is a more direct and extensible mechanism that is not bound to compiled-in scsi-option values. The scsi_get_device_type_string(9F) interface also allows the caller to establish the name of the tuple-list: in our case "scsi-vhci-failover-override". For each failover-module-name in "scsi-vhci-failover-override" (except "NONE") there needs to be a corresponding "misc/scsi_vhci/scsi_vhci_" in the scsi_vhci.conf 'ddi-forceload' definition (A). In addition to updating scsi_vhci(7D), the "Configuring Multipathing Software" [9] documentation must be updated. 4.2.1 Example Using the example above, the new scsi_vhci.conf would look like: scsi-vhci-failover-override = "FOO BAR", "f_sym", "FOO GOO", "NONE"; 4.3 Delivery While [6] and [8] are approved, they have not yet been putback. The plan is to deliver [6] and [8] along with this case. This putback will also address the following dependent CRs: 6504975 ddi_modopen should allow open in subdirectory Class action scripts for scsi_vhci.conf are provided to convert existing scsi_vhci.conf overrides to the new representation. The only scsi_options values that have been used are 0x1000000 and 0x7000000 - the class action script based scsi_vhci.conf conversion will be limited to these values. 4.4 Interface Table 4.4.1 Interfaces removed by this case ------------------------------------------------------------------------ Interface Level Comments ------------------------------------------------------------------------ SCSI_OPTIONS_VHCI_MASK Evolving PSARC/2002/229 SCSI_OPTIONS_SYMMETRIC " " SCSI_OPTIONS_ASYMMETRIC " " SCSI_OPTIONS_SUN_T3_ASYMMETRIC " " SCSI_OPTIONS_VHCI() " " scsi_vhci(7D) use of " " device-type-scsi-options-list in scsi_vhci.conf 4.4.2 Interfaces added by this case ------------------------------------------------------------------------ Interface Level Comments ------------------------------------------------------------------------ scsi_vhci(7D) use of Committed override property scsi-vhci-failover-override based on in scsi_vhci.conf PSARC/2007/710 failover-module-name Committed Name of failover values (like "f_sym", and module used in "NONE") scsi_vhci.conf 4.5 Future Future work to discover and configure plugins in the /kernel/misc/scsi_vhci directory without requiring changes to scsi_vhci.conf should be considered after new-boot sparc [7], where it will be possible to implement readdir/ftw. If we do this, we still need to consider how to specify precedence among failover modules before we can remove ddi-forceload in scsi_vhci.conf. 4.6 References [1] Common Devid/GUID Encode Interfaces for SCSI Devices http://sac.sfbay/PSARC/2004/504 http://www.opensolaris.org/os/community/arc/caselog/2004/504 [2] Multiplexed I/O Framework http://sac.sfbay/PSARC/1999/647 http://www.opensolaris.org/os/community/arc/caselog/1999/647 MPXIO related cases: http://sac.sfbay/PSARC/1999/647/related_cases.html [3] scsi-options per device type scsi_get_device_type_scsi_options(9F) http://sac.sfbay/PSARC/1995/445 http://www.opensolaris.org/os/community/arc/caselog/1995/445 [4] MPXIO/scsi_vhci failover-ops configuration http://sac.sfbay/PSARC/2002/229 http://www.opensolaris.org/os/community/arc/caselog/2002/229 [5] ddi_modopen dynamically access a loadable kernel module http://sac.sfbay/PSARC/2005/050 http://www.opensolaris.org/os/community/arc/caselog/2005/050 [6] ddi-forceload http://sac.sfbay/PSARC/2006/708 http://www.opensolaris.org/os/community/arc/caselog/2006/708 [7] new-boot sparc http://sac.sfbay/PSARC/2006/525 http://www.opensolaris.org/os/community/arc/caselog/2006/525 [8] scsi_get_device_type_string http://sac.sfbay/PSARC/2006/710 http://www.opensolaris.org/os/community/arc/caselog/2006/710 [9] Configuring Multipathing Software http://docs.sun.com/source/819-0139/ch_4_config_multi_SW.html 4.7 New scsi_vhci(7D) man page: See A.1 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open ----------------------- ----------------------- ----------------------- A.1 scsi_vhci(7D) man page changes --- scsi_vhci.7d.orig Mon Jun 18 11:49:27 2007 +++ scsi_vhci.7d.new Fri Jun 22 12:41:23 2007 @@ -9,19 +9,18 @@ SCSI-3 devices. This driver introduces a fundamental restructuring of the Solaris device tree to enable a multipath device to be represented as single device instance rather than as an instance per physical path as in earlier Solaris versions. - The multipath SCSI target devices managed by this driver are - identified and represented by using SCSI-3 VPD page (0x83) as the - device's unit address. + The logical units (LUNs) associated multipath SCSI target devices + managed by this driver are identified and represented by using the + SCSI-3 VPD page (0x83) LUN global unique identifier (GUID) + represented as hexadecimal number (64/128 bits). Symbolic links in /dev/[r]dsk continue to adhere to the cNtNdNsN format. cN is the logical controller number assigned to this - driver instance. tN is the global unique identifier (GUID) of the - multipath target device (64/128 bits), represented as hexadecimal - numbers. + driver instance. tN is the GUID. The following is an example of a system with a A5000 storage array: /dev/rdsk/c4t200000203709C3F5d0s0 -> ../../devices/scsi_vhci/ @@ -41,51 +40,60 @@ /dev/rdsk/c1t60020F200000033939A2C2B60008D4AEd0s7 -> ../../devices/ scsi_vhci/ssd@g60020f200000033939a2c2b60008d4ae:h,raw The scsi_vhci driver receives naming and transport services from one or more physical HBA (host bus adapter) devices. To support - multi-pathing, a physical HBA driver must comply with the - multipathing services provided by this driver. + multi-pathing, a physical HBA driver must have its multipathing + enabled and comply with the multipathing services provided by this + driver. The scsi_vhci driver supports the standard functions provided by the SCSA interface. Configuration - The scsi_vhci driver can be configured by defining properties in - the scsi_vhci.conf file. + For each candidate SCSI target device, the scsi_vhci code must + identify a failover module to support the device. If a failover + module can't be identified then the device will not function under + scsi_vhci(7D) multipathing control. For SCSI target devices that + support the standard Target Port Group Select, no special special + vendor/product knowledge is needed. For other SCSI target device, + each failover module understand which devices it supports. - The scsi_vhci driver supports the following property: + When autoconfiguration does not result in the desired + configuration, a vendor/product specific override mechanism is + available. This scsi_vhci.conf base mechanism can be used to + direct a device to a specific failover module (or to indicate + that a device should not be under scsi_vhci multipathing control + via "NONE"). In scsi_vhci.conf, the property + 'scsi-vhci-failover-override' defines overrides in + scsi_get_device_type_string(9F) form. To add a third-party + (non-Sun) symmetric storage device to run under scsi_vhci (and + thereby take advantage of scsi_vhci multipathing), you add the + vendor ID and product ID for the device, as those strings are + returned by the SCSI Inquiry command. For example, to add a + device from a vendor with the ID of "Acme" and a product ID of + "MSU", you would add: - device-type-scsi-options-list - - To add a third-party (non-Sun) symmetric storage device to run - under scsi_vhci (and thereby take advantage of Solaris I/O - multipathing), you add the vendor ID and product ID for the - device, as those strings are returned by the SCSI Inquiry - command. As shipped, the scsi_vhci.conf file contains, in part: - - # device-type-scsi-options-list = - # "SUN SENA", "symmetric-option"; - # symmetric-option=0x1000000; - - For example,to add a device from a vendor with the ID of "Acme" - and a product ID of "MSU", you would add: - device-type-scsi-options-list = - "Acme MSU", "symmetric-option"; - symmetric-option=0x1000000; + "Acme MSU", "f_sym"; - In addition to "Acme," you also might want to add another entry, for example, a device from "XYZ" vendor with a product ID of "ABC:" device-type-scsi-options-list = - "Acme MSU", "symmetric-option", - "XYZ ABC", "symmetric-option"; - symmetric-option=0x1000000; + "Acme MSU", "f_sym", + "XYZ ABC", "f_sym"; + As a last override, you might want to add an entry so that + no devices from "ABC" vendor use scsi_vhci multipathing: + + device-type-scsi-options-list = + "Acme MSU", "f_sym", + "XYZ ABC", "f_sym", + "ABC ", "NONE"; + FILES /kernel/drv/sparcv9/scsi_vhci 64-bit kernel module (SPARC). @@ -112,11 +120,13 @@ SEE ALSO eeprom(1M), prtconf(1M), attributes(5), fcp(7D), fctl(7D), fp(7D), ssd(7D), scsi_abort(9F), scsi_ifgetcap(9F), scsi_pkt(9S), scsi_reset(9F), scsi_transport(9F), scsi_inquiry(9S), - scsi_extended_sense(9S) + scsi_extended_sense(9S), + mpt(7D), scsi_get_device_type_scsi_options(9F), + scsi_get_device_type_string(9F) Writing Device Drivers Small Computer System Interface-3 (SCSI-3) @@ -125,10 +135,16 @@ mpxio-disable property, which allowed you to disable Solaris I/O multipathing on a system-wide basis. This property is not present in the current release of the Solaris operating system. Multipathing is always enabled in scsi_vhci. If you want to disable multipathing, use the mechanisms provided by the HBA - drivers. See fp(7D). + drivers. See fp(7D), mpt(7D). + In previous releases, the override mechanism was based on the + scsi_get_device_type_scsi_options(9F) defined + "device-type-scsi-options-list" property. During upgrade, + scsi_vhci.conf is converted to the new form. After upgrade, a + scsi_vhci.conf modification based on the old mechanism will be + silently ignored. + In previous releases, Solaris I/O multipathing was also known as MPxIO and Sun StorEdge Traffic Manager (STMS). - A.2 scsi_vhci.conf # CDDL HEADER START # # The contents of this file are subject to the terms of the # Common Development and Distribution License (the "License"). # You may not use this file except in compliance with the License. # # You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE # or http://www.opensolaris.org/os/licensing. # See the License for the specific language governing permissions # and limitations under the License. # # When distributing Covered Code, include this CDDL HEADER in each # file and include the License file at usr/src/OPENSOLARIS.LICENSE. # If applicable, add the following below this CDDL HEADER, with the # fields enclosed by brackets "[]" replaced with your own identifying # information: Portions Copyright [yyyy] [name of copyright owner] # # CDDL HEADER END # # Copyright 2007 Sun Microsystems, Inc. All rights reserved. # Use is subject to license terms. # #pragma ident "%Z%%M% %I% %E% SMI" # name="scsi_vhci" class="root"; # # Load balancing global configuration: setting load-balance="none" will cause # all I/O to a given device (which supports multipath I/O) to occur via one # path. Setting load-balance="round-robin" will cause each path to the device # to be used in turn. # load-balance="round-robin"; # # Automatic failback configuration # possible values are auto-failback="enable" or auto-failback="disable" auto-failback="enable"; #BEGIN: FAILOVER_MODULE_BLOCK (DO NOT MOVE OR DELETE) # # Declare scsi_vhci failover module paths with 'ddi-forceload' so that # they get loaded early enough to be available for scsi_vhci root use. # # NOTE: Correct operation depends on the value of 'ddi-forceload', this # value should not be changed. The ordering of entries is from # most-specific failover modules (with a "probe" implementation that is # completely VID/PID table based), to most generic (failover modules that # are based on T10 standards like TPGS). By convention the last part of a # failover module path, after "/scsi_vhci_", is called the # "failover-module-name", which begins with "f_" (like "f_asym_sun"). The # "failover-module-name" is also used in the override mechanism below. ddi-forceload = "misc/scsi_vhci/scsi_vhci_f_asym_sun", "misc/scsi_vhci/scsi_vhci_f_asym_lsi", "misc/scsi_vhci/scsi_vhci_f_asym_emc", "misc/scsi_vhci/scsi_vhci_f_sym_emc", "misc/scsi_vhci/scsi_vhci_f_sym", "misc/scsi_vhci/scsi_vhci_f_tpgs"; # # For a device that has a GUID, discovered on a pHCI with mpxio enabled, vHCI # access also depends on one of the scsi_vhci failover modules accepting the # device. The default way this occurs is by a failover module's "probe" # implementation (sfo_device_probe) indicating the device is supported under # scsi_vhci. To override this default probe-oriented configuration in # order to # # 1) establish support for a device not currently accepted under scsi_vhci # # or 2) override the module selected by "probe" # # or 3) disable scsi_vhci support for a device # # you can add a 'scsi-vhci-failover-override' tuple, as documented in # scsi_get_device_type_string(9F). For each tuple, the first part provides # basic device identity information (vid/pid) and the second part selects # the failover module by "failover-module-name". If you want to disable # scsi_vhci support for a device, use the special failover-module-name "NONE". # Currently, for each failover-module-name in 'scsi-vhci-failover-override' # (except "NONE") there needs to be a # "misc/scsi_vhci/scsi_vhci_" in 'ddi-forceload' above. # # " 111111" # "012345670123456789012345", "failover-module-name" or "NONE" # "|-VID--||-----PID------|", # scsi-vhci-failover-override = # "STK FLEXLINE 400", "f_asym_lsi", # "SUN T4", "f_tpgs", # "CME XIRTEMMYS", "NONE"; # #END: FAILOVER_MODULE_BLOCK (DO NOT MOVE OR DELETE) From sommerfeld@sun.com Mon Jun 25 13:12:52 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5PKCpw2024366 for ; Mon, 25 Jun 2007 13:12:52 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5PKB9ET013687; Mon, 25 Jun 2007 21:11:09 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JK700507K2KGP00@brm-avmta-1.central.sun.com>; Mon, 25 Jun 2007 14:11:08 -0600 (MDT) Received: from eastmail4bur.east.Sun.COM ([129.148.13.1]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JK70048QK2J2610@brm-avmta-1.central.sun.com>; Mon, 25 Jun 2007 14:11:07 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5PKB5Tq029019; Mon, 25 Jun 2007 16:11:05 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5PKB5Dc017629; Mon, 25 Jun 2007 16:11:05 -0400 (EDT) Date: Mon, 25 Jun 2007 16:11:04 -0400 From: Bill Sommerfeld Subject: Re: MPXIO/scsi_vhci failover-ops configuration - revisited [PSARC/2007/379 FastTrack timeout 07/05/07] In-reply-to: <200706251610.l5PGAdv1015454@sac.sfbay.sun.com> To: Christopher Horne Cc: PSARC-ext@sun.com, mpxio-iteam@sun.com Message-id: <1182802264.17033.35.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200706251610.l5PGAdv1015454@sac.sfbay.sun.com> Status: RO Content-Length: 863 On Mon, 2007-06-25 at 09:10 -0700, Christopher Horne wrote: > While full support > for scsi_vhci plugins is further off, it is still a step0 goal > to allow a 'motivated' OpenSolaris developer to deliver a new > failover plugin by changing only scsi_vhci.conf. so, reading between the lines here: what's the stability level of the interface between the scsi_vhci framework and an individual plugin module? Consolidation Private? (I think that's OK for now but it should be stated explicitly). > scsi_vhci(7D) use of Committed override property > scsi-vhci-failover-override based on > in scsi_vhci.conf PSARC/2007/710 Unless I'm mistaken "2007/710" is a typo -- we haven't assigned that case number yet. I'm guessing you mean 2006/710 here. From Chris.Horne@sun.com Mon Jun 25 14:15:12 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5PLFBOO027301 for ; Mon, 25 Jun 2007 14:15:11 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l5PLDSvq001848; Mon, 25 Jun 2007 22:13:28 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JK700909MYFLM00@brm-avmta-1.central.sun.com>; Mon, 25 Jun 2007 15:13:27 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JK700412MY02260@brm-avmta-1.central.sun.com>; Mon, 25 Jun 2007 15:13:12 -0600 (MDT) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5PLDCQn009963; Mon, 25 Jun 2007 21:13:12 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JK700I01MRSRI00@mail-amer.sun.com> (original mail from Chris.Horne@Sun.COM); Mon, 25 Jun 2007 15:13:12 -0600 (MDT) Received: from sun.com ([129.150.32.191]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JK700B9LMXZO620@mail-amer.sun.com>; Mon, 25 Jun 2007 15:13:11 -0600 (MDT) Date: Mon, 25 Jun 2007 15:13:11 -0600 From: Chris Horne Subject: Re: MPXIO/scsi_vhci failover-ops configuration - revisited [PSARC/2007/379 FastTrack timeout 07/05/07] In-reply-to: <1182802264.17033.35.camel@thunk> Sender: Chris.Horne@sun.com To: Bill Sommerfeld Cc: Christopher Horne , PSARC-ext@sun.com, mpxio-iteam@sun.com Message-id: <46802FE7.8040108@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <200706251610.l5PGAdv1015454@sac.sfbay.sun.com> <1182802264.17033.35.camel@thunk> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20040414 Status: RO Content-Length: 1019 Hi Bill > On Mon, 2007-06-25 at 09:10 -0700, Christopher Horne wrote: > >> While full support >> for scsi_vhci plugins is further off, it is still a step0 goal >> to allow a 'motivated' OpenSolaris developer to deliver a new >> failover plugin by changing only scsi_vhci.conf. > > > so, reading between the lines here: what's the stability level of the > interface between the scsi_vhci framework and an individual plugin > module? Consolidation Private? (I think that's OK for now but it > should be stated explicitly). The interfaces between scsi_vhci and its plugin modules remain consolidation private. >> scsi_vhci(7D) use of Committed override property >> scsi-vhci-failover-override based on >> in scsi_vhci.conf PSARC/2007/710 > > > Unless I'm mistaken "2007/710" is a typo -- we haven't assigned that case number yet. > I'm guessing you mean 2006/710 here. Yes, 2006/710 is correct. -Chris From Chris.Horne@sun.com Wed Jun 27 10:26:49 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5RHQmQn007509 for ; Wed, 27 Jun 2007 10:26:49 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l5RHP1Z2004596; Thu, 28 Jun 2007 01:25:05 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JKB00E361PRBA00@brm-avmta-1.central.sun.com>; Wed, 27 Jun 2007 11:25:03 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JKB0030D1PKVLC0@brm-avmta-1.central.sun.com>; Wed, 27 Jun 2007 11:24:56 -0600 (MDT) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5RHOuSg022631; Wed, 27 Jun 2007 17:24:56 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JKB000010Z7SE00@mail-amer.sun.com> (original mail from Chris.Horne@Sun.COM); Wed, 27 Jun 2007 11:24:56 -0600 (MDT) Received: from [172.20.25.50] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JKB00E8W1P17KF0@mail-amer.sun.com>; Wed, 27 Jun 2007 11:24:39 -0600 (MDT) Date: Wed, 27 Jun 2007 11:23:16 -0600 From: Chris Horne Subject: Re: MPXIO/scsi_vhci failover-ops configuration - revisited [PSARC/2007/379 FastTrack timeout 07/05/07] In-reply-to: <200706251610.l5PGAdv1015454@sac.sfbay.sun.com> Sender: Chris.Horne@sun.com To: PSARC-ext@sun.com Cc: mpxio-iteam@sun.com Message-id: <46829D04.7010405@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200706251610.l5PGAdv1015454@sac.sfbay.sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061204) Status: RO Content-Length: 154 | 1.1. Project/Component Working Name: | MPXIO/scsi_vhci failover-ops configuration - revisited This case was approved at today's psarc meeting. -Chris