Configuring Storage-Related Policies

This chapter includes the following sections:

Configuring vHBA Templates

vHBA Template

This template is a policy that defines how a vHBA on a server connects to the SAN. It is also referred to as a vHBA SAN connectivity template.

You must include this policy in a service profile for it to take effect.

Configuring a vHBA Template

Procedure
     Command or ActionPurpose
    Step 1UCS-A# scope org org-name  

    Enters organization mode for the specified organization. To enter the root organization mode, type / as the org-name .

     
    Step 2UCS-A /org # create vhba-templ vhba-templ-name [fabric {a | b}] [fc-if vsan-name]  

    Creates a vHBA template and enters organization vHBA template mode.

     
    Step 3UCS-A /org/vhba-templ # set descr description   (Optional)

    Provides a description for the vHBA template.

     
    Step 4UCS-A /org/vhba-templ # set fabric {a | b}   (Optional)

    Specifies the fabric to use for the vHBA. If you did not specify the fabric when creating the vHBA template in Step 2, then you have the option to specify it with this command.

     
    Step 5UCS-A /org/vhba-templ # set fc-if vsan-name   (Optional)

    Specifies the Fibre Channel interface (named VSAN) to use for the vHBA template. If you did not specify the Fibre Channel interface when creating the vHBA template in Step 2, you have the option to specify it with this command.

     
    Step 6UCS-A /org/vhba-templ # set max-field-size size-num  

    Specifies the maximum size of the Fibre Channel frame payload (in bytes) that the vHBA supports.

     
    Step 7UCS-A /org/vhba-templ # set pin-group group-name  

    Specifies the pin group to use for the vHBA template.

     
    Step 8UCS-A /org/vhba-templ # set qos-policy mac-pool-name  

    Specifies the QoS policy to use for the vHBA template.

     
    Step 9UCS-A /org/vhba-templ # set stats-policy policy-name  

    Specifies the server and server component statistics threshold policy to use for the vHBA template.

     
    Step 10UCS-A /org/vhba-templ # set type {initial-template | updating-template}  

    Specifies the vHBA template update type. If you do not want vHBA instances created from this template to be automatically updated when the template is updated, use the initial-template keyword; otherwise, use the updating-template keyword to ensure that all vHBA instances are updated when the vHBA template is updated.

     
    Step 11UCS-A /org/vhba-templ # set wwpn-pool pool-name  

    Specifies the WWPN pool to use for the vHBA template.

     
    Step 12UCS-A /org/vhba-templ # commit-buffer  

    Commits the transaction to the system configuration.

     

    The following example configures a vHBA template and commits the transaction: 

    UCS-A# scope org /
UCS-A /org* # create vhba template VhbaTempFoo
UCS-A /org/vhba-templ* # set descr "This is a vHBA template example."
UCS-A /org/vhba-templ* # set fabric a
UCS-A /org/vhba-templ* # set fc-if accounting
UCS-A /org/vhba-templ* # set max-field-size 2112
UCS-A /org/vhba-templ* # set pin-group FcPinGroup12
UCS-A /org/vhba-templ* # set qos-policy policy34foo
UCS-A /org/vhba-templ* # set stats-policy ServStatsPolicy
UCS-A /org/vhba-templ* # set type updating-template
UCS-A /org/vhba-templ* # set wwpn-pool SanPool7
UCS-A /org/vhba-templ* # commit-buffer
UCS-A /org/vhba-templ #

    Redundancy Template Pairs

    Creating vNIC and vHBA template pairs enables you to group vNICs or vHBAs that belong to a specific server. For example, you can create a vNIC or a vHBA template and specify it as the Primary template, then create a different vNIC or vHBA template and specify it as the Secondary template. You can link the two templates to create a pair that share attributes that you define in the Primary template. The Secondary template inherits the attributes from the Primary template and any changes made to the Primary template are propagated to the Secondary template in the template pair. You can also modify any non-shared configurations on each individual template in the pair.

    When creating the pair, you can assign one template, for example the Primary template to Fabric A and the other template, for example the Secondary template to Fabric B or vice versa. This feature eliminates the need to configure vNIC or vHBA pairs independently using one or more templates.

    The number of vNIC and vHBA pairs that can be created using a template pair is only limited by the adapter's maximum capabilities.

    Use the Initial Template type for one time provisioning.

    Use the Updating Template type to have the Primary template drive the changes in the redundancy pair for shared configurations. See the shared configurations listed below.

    Creating vHBA Template Pairs

    Procedure
       Command or ActionPurpose
      Step 1 UCS-A/ org # create vhba-templ vhba-primary .  

      Creates a Primary vHBA template.

       
      Step 2 UCS-A/ # org vhba-templ set type updating-template .  

      Set the template type to updating, which drives the configurations in the Primary vNIC template for shared configurations to the peer vHBA template. See the shared configurations listed below.

       
      Step 3UCS-A/ # org vhba-templ [set fabric {a | b}] .  

      Specifies the fabric for the Primary vHBA template. If you specify Fabric A for the Primary vHBA template, the Secondary vHBA template must be Fabric B or vice versa.

       
      Step 4 UCS-A/ # org vhba-templ set redundancy-type primary .  

      Sets the redundancy template type as the Primary template. See the Redundancy Type descriptions below.

       
      Step 5UCS-A/ # org vhba-templ commit-buffer .  

      Commits the transaction to the system configuration.

       
      Step 6UCS-A/ # org vhba-templcreate vhba-templ vhba-secondary .  

      Creates a Secondary vHBA template.

       
      Step 7 UCS-A/ # org vhba-templ set redundancy-type secondary .  

      Sets the secondary or peer redundancy type.

      Following is a list of the Redundancy Types.

      Primary—Creates configurations that can be shared with the Secondary vHBA template. Any shared changes on the Primary vHBA template are automatically synchronized to the Secondary vHBA template.

      Secondary — All shared configurations are inherited from the Primary template.

      No Redundancy— Legacy vHBA template behavior.

      Following is a list of shared configurations

      • VSANS

      • Template Type

      • Maximum Data Field Size

      • QoS Policy

      • Stats Threshold Policy

      Following is a list of non-shared configurations:

      • Fabric ID

        Note   

        The Fabric ID must be mutually exclusive. If you assign the Primary template to Fabric A, then Fabric B is automatically assigned to the Secondary template as part of the synchronization from the Primary template.

      • WWPN Pool

      • Description

      • Pin Group Policy

       
      Step 8UCS-A/ # org vhba-templ commit-buffer .  

      Commits the transaction to the system configuration.

       
      Step 9UCS-A/ # org vhba-templ vhba primary.  

      Sets the Primary vHBA template as a redundancy pair template.

       
      Step 10UCS-A/ # org vhba-templ scope vhba template vhba primary.  

      Accesses the primary vhba template.

       
      Step 11UCS-A/ # org vhba-templ set redundancy peer-template-name vhba-secondary.  

      Sets the Secondary vHBA template as the peer to the Primary vHBA template.

       
      Step 12UCS-A/ # org vhba-templ commit-buffer .  

      Commits the transaction to the system configuration.

       

      The following example configures a vHBA redundancy template pair and commits the transaction: 

      UCS-A /org* # create vhba-template vhba-primary
UCS-A /org/vhba-templ* # set type updating-template
UCS-A /org/vhba-templ* # set fabric a
UCS-A /org/vhba-templ* # set redundancy-type primary
UCS-A /org/vhba-templ* # commit-buffer
UCS-A /org/vhba-templ* # create vhba-template vhba-secondary
UCS-A /org/vhba-templ* # set redundancy-peer vhba-primary
UCS-A /org/vhba-templ* # commit-buffer
      What to Do Next

      After you create the vHBA redundancy template pair, you can use the redundancy template pair to create redundancy vHBA pairs for any service profile in the same organization or sub- organization.

      Undo vHBA Template Pairs

      You can undo the vHBA template pair by changing the Peer Redundancy Template so that there is no peer template for the Primary or the Secondary template. When you undo a vHBA template pair, the corresponding vHBA pairs also becomes undone.

      Procedure
         Command or ActionPurpose
        Step 1UCS-A /org # scope vhba-templ template1.  

        Specifies the name of the vHBA template that you want to undo from the template pair.

         
        Step 2UCS-A /org/ vhba-templ # set redundancy-type no redundancy.  

        Removes the paring between the peer Primary or Secondary redundancy template used to perform the template pairing.

         
        Step 3UCS-A /org/vhba-templ* # commit-buffer .  

        Commits the transaction to the system configuration.

         

        The following example shows how to undo a template pairing: 

        UCS-A /org # scope vhba-templ template1
UCS-A /org/vhba-templ # set redundancy-type no-redundancy
UCS-A /org/vhba-templ* # commit buffer

        Deleting a vHBA Template

        Procedure
           Command or ActionPurpose
          Step 1UCS-A# scope org org-name  

          Enters organization mode for the specified organization. To enter the root organization mode, type / as the org-name .

           
          Step 2UCS-A /org # delete vhba-templ vhba-templ-name  

          Deletes the specified vHBA template.

           
          Step 3UCS-A /org # commit-buffer  

          Commits the transaction to the system configuration.

           

          The following example deletes the vHBA template named VhbaTempFoo and commits the transaction: 

          UCS-A# scope org /
UCS-A /org # delete vhba template VhbaTempFoo
UCS-A /org* # commit-buffer
UCS-A /org #

          Configuring Fibre Channel Adapter Policies

          Ethernet and Fibre Channel Adapter Policies

          These policies govern the host-side behavior of the adapter, including how the adapter handles traffic. For example, you can use these policies to change default settings for the following:

          • Queues

          • Interrupt handling

          • Performance enhancement

          • RSS hash

          • Failover in a cluster configuration with two fabric interconnects


          Note

          For Fibre Channel adapter policies, the values displayed by Cisco UCS Manager may not match those displayed by applications such as QLogic SANsurfer. For example, the following values may result in an apparent mismatch between SANsurfer and Cisco UCS Manager:

          • Max LUNs Per Target—SANsurfer has a maximum of 256 LUNs and does not display more than that number. Cisco UCS Manager supports a higher maximum number of LUNs.

          • Link Down Timeout—In SANsurfer, you configure the timeout threshold for link down in seconds. In Cisco UCS Manager, you configure this value in milliseconds. Therefore, a value of 5500 ms in Cisco UCS Manager displays as 5s in SANsurfer.

          • Max Data Field Size—SANsurfer has allowed values of 512, 1024, and 2048. Cisco UCS Manager allows you to set values of any size. Therefore, a value of 900 in Cisco UCS Manager displays as 512 in SANsurfer.

          • LUN Queue Depth—The LUN queue depth setting is available for Windows system FC adapter policies. Queue depth is the number of commands that the HBA can send and receive in a single transmission per LUN. Windows Storport driver sets this to a default value of 20 for physical miniports and to 250 for virtual miniports. This setting adjusts the initial queue depth for all LUNs on the adapter. Valid range for this value is 1 to 254. The default LUN queue depth is 20. This feature only works with Cisco UCS Manager version 3.1(2) and higher.

          • IO TimeOut Retry—When the target device is not responding to an IO request within the specified timeout, the FC adapter will abort the pending command then resend the same IO after the timer expires. The FC adapter valid range for this value is 1 to 59 seconds. The default IO retry timeout is 5 seconds. This feature only works with Cisco UCS Manager version 3.1(2) and higher.

          Operating System Specific Adapter Policies

          By default, Cisco UCS provides a set of Ethernet adapter policies and Fibre Channel adapter policies. These policies include the recommended settings for each supported server operating system. Operating systems are sensitive to the settings in these policies. Storage vendors typically require non-default adapter settings. You can find the details of these required settings on the support list provided by those vendors.

          Important:

          We recommend that you use the values in these policies for the applicable operating system. Do not modify any of the values in the default policies unless directed to do so by Cisco Technical Support.

          However, if you are creating an Ethernet adapter policy for a Windows OS (instead of using the default Windows adapter policy), you must use the following formulas to calculate values that work with Windows:

          • Completion Queues = Transmit Queues + Receive Queues
          • Interrupt Count = (Completion Queues + 2) rounded up to nearest power of 2

          For example, if Transmit Queues = 1 and Receive Queues = 8 then:

          • Completion Queues = 1 + 8 = 9
          • Interrupt Count = (9 + 2) rounded up to the nearest power of 2 = 16

          Configuring a Fibre Channel Adapter Policy

          Procedure
             Command or ActionPurpose
            Step 1UCS-A# scope org org-name  

            Enters organization mode for the specified organization. To enter the root organization mode, type / as the org-name .

             
            Step 2UCS-A /org # create fc-policy policy-name  

            Creates the specified Fibre Channel adapter policy and enters organization Fibre Channel policy mode.

             
            Step 3UCS-A /org/fc-policy # set descr description   (Optional)

            Provides a description for the policy.

            Note   

            If your description includes spaces, special characters, or punctuation, you must begin and end your description with quotation marks. The quotation marks will not appear in the description field of any show command output.

             
            Step 4UCS-A /org/fc-policy # set error-recovery {fcp-error-recovery {disabled | enabled} | link-down-timeout timeout-msec | port-down-io-retry-count retry-count | port-down-timeout timeout-msec}   (Optional)

            Configures the Fibre Channel error recovery.

             
            Step 5UCS-A /org/fc-policy # set interrupt mode {intx | msi | msi-x}}   (Optional)

            Configures the driver interrupt mode.

             
            Step 6UCS-A /org/fc-policy # set port {io-throttle-count throttle-count | max-luns max-num}   (Optional)

            Configures the Fibre Channel port.

             
            Step 7UCS-A /org/fc-policy # set port-f-logi {retries retry-count | timeout timeout-msec}   (Optional)

            Configures the Fibre Channel port fabric login (FLOGI).

             
            Step 8UCS-A /org/fc-policy # set port-p-logi {retries retry-count | timeout timeout-msec}   (Optional)

            Configures the Fibre Channel port-to-port login (PLOGI).

             
            Step 9UCS-A /org/fc-policy # set recv-queue {count count | ring-size size-num}   (Optional)

            Configures the Fibre Channel receive queue.

             
            Step 10UCS-A /org/fc-policy # set scsi-io {count count | ring-size size-num}   (Optional)

            Configures the Fibre Channel SCSI I/O.

             
            Step 11UCS-A /org/fc-policy # set trans-queue ring-size size-num}   (Optional)

            Configures the Fibre Channel transmit queue.

             
            Step 12UCS-A /org/fc-policy # commit-buffer  

            Commits the transaction to the system configuration.

             

            The following example configures a Fibre Channel adapter policy and commits the transaction: 

            UCS-A# scope org /
UCS-A /org* # create fc-policy FcPolicy42
UCS-A /org/fc-policy* # set descr "This is a Fibre Channel adapter policy example."
UCS-A /org/fc-policy* # set error-recovery error-detect-timeout 2500
UCS-A /org/fc-policy* # set port max-luns 4
UCS-A /org/fc-policy* # set port-f-logi retries 250
UCS-A /org/fc-policy* # set port-p-logi timeout 5000
UCS-A /org/fc-policy* # set recv-queue count 1
UCS-A /org/fc-policy* # set scsi-io ring-size 256
UCS-A /org/fc-policy* # set trans-queue ring-size 256
UCS-A /org/fc-policy* # commit-buffer
UCS-A /org/fc-policy #

            Deleting a Fibre Channel Adapter Policy

            Procedure
               Command or ActionPurpose
              Step 1UCS-A# scope org org-name  

              Enters organization mode for the specified organization. To enter the root organization mode, type / as the org-name .

               
              Step 2UCS-A /org # delete fc-policy policy-name  

              Deletes the specified Fibre Channel adapter policy.

               
              Step 3UCS-A /org # commit-buffer  

              Commits the transaction to the system configuration.

               

              The following example deletes the Fibre Channel adapter policy named FcPolicy42 and commits the transaction: 

              UCS-A# scope org /
UCS-A /org # delete fc-policy FcPolicy42
UCS-A /org* # commit-buffer
UCS-A /org #

              Configuring the Default vHBA Behavior Policy

              Default vHBA Behavior Policy

              Default vHBA behavior policy allow you to configure how vHBAs are created for a service profile. You can choose to create vHBAs manually, or you can allow them to be created automatically.

              You can configure the default vHBA behavior policy to define how vHBAs are created. This can be one of the following:

              • None—Cisco UCS Manager does not create default vHBAs for a service profile. All vHBAs must be explicitly created.

              • HW Inherit—If a service profile requires vHBAs and none have been explicitly defined, Cisco UCS Manager creates the required vHBAs based on the adapter installed in the server associated with the service profile.


              Note

              If you do not specify a default behavior policy for vHBAs, none is used by default.

              Configuring a Default vHBA Behavior Policy

              Procedure
                 Command or ActionPurpose
                Step 1UCS-A# scope org / 

                Enters the root organization mode.

                 
                Step 2UCS-A/org # scope vhba-beh-policy 

                Enters default vHBA behavior policy mode.

                 
                Step 3UCS-A/org/vhba-beh-policy # set action {hw-inherit [template_name name] | none} 

                Specifies the default vHBA behavior policy. This can be one of the following:

                • hw-inherit—If a service profile requires vHBAs and none have been explicitly defined, Cisco UCS Manager creates the required vHBAs based on the adapter installed in the server associated with the service profile.

                  If you specify hw-inherit, you can also specify a vHBA template to create the vHBAs.

                • none—Cisco UCS Manager does not create default vHBAs for a service profile. All vHBAs must be explicitly created.

                 
                Step 4UCS-A/org/vhba-beh-policy # commit-buffer 

                Commits the transaction to the system configuration.

                 

                This example shows how to set the default vHBA behavior policy to hw-inherit. 

                UCS-A # scope org /
UCS-A/org # scope vhba-beh-policy
UCS-A/org/vhba-beh-policy # set action hw-inherit
UCS-A/org/vhba-beh-policy* # commit-buffer
UCS-A/org/vhba-beh-policy #

                Configuring SAN Connectivity Policies

                About the LAN and SAN Connectivity Policies

                Connectivity policies determine the connections and the network communication resources between the server and the LAN or SAN on the network. These policies use pools to assign MAC addresses, WWNs, and WWPNs to servers and to identify the vNICs and vHBAs that the servers use to communicate with the network.


                Note

                We do not recommend that you use static IDs in connectivity policies, because these policies are included in service profiles and service profile templates and can be used to configure multiple servers.

                Privileges Required for LAN and SAN Connectivity Policies

                Connectivity policies enable users without network or storage privileges to create and modify service profiles and service profile templates with network and storage connections. However, users must have the appropriate network and storage privileges to create connectivity policies.

                Privileges Required to Create Connectivity Policies

                Connectivity policies require the same privileges as other network and storage configurations. For example, you must have at least one of the following privileges to create connectivity policies:

                • admin—Can create LAN and SAN connectivity policies

                • ls-server—Can create LAN and SAN connectivity policies

                • ls-network—Can create LAN connectivity policies

                • ls-storage—Can create SAN connectivity policies

                Privileges Required to Add Connectivity Policies to Service Profiles

                After the connectivity policies have been created, a user with ls-compute privileges can include them in a service profile or service profile template. However, a user with only ls-compute privileges cannot create connectivity policies.

                Interactions between Service Profiles and Connectivity Policies

                You can configure the LAN and SAN connectivity for a service profile through either of the following methods:

                • LAN and SAN connectivity policies that are referenced in the service profile

                • Local vNICs and vHBAs that are created in the service profile

                • Local vNICs and a SAN connectivity policy

                • Local vHBAs and a LAN connectivity policy

                Cisco UCS maintains mutual exclusivity between connectivity policies and local vNIC and vHBA configuration in the service profile. You cannot have a combination of connectivity policies and locally created vNICs or vHBAs. When you include a LAN connectivity policy in a service profile, all existing vNIC configuration is erased, and when you include a SAN connectivity policy, all existing vHBA configuration in that service profile is erased.

                Creating a SAN Connectivity Policy

                Procedure
                   Command or ActionPurpose
                  Step 1UCS-A# scope org org-name  

                  Enters the organization mode for the specified organization. To enter the root organization mode, enter / as the org-name.

                   
                  Step 2UCS-A /org # create san-connectivity-policy policy-name  

                  Creates the specified SAN connectivity policy, and enters organization network control policy mode.

                  This name can be between 1 and 16 alphanumeric characters. You cannot use spaces or any special characters other than - (hyphen), _ (underscore), : (colon), and . (period), and you cannot change this name after the object is saved.

                   
                  Step 3UCS-A /org/lan-connectivity-policy # set descr policy-name   (Optional)

                  Adds a description to the policy. We recommend that you include information about where and how the policy should be used.

                  Enter up to 256 characters. You can use any characters or spaces except ` (accent mark), \ (backslash), ^ (carat), " (double quote), = (equal sign), > (greater than), < (less than), or ' (single quote).

                   
                  Step 4UCS-A /org/service-profile # set identity {dynamic-uuid {uuid | derived} | dynamic-wwnn {wwnn | derived} | uuid-pool pool-name | wwnn-pool pool-name}  

                  Specifies how the server acquires a UUID or WWNN. You can do one of the following:

                  • Create a unique UUID in the form nnnnnnnn-nnnn-nnnn-nnnnnnnnnnnn

                  • Derive the UUID from the one burned into the hardware at manufacture

                  • Use a UUID pool

                  • Create a unique WWNN in the form hh : hh : hh : hh : hh : hh : hh : hh

                  • Derive the WWNN from one burned into the hardware at manufacture

                  • Use a WWNN pool

                   
                  Step 5UCS-A /org/lan-connectivity-policy # commit-buffer  

                  Commits the transaction to the system configuration.

                   

                  The following example shows how to create a SAN connectivity policy named SanConnect242 and commit the transaction:

                  UCS-A# scope org /
UCS-A /org* # create san-connectivity-policy SanConnect242
UCS-A /org/san-connectivity-policy* # set descr "SAN connectivity policy"
UCS-A /org/san-connectivity-policy* # set identity wwnn-pool SanPool7
UCS-A /org/san-connectivity-policy* # commit-buffer
UCS-A /org/san-connectivity-policy #
                  What to Do Next

                  Add one or more vHBAs and/or initiator groups to this SAN connectivity policy.

                  Creating a vHBA for a SAN Connectivity Policy

                  If you are continuing from Creating a SAN Connectivity Policy, begin this procedure at Step 3.

                  Procedure
                     Command or ActionPurpose
                    Step 1UCS-A# scope org org-name  

                    Enters the organization mode for the specified organization. To enter the root organization mode, enter / as the org-name.

                     
                    Step 2UCS-A /org # scope san-connectivity-policy policy-name  

                    Enters SAN connectivity policy mode for the specified SAN connectivity policy.

                     
                    Step 3UCS-A /org/san-connectivity-policy # create vhba vhba-name [fabric {a | b}] [fc-if fc-if-name]  

                    Creates a vHBA for the specified SAN connectivity policy and enters vHBA mode.

                    This name can be between 1 and 16 alphanumeric characters. You cannot use spaces or any special characters other than - (hyphen), _ (underscore), : (colon), and . (period), and you cannot change this name after the object is saved.

                     
                    Step 4UCS-A /org/san-connectivity-policy/vhba # set adapter-policy policy-name  

                    Specifies the adapter policy to use for the vHBA.

                     
                    Step 5UCS-A /org/san-connectivity-policy/vhba # set identity {dynamic-wwpn {wwpn | derived} | wwpn-pool wwn-pool-name}  

                    Specifies the WWPN for the vHBA.

                    You can set the storage identity using one of the following options:

                    • Create a unique WWPN in the form hh:hh:hh:hh:hh:hh:hh:hh.

                      You can specify a WWPN in the range from 20:00:00:00:00:00:00:00 to 20:FF:FF:FF:FF:FF:FF:FF or from 50:00:00:00:00:00:00:00 to 5F:FF:FF:FF:FF:FF:FF:FF.

                      If you want the WWPN to be compatible with Cisco MDS Fibre Channel switches, use the WWPN template 20:00:00:25:B5:XX:XX:XX.

                    • Derive the WWPN from one burned into the hardware at manufacture.

                    • Assign a WWPN from a WWN pool.

                     
                    Step 6UCS-A /org/san-connectivity-policy/vhba # set max-field-size size-num  

                    Specifies the maximum size of the Fibre Channel frame payload (in bytes) that the vHBA supports.

                    Enter an integer between 256 and 2112. The default is 2048.

                     
                    Step 7UCS-A /org/san-connectivity-policy/vhba # set order {order-num | unspecified}  

                    Specifies the PCI scan order for the vHBA.

                     
                    Step 8UCS-A /org/san-connectivity-policy/vhba # set pers-bind {disabled | enabled}  

                    Disables or enables persistent binding to Fibre Channel targets.

                     
                    Step 9UCS-A /org/san-connectivity-policy/vhba # set pin-group group-name  

                    Specifies the SAN pin group to use for the vHBA.

                     
                    Step 10UCS-A /org/san-connectivity-policy/vhba # set qos-policy policy-name  

                    Specifies the QoS policy to use for the vHBA.

                     
                    Step 11UCS-A /org/san-connectivity-policy/vhba # set stats-policy policy-name  

                    Specifies the statistics threshold policy to use for the vHBA.

                     
                    Step 12UCS-A /org/san-connectivity-policy/vhba # set template-name policy-name  

                    Specifies the vHBA template to use for the vHBA. If you choose to use a vHBA template for the vHBA, you must still complete all of the configuration not included in the vHBA template, including Steps 4, 7, and 8.

                     
                    Step 13UCS-A /org/san-connectivity-policy/vhba # set vcon {1 | 2 | 3 | 4 | any}  

                    Assigns the vHBA to one or all virtual network interface connections.

                     
                    Step 14UCS-A /org/san-connectivity-policy/vhba # commit-buffer  

                    Commits the transaction to the system configuration.

                     

                    The following example shows how to configure a vHBA for a SAN connectivity policy named SanConnect242 and commit the transaction:

                    UCS-A# scope org /
UCS-A /org* # scope san-connectivity-policy SanConnect242
UCS-A /org/san-connectivity-policy* # create vhba vhba3 fabric a
UCS-A /org/san-connectivity-policy/vhba* # set adapter-policy AdaptPol2
UCS-A /org/san-connectivity-policy/vhba* # set identity wwpn-pool SanPool7
UCS-A /org/san-connectivity-policy/vhba* # set max-field-size 2112
UCS-A /org/san-connectivity-policy/vhba* # set order 0
UCS-A /org/san-connectivity-policy/vhba* # set pers-bind enabled
UCS-A /org/san-connectivity-policy/vhba* # set pin-group FcPinGroup12
UCS-A /org/san-connectivity-policy/vhba* # set qos-policy QosPol5
UCS-A /org/san-connectivity-policy/vhba* # set stats-policy StatsPol2
UCS-A /org/san-connectivity-policy/vhba* # set template-name SanConnPol3
UCS-A /org/san-connectivity-policy/vhba* # set vcon any
UCS-A /org/san-connectivity-policy/vhba* # commit-buffer
UCS-A /org/san-connectivity-policy/vhba #
                    What to Do Next

                    If desired, add another vHBA or an initiator group to the SAN connectivity policy. If not, include the policy in a service profile or service profile template.

                    Deleting a vHBA from a SAN Connectivity Policy

                    Procedure
                       Command or ActionPurpose
                      Step 1UCS-A# scope org org-name  

                      Enters the organization mode for the specified organization. To enter the root organization mode, enter / as the org-name.

                       
                      Step 2UCS-A /org # scope san-connectivity-policy policy-name  

                      Enters SAN connectivity policy mode for the specified SAN connectivity policy.

                       
                      Step 3UCS-A /org/san-connectivity-policy # delete vHBA vhba-name 

                      Deletes the specified vHBA from the SAN connectivity policy.

                       
                      Step 4UCS-A /org/san-connectivity-policy # commit-buffer  

                      Commits the transaction to the system configuration.

                       

                      The following example shows how to delete a vHBA named vHBA3 from a SAN connectivity policy named SanConnect242 and commit the transaction:

                      UCS-A# scope org /
UCS-A /org # scope san-connectivity-policy SanConnect242
UCS-A /org/san-connectivity-policy # delete vHBA vHBA3
UCS-A /org/san-connectivity-policy* # commit-buffer
UCS-A /org/san-connectivity-policy #

                      Creating an Initiator Group for a SAN Connectivity Policy

                      If you are continuing from Creating a SAN Connectivity Policy, begin this procedure at Step 3.

                      Procedure
                         Command or ActionPurpose
                        Step 1UCS-A# scope org org-name  

                        Enters the organization mode for the specified organization. To enter the root organization mode, enter / as the org-name.

                         
                        Step 2UCS-A /org # scope san-connectivity-policy policy-name  

                        Enters SAN connectivity policy mode for the specified SAN connectivity policy.

                         
                        Step 3UCS-A /org/san-connectivity-policy # create initiator-group group-name fc 

                        Creates the specified initiator group for Fibre Channel zoning and enters initiator group mode.

                        This name can be between 1 and 16 alphanumeric characters. You cannot use spaces or any special characters other than - (hyphen), _ (underscore), : (colon), and . (period), and you cannot change this name after the object is saved.

                         
                        Step 4UCS-A /org/san-connectivity-policy/initiator-group # create initiator vhba-name  

                        Creates the specified vHBA initiator in the initiator group.

                        If desired, repeat this step to add a second vHBA initiator to the group.

                         
                        Step 5UCS-A /org/san-connectivity-policy/initiator-group # set storage-connection-policy policy-name  

                        Associates the specified storage connection policy with the SAN connectivity policy.

                        Note   

                        This step assumes that you want to associate an existing storage connection policy to associate with the SAN connectivity policy. If you do, continue with Step 10. If you want to create a local storage definition for this policy instead, continue with Step 6.

                         
                        Step 6UCS-A /org/san-connectivity-policy/initiator-group/storage-connection-def # create storage-target wwpn  

                        Creates a storage target endpoint with the specified WWPN, and enters storage target mode.

                         
                        Step 7UCS-A /org/san-connectivity-policy/initiator-group/storage-connection-def/storage-target # set target-path {a | b}  

                        Specifies which fabric interconnect is used for communications with the target endpoint.

                         
                        Step 8UCS-A /org/san-connectivity-policy/initiator-group/storage-connection-def/storage-target # set target-vsan vsan  

                        Specifies which VSAN is used for communications with the target endpoint.

                         
                        Step 9UCS-A /org/san-connectivity-policy/initiator-group # commit-buffer  

                        Commits the transaction to the system configuration.

                         

                        The following example shows how to configure an initiator group named initGroupZone1 with two initiators for a a SAN connectivity policy named SanConnect242, configure a local storage connection policy definition named scPolicyZone1, and commit the transaction: 

                        UCS-A# scope org /
UCS-A /org* # scope san-connectivity-policy SanConnect242
UCS-A /org/san-connectivity-policy # create initiator-group initGroupZone1 fc
UCS-A /org/san-connectivity-policy/initiator-group* # set zoning-type sist
UCS-A /org/san-connectivity-policy/initiator-group* # create initiator vhba1
UCS-A /org/san-connectivity-policy/initiator-group* # create initiator vhba2
UCS-A /org/san-connectivity-policy/initiator-group* # create storage-connection-def scPolicyZone1
UCS-A /org/san-connectivity-policy/initiator-group/storage-connection-def* # create storage-target 
20:10:20:30:40:50:60:70
UCS-A /org/san-connectivity-policy/initiator-group/storage-connection-def/storage-target* # set 
target-path a
UCS-A /org/san-connectivity-policy/initiator-group/storage-connection-def/storage-target* # set 
target-vsan default
UCS-A /org/san-connectivity-policy/initiator-group* # commit-buffer
UCS-A /org/san-connectivity-policy/initiator-group #
                        What to Do Next

                        If desired, add another initiator group or a vHBA to the SAN connectivity policy. If not, include the policy in a service profile or service profile template.

                        Deleting an Initiator Group from a SAN Connectivity Policy

                        Procedure
                           Command or ActionPurpose
                          Step 1UCS-A# scope org org-name  

                          Enters the organization mode for the specified organization. To enter the root organization mode, enter / as the org-name.

                           
                          Step 2UCS-A /org # scope san-connectivity-policy policy-name  

                          Enters SAN connectivity policy mode for the specified SAN connectivity policy.

                           
                          Step 3UCS-A /org/san-connectivity-policy # delete initiator-group group-name 

                          Deletes the specified initiator group from the SAN connectivity policy.

                           
                          Step 4UCS-A /org/san-connectivity-policy # commit-buffer  

                          Commits the transaction to the system configuration.

                           

                          The following example shows how to delete an initiator group named initGroup3 from a SAN connectivity policy named SanConnect242 and commit the transaction:

                          UCS-A# scope org /
UCS-A /org # scope san-connectivity-policy SanConnect242
UCS-A /org/san-connectivity-policy # delete initiator-group initGroup3
UCS-A /org/san-connectivity-policy* # commit-buffer
UCS-A /org/san-connectivity-policy #

                          Deleting a SAN Connectivity Policy

                          If you delete a SAN connectivity policy that is included in a service profile, it also deletes all vHBAs from that service profile and disrupts SAN data traffic for the server associated with the service profile.

                          Procedure
                             Command or ActionPurpose
                            Step 1UCS-A# scope org org-name  

                            Enters the organization mode for the specified organization. To enter the root organization mode, enter / as the org-name.

                             
                            Step 2UCS-A /org # delete san-connectivity-policy policy-name  

                            Deletes the specified SAN connectivity policy.

                             
                            Step 3UCS-A /org # commit-buffer  

                            Commits the transaction to the system configuration.

                             

                            The following example shows how to delete a SAN connectivity policy named SanConnect52 from the root organization and commit the transaction: 

                            UCS-A# scope org /
UCS-A /org # delete san-connectivity-policy SanConnect52
UCS-A /org* # commit-buffer
UCS-A /org #