Cisco UCS Manager CLI Configuration Guide, Release 1.3(1)
Configuring Server-Related Policies
Download this chapter
Configuring Server-Related PoliciesConfiguring Server-Related Policies
Download the complete book
CLI_Config_Guide_1_3_1.pdfCLI_Config_Guide_1_3_1.pdf (PDF - 4 MB)
 Feedback

Contents

Configuring Server-Related Policies

This chapter includes the following sections:

Configuring BIOS Settings

Server BIOS Settings

Cisco UCS provides two methods for making global modifications to the BIOS settings on servers in an instance. You can create one or more BIOS policies that include a specific grouping of BIOS settings that match the needs of a server or set of servers, or you can use the default BIOS settings for a specific server platform.

Both the BIOS policy and the default BIOS settings for a server platform enable you to fine tune the BIOS settings for options such as the following:

Main Server Settings

  • Quiet boot

  • Resume on AC power loss

  • Front panel lockout

Processor Settings

  • Intel TurboBoost Technology

  • Enhanced Intel SpeedStep

  • Intel Hyperthreading Technology

  • Intel Virtualization Technology

  • Processor C3 report

  • Processor C6 report

Intel-Directed I/O

  • Intel VT for directed I/O

  • Interrupt remap

  • Coherency support

  • ATS Support

  • Pass Through DMA

RAS Memory

  • Memory RAS configuration

  • NUMA Optimized

  • Mirroring mode

  • LV DDR mode

Depending upon the needs of the data center, you can combine both of these options in a Cisco UCS instance, or you can use only one of them. You can also use Cisco UCS Manager to view the actual BIOS settings on a server and determine whether they are meeting current needs.


Note

Cisco UCS Manager pushes BIOS configuration changes through a BIOS policy or default BIOS settings to the CIMC buffer. These changes remain in the buffer until the server is rebooted.

If you change a BIOS policy, you must reboot any servers associated with service profiles that include the policy for the changes to take effect.

If you change the default BIOS settings, those changes are applied to servers upon association with service profiles that do not include a BIOS policy or when the server is rebooted. Changes to the default BIOS settings do not affect servers that are already associated with service profiles.

BIOS Policy

The BIOS policy is a policy that automates the configuration of BIOS settings for a server or group of servers. You can create global BIOS policies available to all servers in the root organization, or you can create BIOS policies in sub-organizations that are only available to that hierarchy.

To use a BIOS policy, do the following:


  • Create the BIOS policy in Cisco UCS Manager

  • Assign the BIOS policy to one or more service profiles

  • Associate the service profile with a server

During service profile association, Cisco UCS Manager modifies the BIOS settings on the server to match the configuration in the BIOS policy. If you do not create and assign a BIOS policy to a service profile, the server uses the default BIOS settings for that server platform.

Default BIOS Settings

Default BIOS settings are applicable to all servers of a specific type that do not have a BIOS policy included in their service profiles. These settings are available only in the root organization and are global. Only one set of BIOS settings can exist for each server platform supported by Cisco UCS.

Cisco UCS Manager applies these server platform-specific BIOS settings as follows:


  • The service profile associated with a server does not include a BIOS policy

  • The BIOS policy is configured with the platform-default option for a specific setting

You can modify the default BIOS settings provided by Cisco UCS Manager. However, any changes to the default BIOS settings apply to all servers of that particular type or platform. If you want to modify the BIOS settings for only certain servers, we recommend that you use a BIOS policy.

Creating a BIOS Policy

If you change a BIOS policy, you must reboot any servers associated with service profiles that include the policy for the changes to take effect.

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

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

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

Creates a BIOS policy with the specified policy name, and enters org BIOS policy mode.

 
Step 3UCS-A /org/bios-policy # set quiet-boot-config quiet-boot {disabled | enabled | platform-default}  

(Optional) Determines what the BIOS displays during Power On Self-Test (POST). This can be one of the following:


  • disabled—The BIOS displays the logo screen.

  • enabled—The BIOS does not display any messages during boot.

  • platform-default—The BIOS uses the value for this attribute contained in the BIOS defaults for the server type and vendor.

 
Step 4UCS-A /org/bios-policy # set resume-ac-on-power-loss-config resume-action {stay-off | last-state | reset | platform-default}  

(Optional) Determines how the server behaves when power is restored after an unexpected power loss. This can be one of the following:


  • stay-off—The server remains off until manually powered on.

  • last-state—The server is powered on and the system attempts to restore its last state.

  • reset—The server is powered on and automatically reset.

  • platform-default—The server uses the value for this attribute contained in the BIOS defaults for the server type and vendor.

 
Step 5UCS-A /org/bios-policy # set front-panel-lockout-config front-panel-lockout {disabled | enabled | platform-default}  

(Optional) Specifies whether the power and reset buttons on the front panel are ignored by the server. This can be one of the following:


  • disabled—The power and reset buttons on the front panel are active and can be used to affect the server.

  • enabled—The power and reset buttons are locked out. The server can only be reset or powered on or off from the CIMC GUI.

  • platform-default—The server uses the value for this attribute contained in the BIOS defaults for the server type and vendor.

 
Step 6UCS-A /org/bios-policy # set intel-turbo-boost-config turbo-boost {disabled | enabled | platform-default}  

(Optional) Specifies whether the processor uses Intel Turbo Boost Technology, which allows the processor to automatically increase its frequency if it is running below power, temperature, or voltage specifications. This can be one of the following:


  • disabled—The processor never increases its frequency automatically.

  • enabled—The processor utilizes Turbo Boost Technology if required.

  • platform-default—The processor uses the value for this attribute contained in the BIOS defaults for the server type and vendor.

 
Step 7UCS-A /org/bios-policy # set enhanced-intel-speedstep-config speed-step {disabled | enabled | platform-default}  

(Optional) Specifies whether the processor uses Enhanced Intel SpeedStep Technology that allows the system to dynamically adjust processor voltage and core frequency, which can result in decreased average power consumption and decreased average heat production. This can be one of the following:


  • disabled—The processor never dynamically adjusts its voltage or frequency.

  • enabled—The processor utilizes Enhanced Intel SpeedStep Technology and enables all supported processor sleep states to further conserve power. Contact your operating system vendor to make sure the operating system supports this feature.

  • platform-default—The processor uses the value for this attribute contained in the BIOS defaults for the server type and vendor.

 
Step 8UCS-A /org/bios-policy # set hyper-threading-config hyper-threading {disabled | enabled | platform-default}  

(Optional) Specifies whether the processor uses Intel Hyper-Threading Technology, which allows multithreaded software applications to execute threads in parallel within each processor. This can be one of the following:


  • disabled—The processor does not permit hyperthreading.

  • enabled—The processor allows for the parallel execution of multiple threads. Contact your operating system vendor to make sure the operating system supports this feature.

  • platform-default—The processor uses the value for this attribute contained in the BIOS defaults for the server type and vendor.

 
Step 9UCS-A /org/bios-policy # set intel-vt-config vt {disabled | enabled | platform-default}  

(Optional) Specifies whether the processor uses Intel Virtualization Technology, which allows a platform to run multiple operating systems and applications in independent partitions. This can be one of the following:


  • disabled—The processor does not permit virtualization.

  • enabled—The processor allows multiple operating systems in independent partitions.

  • platform-default—The processor uses the value for this attribute contained in the BIOS defaults for the server type and vendor.

Note   

If you change this option, you must power cycle the server before the setting takes effect.

 
Step 10UCS-A /org/bios-policy # set processor-c3-report-config processor-c3-report {acpi-c2 | acpi-c2 | disabled | platform-default}  

(Optional) Determines whether the processor sends the C3 report to the operating system. This can be one of the following:


  • acpi-c2—The processor sends the C3 report using the ACPI C2 format.

  • acpi-c3—The processor sends the C3 report using the ACPI C3 format.

  • disabled—The processor does not send the C3 report.

  • platform-default—The processor uses the value for this attribute contained in the BIOS defaults for the server type and vendor.

 
Step 11UCS-A /org/bios-policy # set processor-c6-report-config processor-report {disabled | enabled | platform-default}  

(Optional) Determines whether the processor sends the C6 report to the operating system. This can be one of the following:


  • disabled—The processor does not send the C6 report.

  • enabled—The processor sends the C6 report.

  • platform-default—The processor uses the value for this attribute contained in the BIOS defaults for the server type and vendor.

 
Step 12UCS-A /org/bios-policy # set intel-vt-directed-io-config vtd {disabled | enabled | platform-default}  

(Optional) Specifies whether the processor uses Intel Virtualization Technology for Directed I/O. This can be one of the following:


  • disabled—The processor does not use virtualization technology.

  • enabled—The processor uses virtualization technology.

  • platform-default—The processor uses the value for this attribute contained in the BIOS defaults for the server type and vendor.

 
Step 13UCS-A /org/bios-policy # set intel-vt-directed-io-config interrupt-remapping {disabled | enabled | platform-default}  

(Optional) Specifies whether the processor supports Intel VT-d Interrupt Remapping. This can be one of the following:


  • disabled—The processor does not support remapping.

  • enabled—The processor uses VT-d Interrupt Remapping as required.

  • platform-default—The processor uses the value for this attribute contained in the BIOS defaults for the server type and vendor.

 
Step 14UCS-A /org/bios-policy # set intel-vt-directed-io-config coherency-support {disabled | enabled | platform-default}  

(Optional) Specifies whether the processor supports Intel VT-d Coherency. This can be one of the following:


  • disabled—The processor does not support coherency.

  • enabled—The processor uses VT-d Coherency as required.

  • platform-default—The processor uses the value for this attribute contained in the BIOS defaults for the server type and vendor.

 
Step 15UCS-A /org/bios-policy # set intel-vt-directed-io-config ats-support {disabled | enabled | platform-default}  

(Optional) Specifies whether the processor supports Intel VT-d Address Translation Services (ATS). This can be one of the following:


  • disabled—The processor does not support ATS.

  • enabled—The processor uses VT-d ATS as required.

  • platform-default—The processor uses the value for this attribute contained in the BIOS defaults for the server type and vendor.

 
Step 16UCS-A /org/bios-policy # set intel-vt-directed-io-config passthrough-dma {disabled | enabled | platform-default}  

(Optional) Specifies whether the processor supports Intel VT-d Pass-through DMA. This can be one of the following:


  • disabled—The processor does not support pass-through DMA.

  • enabled—The processor uses VT-d Pass-through DMA as required.

  • platform-default—The processor uses the value for this attribute contained in the BIOS defaults for the server type and vendor.

 
Step 17UCS-A /org/bios-policy # set memory-ras-config ras-config {lockstep | maximum performance | mirroring | platform-default}  

(Optional) Specifies the memory reliability, availability and serviceability (RAS) configuration. This can be one of the following:


  • lockstep—If the DIMM pairs in the server have an identical type, size, and organization and are populated across the SMI channels, you can enable lockstep mode to minimize memory access latency and provide better performance. Lockstep is enabled by default for B400 servers.

  • maximum performance—System performance is optimized.

  • mirroring—System reliability is optimized by using half the system memory as backup.

  • platform-default—The processor uses the value for this attribute contained in the BIOS defaults for the server type and vendor.

 
Step 18UCS-A /org/bios-policy # set numa-config numa-optimization {disabled | enabled | platform-default}  

(Optional) Specifies whether the BIOS supports NUMA. This can be one of the following:


  • disabled—The BIOS does not support NUMA.

  • enabled—The BIOS includes the ACPI tables that are required for NUMA-aware operating systems. If you enable this option, the system must disable Inter-Socket Memory interleaving on some platforms.

  • platform-default—The processor uses the value for this attribute contained in the BIOS defaults for the server type and vendor.

 
Step 19UCS-A /org/bios-policy # set memory-mirroring-mode mirroring-mode {intersocket | intrasocket | platform-default}  

(Optional) Specifies memory mirroring, which enhances system reliability by keeping two identical data images in memory. This can be one of the following:


  • intersocket—Memory is mirrored between two Integrated Memory Controllers (IMCs) across CPU sockets.

  • intrasocket—One IMC is mirrored with another IMC in the same socket.

  • platform-default—The processor uses the value for this attribute contained in the BIOS defaults for the server type and vendor.

 
Step 20UCS-A /org/bios-policy # set lv-dimm-support-config lv-ddr-mode {performance-mode | power-saving-mode | platform-default}  

(Optional) Specifies whether the system prioritizes low voltage or high frequency memory operations. This can be one of the following:


  • performance-mode—The system prioritizes high frequency operations over low voltage operations.

  • power-saving-mode—The system prioritizes low voltage memory operations over high frequency memory operations. This mode may lower memory frequency in order to keep the voltage low.

  • platform-default—The processor uses the value for this attribute contained in the BIOS defaults for the server type and vendor.

 
Step 21UCS-A /org/bios-policy # set console-redir-config console-redir {disabled | platform-default | serial-port-a | serial-port-b}  

(Optional) Specifies whether a serial port can be used for server management tasks. This can be one of the following:


  • disabled—Serial ports cannot be used for management tasks.

  • platform-default—The processor uses the value for this attribute contained in the BIOS defaults for the server type and vendor.

  • serial-port-a—Serial port A is configured for management tasks.

  • serial-port-b—Serial port B is configured for management tasks.

 
Step 22UCS-A /org/bios-policy # set console-redir-config baud-rate {115200 | 57600| 38400 | 19200 | 9600}  

(Optional) If a serial port can be used for management tasks, set the serial port transmission speed so that it matches the rate of the remote terminal application. This can be one of the following:


  • 115200

  • 57600

  • 38400

  • 19200

  • 9600

  • platform-default—The processor uses the value for this attribute contained in the BIOS defaults for the server type and vendor.

 
Step 23UCS-A /org/bios-policy # commit-buffer  

Commits the transaction to the system configuration.

 

The following example creates a BIOS policy under the root organization and commits the transaction: 

UCS-A# scope org /
UCS-A /org # create bios-policy biosPolicy3
UCS-A /org/bios-policy* # set numa-config numa-optimization enabled 
UCS-A /org/bios-policy* # commit-buffer 
UCS-A /org/bios-policy #

Modifying BIOS Defaults

If you change the default BIOS settings, those changes are applied to servers upon association with service profiles that do not include a BIOS policy or when the server is rebooted. Changes to the default BIOS settings do not affect servers that are already associated with service profiles.

Procedure
 Command or ActionPurpose
Step 1UCS-A# scope system  

Enters system mode.

 
Step 2UCS-A /system # scope server-defaults  

Enters server defaults mode.

 
Step 3UCS-A /system/server-defaults # show platform  

(Optional) Displays platform descriptions for all servers.

 
Step 4UCS-A /system/server-defaults # scope platform platform-description  

Enters server defaults mode for the server specified. For the platform-description argument, enter the entire server description as displayed by the show platform command.

 
Step 5UCS-A /system/server-defaults/platform # scope bios-settings 

Enters server defaults BIOS settings mode for the server.

 
Step 6UCS-A /system/server-defaults/platform/bios-settings # set quiet-boot-config quiet-boot {disabled | enabled | platform-default}  

(Optional) Determines what the BIOS displays during Power On Self-Test (POST). This can be one of the following:


  • disabled—The BIOS displays the logo screen.

  • enabled—The BIOS does not display any messages during boot.

  • platform-default—The BIOS uses the value for this attribute contained in the BIOS defaults for the server type and vendor.

 
Step 7UCS-A /system/server-defaults/platform/bios-settings # set resume-ac-on-power-loss-config resume-action {stay-off | last-state | reset | platform-default}  

(Optional) Determines how the server behaves when power is restored after an unexpected power loss. This can be one of the following:


  • stay-off—The server remains off until manually powered on.

  • last-state—The server is powered on and the system attempts to restore its last state.

  • reset—The server is powered on and automatically reset.

  • platform-default—The server uses the value for this attribute contained in the BIOS defaults for the server type and vendor.

 
Step 8UCS-A /system/server-defaults/platform/bios-settings # set front-panel-lockout-config front-panel-lockout {disabled | enabled | platform-default}  

(Optional) Specifies whether the power and reset buttons on the front panel are ignored by the server. This can be one of the following:


  • disabled—The power and reset buttons on the front panel are active and can be used to affect the server.

  • enabled—The power and reset buttons are locked out. The server can only be reset or powered on or off from the CIMC GUI.

  • platform-default—The server uses the value for this attribute contained in the BIOS defaults for the server type and vendor.

 
Step 9UCS-A /system/server-defaults/platform/bios-settings # set intel-turbo-boost-config turbo-boost {disabled | enabled | platform-default}  

(Optional) Specifies whether the processor uses Intel Turbo Boost Technology, which allows the processor to automatically increase its frequency if it is running below power, temperature, or voltage specifications. This can be one of the following:


  • disabled—The processor never increases its frequency automatically.

  • enabled—The processor utilizes Turbo Boost Technology if required.

  • platform-default—The processor uses the value for this attribute contained in the BIOS defaults for the server type and vendor.

 
Step 10UCS-A /system/server-defaults/platform/bios-settings # set enhanced-intel-speedstep-config speed-step {disabled | enabled | platform-default}  

(Optional) Specifies whether the processor uses Enhanced Intel SpeedStep Technology that allows the system to dynamically adjust processor voltage and core frequency, which can result in decreased average power consumption and decreased average heat production. This can be one of the following:


  • disabled—The processor never dynamically adjusts its voltage or frequency.

  • enabled—The processor utilizes Enhanced Intel SpeedStep Technology and enables all supported processor sleep states to further conserve power. Contact your operating system vendor to make sure the operating system supports this feature.

  • platform-default—The processor uses the value for this attribute contained in the BIOS defaults for the server type and vendor.

 
Step 11UCS-A /system/server-defaults/platform/bios-settings # set hyper-threading-config hyper-threading {disabled | enabled | platform-default}  

(Optional) Specifies whether the processor uses Intel Hyper-Threading Technology, which allows multithreaded software applications to execute threads in parallel within each processor. This can be one of the following:


  • disabled—The processor does not permit hyperthreading.

  • enabled—The processor allows for the parallel execution of multiple threads. Contact your operating system vendor to make sure the operating system supports this feature.

  • platform-default—The processor uses the value for this attribute contained in the BIOS defaults for the server type and vendor.

 
Step 12UCS-A /system/server-defaults/platform/bios-settings # set intel-vt-config vt {disabled | enabled | platform-default}  

(Optional) Specifies whether the processor uses Intel Virtualization Technology, which allows a platform to run multiple operating systems and applications in independent partitions. This can be one of the following:


  • disabled—The processor does not permit virtualization.

  • enabled—The processor allows multiple operating systems in independent partitions.

  • platform-default—The processor uses the value for this attribute contained in the BIOS defaults for the server type and vendor.

Note   

If you change this option, you must power cycle the server before the setting takes effect.

 
Step 13UCS-A /system/server-defaults/platform/bios-settings # set processor-c3-report-config processor-c3-report {acpi-c2 | acpi-c2 | disabled | platform-default}  

(Optional) Determines whether the processor sends the C3 report to the operating system. This can be one of the following:


  • acpi-c2—The processor sends the C3 report using the ACPI C2 format.

  • acpi-c3—The processor sends the C3 report using the ACPI C3 format.

  • disabled—The processor does not send the C3 report.

  • platform-default—The processor uses the value for this attribute contained in the BIOS defaults for the server type and vendor.

 
Step 14UCS-A /system/server-defaults/platform/bios-settings # set processor-c6-report-config processor-report {disabled | enabled | platform-default}  

(Optional) Determines whether the processor sends the C6 report to the operating system. This can be one of the following:


  • disabled—The processor does not send the C6 report.

  • enabled—The processor sends the C6 report.

  • platform-default—The processor uses the value for this attribute contained in the BIOS defaults for the server type and vendor.

 
Step 15UCS-A /system/server-defaults/platform/bios-settings # set intel-vt-directed-io-config vtd {disabled | enabled | platform-default}  

(Optional) Specifies whether the processor uses Intel Virtualization Technology for Directed I/O. This can be one of the following:


  • disabled—The processor does not use virtualization technology.

  • enabled—The processor uses virtualization technology.

  • platform-default—The processor uses the value for this attribute contained in the BIOS defaults for the server type and vendor.

 
Step 16UCS-A /system/server-defaults/platform/bios-settings # set intel-vt-directed-io-config interrupt-remapping {disabled | enabled | platform-default}  

(Optional) Specifies whether the processor supports Intel VT-d Interrupt Remapping. This can be one of the following:


  • disabled—The processor does not support remapping.

  • enabled—The processor uses VT-d Interrupt Remapping as required.

  • platform-default—The processor uses the value for this attribute contained in the BIOS defaults for the server type and vendor.

 
Step 17UCS-A /system/server-defaults/platform/bios-settings # set intel-vt-directed-io-config coherency-support {disabled | enabled | platform-default}  

(Optional) Specifies whether the processor supports Intel VT-d Coherency. This can be one of the following:


  • disabled—The processor does not support coherency.

  • enabled—The processor uses VT-d Coherency as required.

  • platform-default—The processor uses the value for this attribute contained in the BIOS defaults for the server type and vendor.

 
Step 18UCS-A /system/server-defaults/platform/bios-settings # set intel-vt-directed-io-config ats-support {disabled | enabled | platform-default}  

(Optional) Specifies whether the processor supports Intel VT-d Address Translation Services (ATS). This can be one of the following:


  • disabled—The processor does not support ATS.

  • enabled—The processor uses VT-d ATS as required.

  • platform-default—The processor uses the value for this attribute contained in the BIOS defaults for the server type and vendor.

 
Step 19UCS-A /system/server-defaults/platform/bios-settings # set intel-vt-directed-io-config passthrough-dma {disabled | enabled | platform-default}  

(Optional) Specifies whether the processor supports Intel VT-d Pass-through DMA. This can be one of the following:


  • disabled—The processor does not support pass-through DMA.

  • enabled—The processor uses VT-d Pass-through DMA as required.

  • platform-default—The processor uses the value for this attribute contained in the BIOS defaults for the server type and vendor.

 
Step 20UCS-A /system/server-defaults/platform/bios-settings # set memory-ras-config ras-config {lockstep | maximum performance | mirroring | platform-default}  

(Optional) Specifies the memory reliability, availability and serviceability (RAS) configuration. This can be one of the following:


  • lockstep—If the DIMM pairs in the server have an identical type, size, and organization and are populated across the SMI channels, you can enable lockstep mode to minimize memory access latency and provide better performance. Lockstep is enabled by default for B400 servers.

  • maximum performance—System performance is optimized.

  • mirroring—System reliability is optimized by using half the system memory as backup.

  • platform-default—The processor uses the value for this attribute contained in the BIOS defaults for the server type and vendor.

 
Step 21UCS-A /system/server-defaults/platform/bios-settings # set numa-config numa-optimization {disabled | enabled | platform-default}  

(Optional) Specifies whether the BIOS supports NUMA. This can be one of the following:


  • disabled—The BIOS does not support NUMA.

  • enabled—The BIOS includes the ACPI tables that are required for NUMA-aware operating systems. If you enable this option, the system must disable Inter-Socket Memory interleaving on some platforms.

  • platform-default—The processor uses the value for this attribute contained in the BIOS defaults for the server type and vendor.

 
Step 22UCS-A /system/server-defaults/platform/bios-settings # set memory-mirroring-mode mirroring-mode {intersocket | intrasocket | platform-default}  

(Optional) Specifies memory mirroring, which enhances system reliability by keeping two identical data images in memory. This can be one of the following:


  • intersocket—Memory is mirrored between two Integrated Memory Controllers (IMCs) across CPU sockets.

  • intrasocket—One IMC is mirrored with another IMC in the same socket.

  • platform-default—The processor uses the value for this attribute contained in the BIOS defaults for the server type and vendor.

 
Step 23UCS-A /system/server-defaults/platform/bios-settings # set lv-dimm-support-config lv-ddr-mode {performance-mode | power-saving-mode | platform-default}  

(Optional) Specifies whether the system prioritizes low voltage or high frequency memory operations. This can be one of the following:


  • performance-mode—The system prioritizes high frequency operations over low voltage operations.

  • power-saving-mode—The system prioritizes low voltage memory operations over high frequency memory operations. This mode may lower memory frequency in order to keep the voltage low.

  • platform-default—The processor uses the value for this attribute contained in the BIOS defaults for the server type and vendor.

 
Step 24UCS-A /system/server-defaults/platform/bios-settings # set console-redir-config console-redir {disabled | platform-default | serial-port-a | serial-port-b}  

(Optional) Specifies whether a serial port can be used for server management tasks. This can be one of the following:


  • disabled—Serial ports cannot be used for management tasks.

  • platform-default—The processor uses the value for this attribute contained in the BIOS defaults for the server type and vendor.

  • serial-port-a—Serial port A is configured for management tasks.

  • serial-port-b—Serial port B is configured for management tasks.

 
Step 25UCS-A /system/server-defaults/platform/bios-settings # set console-redir-config baud-rate {115200 | 57600| 38400 | 19200 | 9600}  

(Optional) If a serial port can be used for management tasks, set the serial port transmission speed so that it matches the rate of the remote terminal application. This can be one of the following:


  • 115200

  • 57600

  • 38400

  • 19200

  • 9600

  • platform-default—The processor uses the value for this attribute contained in the BIOS defaults for the server type and vendor.

 
Step 26UCS-A /system/server-defaults/platform/bios-settings # commit-buffer  

Commits the transaction to the system configuration.

 

The following example shows how to change the NUMA default BIOS setting for a platform and commits the transaction: 

UCS-A# scope system
UCS-A /system # scope server-defaults 
UCS-A /system/server-defaults # show platform 

Platform:
    Product Name Vendor     Model      Revision
    ------------ ---------- ---------- --------
    Cisco B200-M1
                 Cisco Systems, Inc.
                            N20-B6620-1
                                       0

UCS-A /system/server-defaults # scope platform 'Cisco Systems Inc' N20-B6620-1 0
UCS-A /system/server-defaults/platform # scope bios-settings 
UCS-A /system/server-defaults/platform/bios-settings # set numa-config numa-optimization disabled
UCS-A /system/server-defaults/platform/bios-settings* # commit-buffer 
UCS-A /system/server-defaults/platform/bios-settings #

Viewing the Actual BIOS Settings for a Server

Follow this procedure to see the actual BIOS settings on a server.

Procedure
 Command or ActionPurpose
Step 1UCS-A# scope server chassis-id / server-id  

Enters chassis server mode for the specified server.

 
Step 2UCS-A /chassis/server # scope bios  

Enters BIOS mode for the specified server.

 
Step 3UCS-A /chassis/server/bios # scope bios-settings  

Enters BIOS settings mode for the specified server.

 
Step 4UCS-A /chassis/server/bios/bios-settings # show setting  

Displays the BIOS setting. Enter show ? to display a list of allowed values for setting.

 

The following example displays a BIOS setting for blade 3 in chassis 1:

UCS-A# scope server 1/3
UCS-A /chassis/server # scope bios
UCS-A /chassis/server/bios # scope  bios-settings
UCS-A /chassis/server/bios/bios-settings # show intel-vt-config
 
Intel Vt Config:
    Vt
    --
    Enabled

UCS-A /chassis/server/bios/bios-settings #

Configuring Boot Policies

Boot Policy

The boot policy determines the following:


  • Configuration of the boot device

  • Location from which the server boots

  • Order in which boot devices are invoked

For example, you can choose to have associated servers boot from a local device, such as a local disk or CD-ROM (VMedia), or you can select a SAN boot or a LAN (PXE) boot.

You must include this policy in a service profile, and that service profile must be associated with a server for it to take effect. If you do not include a boot policy in a service profile, the server uses the default settings in the BIOS to determine the boot order.

Important:

Changes to a boot policy may be propagated to all servers created with an updating service profile template that includes that boot policy. Reassociation of the service profile with the server to rewrite the boot order information in the BIOS is auto-triggered.

Guidelines

When you create a boot policy, you can add one or more of the following to the boot policy and specify their boot order:

Boot type

Description

SAN boot

Boots from an operating system image on the SAN. You can specify a primary and a secondary SAN boot. If the primary boot fails, the server attempts to boot from the secondary.

We recommend that you use a SAN boot, because it offers the most service profile mobility within the system. If you boot from the SAN when you move a service profile from one server to another, the new server boots from the exact same operating system image. Therefore, the new server appears to be the exact same server to the network.

LAN boot

Boots from a centralized provisioning server. It is frequently used to install operating systems on a server from that server.

Local disk boot

If the server has a local drive, boots from that drive.

Note   

Cisco UCS Manager does not differentiate between the types of local drives. If an operating system has been installed on more than one local drive or on an internal USB drive (eUSB), you cannot specify which of these local drives the server should use as the boot drive.

Virtual media boot

Mimics the insertion of a physical CD-ROM disk (read-only) or floppy disk (read-write) into a server. It is typically used to manually install operating systems on a server.


Note
The default boot order is as follows:

  1. Local disk boot

  2. LAN boot

  3. Virtual media read-only boot

  4. Virtual media read-write boot

Configuring a Boot Policy

You can also create a local boot policy that is restricted to a service profile or service profile template. However, we recommend that you create a global boot policy that can be included in multiple service profiles or service profile templates.

Before You Begin

If you are creating a boot policy that boots the server from a SAN LUN and you require reliable SAN boot operations, you must first remove all local disks from servers associated with a service profile that includes the boot 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 boot-policy policy-name [purpose {operational | utility}]  

Creates a boot policy with the specified policy name, and enters organization boot policy mode.

When you create the boot policy, specify the operational option. This ensures that the server boots from the operating system installed on the server. The utility options is reserved and should only be used if instructed to do so by a Cisco representative.

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

Provides a description for the boot policy.

Note   

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

 
Step 4UCS-A /org/boot-policy # set reboot-on-update {no | yes}  

Specifies whether the servers using this boot policy are automatically rebooted after you make changes to the boot order.

 
Step 5UCS-A /org/boot-policy # commit-buffer  

Commits the transaction to the system configuration.

 

The following example creates a boot policy named boot-policy-LAN, provides a description for the boot policy, specifies that servers using this policy will not be automatically rebooted when the boot order is changed, and commits the transaction: 

UCS-A# scope org /
UCS-A /org* # create boot-policy boot-policy-LAN purpose operational
UCS-A /org/boot-policy* # set descr "Boot policy that boots from the LAN."
UCS-A /org/boot-policy* # set reboot-on-update no
UCS-A /org/boot-policy* # commit-buffer
UCS-A /org/boot-policy #
What to Do Next

Configure one or more of the following boot options for the boot policy and set their boot order:


  • LAN Boot—Boots from a centralized provisioning server. It is frequently used to install operating systems on a server from that server.

    If you choose the LAN Boot option, continue to Configuring a LAN Boot for a Boot Policy.

  • Storage Boot— Boots from an operating system image on the SAN. You can specify a primary and a secondary SAN boot. If the primary boot fails, the server attempts to boot from the secondary.

    We recommend that you use a SAN boot, because it offers the most service profile mobility within the system. If you boot from the SAN, when you move a service profile from one server to another, the new server boots from exactly the same operating system image. Therefore, the new server appears to be exactly the same server to the network.

    If you choose the Storage Boot option, continue to Configuring a Storage Boot for a Boot Policy.

  • Virtual Media Boot—Mimics the insertion of a physical CD into a server. It is typically used to manually install operating systems on a server.

    If you choose the Virtual Media boot option, continue to Configuring a Virtual Media Boot for a Boot Policy.


Tip

We recommend that the boot order in a boot policy include either a local disk or a SAN LUN, but not both, to avoid the possibility of the server booting from the wrong storage type. If you configure a local disk and a SAN LUN for the boot order storage type and the operating system or logical volume manager (LVM) is configured incorrectly, the server may boot from the local disk rather than the SAN LUN.

For example, on a server with Red Hat Linux installed, where the LVM is configured with default LV names and the boot order is configured with a SAN LUN and a local disk, Linux reports that there are two LVs with the same name and boots from the LV with the lowest SCSI ID, which could be the local disk.

Include the boot policy in a service profile and/or template.

Configuring a LAN Boot for a Boot Policy

Before You Begin

Create a boot policy to contain the LAN boot configuration.


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 # scope boot-policy policy-name  

Enters organization boot policy mode for the specified boot policy.

 
Step 3UCS-A /org/boot-policy # create lan  

Creates a LAN boot for the boot policy and enters organization boot policy LAN mode.

 
Step 4UCS-A /org/boot-policy/lan # set order {1 | 2 | 3 | 4}  

Specifies the boot order for the LAN boot.

 
Step 5UCS-A /org/boot-policy/lan # create path {primary | secondary}  

Creates a primary or secondary LAN boot path and enters organization boot policy LAN path mode.

 
Step 6UCS-A /org/boot-policy/lan/path # set vnic vnic-name  

Specifies the vNIC to use for the LAN path to the boot image.

 
Step 7UCS-A /org/boot-policy/lan/path # commit-buffer  

Commits the transaction to the system configuration.

 

The following example enters the boot policy named lab2-boot-policy, creates a LAN boot for the policy, sets the boot order to 2, creates primary and secondary paths using the vNICs named vNIC1 and vNIC2 , and commits the transaction:

UCS-A# scope org /
UCS-A /org* # scope boot-policy lab2-boot-policy
UCS-A /org/boot-policy* # create lan
UCS-A /org/boot-policy/lan* # set order 2
UCS-A /org/boot-policy/lan* # create path primary
UCS-A /org/boot-policy/lan/path* # set vnic vNIC1
UCS-A /org/boot-policy/lan/path* # exit
UCS-A /org/boot-policy/lan* # create path secondary
UCS-A /org/boot-policy/lan/path* # set vnic vNIC2
UCS-A /org/boot-policy/lan/path* # commit-buffer 
UCS-A /org/boot-policy/lan/path #
What to Do Next

Include the boot policy in a service profile and/or template.

Configuring a Storage Boot for a Boot Policy

Before You Begin

Create a boot policy to contain the storage boot configuration.


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 # scope boot-policy policy-name  

Enters organization boot policy mode for the specified boot policy.

 
Step 3UCS-A /org/boot-policy # create storage  

Creates a storage boot for the boot policy and enters organization boot policy storage mode.

 
Step 4UCS-A /org/boot-policy/storage # set order {1 | 2 | 3 | 4}  

Sets the boot order for the storage boot.

 
Step 5UCS-A /org/boot-policy/storage # create {local | san-image {primary | secondary}  

Creates a local or SAN image storage location, and if the san-image option is specified, enters organization boot policy storage SAN image mode.

The use of the terms primary or secondary boot devices does not imply a boot order. The effective order of boot devices within the same device class is determined by PCIe bus scan order.

 
Step 6UCS-A /org/boot-policy/storage/san-image # set vhba vhba-name  

Specifies the vHBA to be used for the storage boot.

 
Step 7UCS-A /org/boot-policy/storage/san-image # create path {primary | secondary}  

Creates a primary or secondary storage boot path and enters organization boot policy SAN path mode.

The use of the terms primary or secondary boot devices does not imply a boot order. The effective order of boot devices within the same device class is determined by PCIe bus scan order.

 
Step 8UCS-A /org/boot-policy/storage/san-image/path # set {lun lun-id | wwn wwn-num}  

Specifies the LUN or WWN to be used for the storage path to the boot image.

 
Step 9UCS-A /org/boot-policy/storage/san-image/path # commit-buffer  

Commits the transaction to the system configuration.

 

The following example enters the boot policy named lab1-boot-policy, creates a storage boot for the policy, sets the boot order to 1, creates a primary SAN image, uses a vHBA named vHBA2, creates primary path using LUN 967295200, and commits the transaction:

UCS-A# scope org /
UCS-A /org* # scope boot-policy lab1-boot-policy
UCS-A /org/boot-policy* # create storage
UCS-A /org/boot-policy/storage* # set order 1
UCS-A /org/boot-policy/storage* # create san-image primary
UCS-A /org/boot-policy/storage* # set vhba vHBA2
UCS-A /org/boot-policy/storage/san-image* # create path primary
UCS-A /org/boot-policy/storage/san-image/path* # set lun 967295200
UCS-A /org/boot-policy/storage/san-image/path* # commit-buffer 
UCS-A /org/boot-policy/storage/san-image/path #
What to Do Next

Include the boot policy in a service profile and/or template.

Configuring a Virtual Media Boot for a Boot Policy

Before You Begin

Create a boot policy to contain the virtual media boot configuration.


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 # scope boot-policy policy-name  

Enters organization boot policy mode for the specified boot policy.

 
Step 3UCS-A /org/boot-policy # create virtual-media {read-only | read-write}  

Creates a virtual media boot for the boot policy, specifies whether the virtual media is has read-only or read-write privileges, and enters organization boot policy virtual media mode.

 
Step 4UCS-A /org/boot-policy/virtual-media # set order {1 | 2 | 3 | 4}  

Sets the boot order for the virtual-media boot.

 
Step 5UCS-A /org/boot-policy/virtual-media # commit-buffer  

Commits the transaction to the system configuration.

 

The following example enters the boot policy named lab3-boot-policy, creates a virtual media boot with read-only privileges for the policy, sets the boot order to 3, and commits the transaction:

UCS-A# scope org /
UCS-A /org* # scope boot-policy lab3-boot-policy
UCS-A /org/boot-policy* # create virtual-media read-only
UCS-A /org/boot-policy/virtual-media* # set order 3
UCS-A /org/boot-policy/virtual-media* # commit-buffer
What to Do Next

Include the boot policy in a service profile and/or template.

Viewing a Boot Policy

Procedure
 Command or ActionPurpose
Step 1 UCS-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 # show boot-policy policy-name 

Displays the boot definition (set by the create boot-definition command). If the boot-definition is not set, and if a policy is set (using the set boot-policy command), then the policy will be displayed.

 

The following example shows how to display boot policy information for a boot policy called boot-policy-LAN:

UCS-A# scope org /
UCS-A /org # show boot-policy boot-policy-LAN

Boot Policy:
Full Name: org-root/boot-policy-LAN
Name: boot-policy-LAN
Purpose: Operational
Reboot on Update: Yes
Description:
Enforce vNIC Name: No

Deleting a Boot 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 boot-policy policy-name  

Deletes the specified boot policy.

 
Step 3UCS-A /org # commit-buffer  

Commits the transaction to the system configuration.

 

The following example deletes the boot policy named boot-policy-LAN and commits the transaction:

UCS-A# scope org /
UCS-A /org # delete boot-policy boot-policy-LAN
UCS-A /org* # commit-buffer
UCS-A /org #

Configuring IPMI Access Profiles

IPMI Access Profile

This policy allows you to determine whether IPMI commands can be sent directly to the server, using the IP address. For example, you can send commands to retrieve sensor data from the CIMC. This policy defines the IPMI access, including a username and password that can be authenticated locally on the server, and whether the access is read-only or read-write.

You must include this policy in a service profile and that service profile must be associated with a server for it to take effect.

Configuring an IPMI Access Profile

Before You Begin

Obtain the following:


  • Username with appropriate permissions that can be authenticated by the operating system of the server

  • Password for the username

  • Permissions associated with the username


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 ipmi-access-profile profile-name  

Creates the specified IPMI access profile and enters organization IPMI access profile mode.

 
Step 3UCS-A /org/ipmi-access-profile # create epuser epuser-name  

Creates the specified endpoint user and enters organization IPMI access profile endpoint user mode.

Note   

More than one endpoint user can be created within an IPMI access profile, with each endpoint user having its own password and privileges.

 
Step 4UCS-A /org/ipmi-access-profile/epuser # set password  

Sets the password for the endpoint user.

After entering the set password command, you are prompted to enter and confirm the password. For security purposes, the password that you type does not appear in the CLI.

 
Step 5UCS-A /org/ipmi-access-profile/epuser # set privilege {admin | readonly}  

Specifies whether the endpoint user has administrative or read-only privileges.

 
Step 6UCS-A /org/ipmi-access-profile/epuser # commit-buffer  

Commits the transaction to the system configuration.

 

The following example creates an IPMI access profile named ReadOnly, creates an endpoint user named bob, sets the password and the privileges for bob, and commits the transaction:

UCS-A# scope org /
UCS-A /org # create ipmi-access-profile ReadOnly
UCS-A /org/ipmi-access-profile* # create epuser bob
UCS-A /org/ipmi-access-profile/epuser* # set password
Enter a password:
Confirm the password:
UCS-A /org/ipmi-access-profile/epuser* # set privilege readonly
UCS-A /org/ipmi-access-profile/epuser* # commit-buffer
UCS-A /org/ipmi-access-profile/epuser #
What to Do Next

Include the IPMI profile in a service profile and/or template.

Deleting an IPMI Access Profile

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 ipmi-access-profile profile-name  

Deletes the specified IPMI access profile.

 
Step 3UCS-A /org # commit-buffer  

Commits the transaction to the system configuration.

 

The following example deletes the IPMI access profile named ReadOnly and commits the transaction:

UCS-A# scope org /
UCS-A /org # delete ipmi-access-profile ReadOnly
UCS-A /org* # commit-buffer
UCS-A /org #

Adding an Endpoint User to an IPMI Access Profile

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 # scope ipmi-access-profile profile-name  

Enters organization IPMI access profile mode for the specified IPMI access profile.

 
Step 3UCS-A /org/ipmi-access-profile # create epuser epuser-name  

Creates the specified endpoint user and enters organization IPMI access profile endpoint user mode.

Note   

More than one endpoint user can be created within an IPMI access profile, with each endpoint user having its own password and privileges.

 
Step 4UCS-A /org/ipmi-access-profile/epuser # set password  

Sets the password for the endpoint user.

After entering the set password command, you are prompted to enter and confirm the password. For security purposes, the password that you type does not appear in the CLI.

 
Step 5UCS-A /org/ipmi-access-profile/epuser # set privilege {admin | readonly}  

Specifies whether the endpoint user has administrative or read-only privileges.

 
Step 6UCS-A /org/ipmi-access-profile/epuser # commit-buffer  

Commits the transaction to the system configuration.

 

The following example adds an endpoint user named alice to the IPMI access profile named ReadOnly and commits the transaction:

UCS-A# scope org /
UCS-A /org* # scope ipmi-access-profile ReadOnly
UCS-A /org/ipmi-access-profile* # create epuser alice
UCS-A /org/ipmi-access-profile/epuser* # set password
Enter a password:
Confirm the password:
UCS-A /org/ipmi-access-profile/epuser* # set privilege readonly
UCS-A /org/ipmi-access-profile/epuser* # commit-buffer
UCS-A /org/ipmi-access-profile/epuser #

Deleting an Endpoint User from an IPMI Access Profile

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 # scope ipmi-access-profile profile-name  

Enters organization IPMI access profile mode for the specified IPMI access profile.

 
Step 3UCS-A /org/ipmi-access-profile # delete epuser epuser-name  

Deletes the specified endpoint user from the IPMI access profile.

 
Step 4UCS-A /org/ipmi-access-profile # commit-buffer  

Commits the transaction to the system configuration.

 

The following example deletes the endpoint user named alice from the IPMI access profile named ReadOnly and commits the transaction:

UCS-A# scope org /
UCS-A /org # scope ipmi-access-profile ReadOnly
UCS-A /org/ipmi-access-profile # delete epuser alice
UCS-A /org/ipmi-access-profile* # commit-buffer
UCS-A /org/ipmi-access-profile #

Configuring Local Disk Configuration Policies

Local Disk Configuration Policy

This policy configures any optional SAS local drives that have been installed on a server through the onboard RAID controller of the local drive. This policy enables you to set a local disk mode for all servers that are associated with a service profile that includes the local disk configuration policy.

The local disk modes include the following:


  • Any Configuration—For a server configuration that carries forward the local disk configuration without any changes.

  • No Local Storage—For a diskless server or a SAN only configuration. If you select this option, you cannot associate any service profile which uses this policy with a server that has a local disk.

  • No RAID—For a server configuration that removes the RAID and leaves the disk MBR and payload unaltered.

  • RAID 1 Mirrored—Data is written to two disks, providing complete data redundancy if one disk fails. The maximum array size is equal to the available space on the smaller of the two drives.

  • RAID10 Mirrored and Striped— RAID 10 uses mirrored pairs of disks to provide complete data redundancy and high throughput rates.

  • RAID 0 Stripes—Data is striped across all disks in the array, providing fast throughput. There is no data redundancy, and all data is lost if any disk fails.

  • RAID 6 Stripes Dual Parity—Data is striped across all disks in the array and two parity disks are used to provide protection against the failure of up to two physical disks. In each row of data blocks, two sets of parity data are stored.

  • RAID 5 Striped Parity—Data is striped across all disks in the array. Part of the capacity of each disk stores parity information that can be used to reconstruct data if a disk fails. RAID 5 provides good data throughput for applications with high read request rates.

You must include this policy in a service profile, and that service profile must be associated with a server for the policy to take effect.

Guidelines and Considerations for a Local Disk Configuration Policy

Before you create a local disk configuration policy, consider the following guidelines:

No Mixed HDDs and SSDs

Do not include HDDs and SSDs in a single RAID configuration or in a single blade server.

Impact of Upgrade to Release 1.3(1i) or Higher

An upgrade from an earlier Cisco UCS firmware release to release 1.3(1i) or higher has the following impact on the Protect Configuration property of the local disk configuration policy the first time servers are associated with service profiles after the upgrade:

Unassociated Servers

After you upgrade the Cisco UCS instance, the initial server association proceeds without configuration errors whether or not the local disk configuration policy matches the server hardware. Even if you enable the Protect Configuration property, Cisco UCS does not protect the user data on the server if there are configuration mismatches between the local disk configuration policy on the previous service profile and the policy in the new service profile.


Note

If you enable the Protect Configuration property and the local disk configuration policy encounters mismatches between the previous service profile and the new service profile, all subsequent service profile associations with the server are blocked.

Associated Servers

Any servers that are already associated with service profiles do not reboot after the upgrade. Cisco UCS Manager does not report any configuration errors if there is a mismatch between the local disk configuration policy and the server hardware.

When a service profile is disassociated from a server and a new service profile associated, the setting for the Protect Configuration property in the new service profile takes precedence and overwrites the setting in the previous service profile.

Creating a Local Disk Configuration 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 local-disk-config-policy policy-name  

Creates a local disk configuration policy and enters local disk configuration policy mode.

 
Step 3UCS-A /org/local-disk-config-policy # set descr description   (Optional)

Provides a description for the local disk configuration policy.

 
Step 4UCS-A /org/local-disk-config-policy # set mode {any-configuration | no-local-storage | no-raid | raid-0-striped | raid-1-mirrored | raid-5-striped-parity | raid-6-striped-dual-parity | raid-10-mirrored-and-striped}  

Specifies the mode for the local disk configuration policy.

 
Step 5UCS-A /org/local-disk-config-policy # set protect{yes | no} 

Specifies whether the local disk will be protected or not.

 
Step 6UCS-A /org/local-disk-config-policy # commit-buffer  

Commits the transaction to the system configuration.

 

The following example configures a local disk configuration policy and commits the transaction: 

UCS-A# scope org /
UCS-A /org # create local-disk-config-policy DiskPolicy7
UCS-A /org/local-disk-config-policy* # set mode raid-1-mirrored
UCS-A /org/local-disk-config-policy* # set protect yes
UCS-A /org/local-disk-config-policy* # commit-buffer
UCS-A /org/local-disk-config-policy #

Viewing a Local Disk Configuration Policy

Procedure
 Command or ActionPurpose
Step 1 UCS-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 # show local-disk-config-policy policy-name 

Displays the local disk policy. If you have not configured a local disk policy, the local disk configuration (created by the create local-disk-config command) displays.

Displays the local disk definition (set by the create local-disk-config command). If the serial over LAN definition is not set, and if a policy is set (using the set local-disk-config-policy command), then the policy will be displayed.

 

The following example shows how to display local disk policy information for a local disk configuration policy called DiskPolicy7:

UCS-A# scope org /
UCS-A /org # show local-disk-config-policy DiskPolicy7

Local Disk Config Policy:
Name: DiskPolicy7
Mode: Raid 1 Mirrored
Description:
Protect Configuration: Yes

Deleting a Local Disk Configuration 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 local-disk-config-policy policy-name  

Deletes the specified local disk configuration policy.

 
Step 3UCS-A /org # commit-buffer  

Commits the transaction to the system configuration.

 

The following example deletes the local disk configuration policy named DiskPolicy7 and commits the transaction:

UCS-A# scope org /
UCS-A /org # delete local-disk-config-policy DiskPolicy7
UCS-A /org* # commit-buffer
UCS-A /org #

Configuring Scrub Policies

Scrub Policy

This policy determines what happens to local data and to the BIOS settings on a server during the discovery process and when the server is disassociated from a service profile. Depending upon how you configure a scrub policy, the following can occur at those times:

Disk Scrub

One of the following occurs to the data on any local drives on disassociation:


  • If enabled, destroys all data on any local drives

  • If disabled, preserves all data on any local drives, including local storage configuration

BIOS Settings Scrub

One of the following occurs to the BIOS settings when a service profile containing the scrub policy is disassociated from a server:


  • If enabled, erases all BIOS settings for the server and and resets them to the BIOS defaults for that server type and vendor

  • If disabled, preserves the existing BIOS settings on the server

Creating a Scrub 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 scrub-policy policy-name  

Creates a scrub policy with the specified policy name, and enters organization scrub policy mode.

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

Provides a description for the scrub 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/scrub-policy # set disk-scrub {no | yes}  

Disables or enables disk scrubbing on servers using this scrub policy as follows:


  • If enabled, destroys all data on any local drives

  • If disabled, preserves all data on any local drives, including local storage configuration

 
Step 5UCS-A /org/scrub-policy # set bios-settings-scrub {no | yes}  

Disables or enables BIOS settings scrubbing on servers using this scrub policy as follows:


  • If enabled, erases all BIOS settings for the server and and resets them to the BIOS defaults for that server type and vendor

  • If disabled, preserves the existing BIOS settings on the server

 
Step 6UCS-A /org/scrub-policy # commit-buffer  

Commits the transaction to the system configuration.

 

The following example creates a scrub policy named ScrubPolicy2, enables disk scrubbing on servers using the scrub policy, and commits the transaction: 

UCS-A# scope org /
UCS-A /org # create scrub-policy ScrubPolicy2
UCS-A /org/scrub-policy* # set descr "Scrub disk but not BIOS."
UCS-A /org/scrub-policy* # set disk-scrub yes
UCS-A /org/scrub-policy* # set bios-settings-scrub no
UCS-A /org/scrub-policy* # commit-buffer
UCS-A /org/scrub-policy #

Deleting a Scrub 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 scrub-policy policy-name  

Deletes the specified scrub policy.

 
Step 3UCS-A /org # commit-buffer  

Commits the transaction to the system configuration.

 

The following example deletes the scrub policy named ScrubPolicy2 and commits the transaction:

UCS-A# scope org /
UCS-A /org # delete scrub-policy ScrubPolicy2
UCS-A /org* # commit-buffer
UCS-A /org #

Configuring Serial over LAN Policies

Serial over LAN Policy

This policy sets the configuration for the serial over LAN connection for all servers associated with service profiles that use the policy. By default, the serial over LAN connection is disabled.

If you implement a serial over LAN policy, we recommend that you also create an IPMI profile.

You must include this policy in a service profile and that service profile must be associated with a server for it to take effect.

Configuring a Serial over LAN 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 sol-policy policy-name  

Creates a serial over LAN policy and enters organization serial over LAN policy mode.

 
Step 3UCS-A /org/sol-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/sol-policy # set speed {115200 | 19200 | 38400 | 57600 | 9600}  

Specifies the serial baud rate.

 
Step 5UCS-A /org/sol-policy # {disable | enable}  

Disables or enables the serial over LAN policy. By default, the serial over LAN policy is disabled; you must enable it before it can be applied.

 
Step 6UCS-A /org/sol-policy # commit-buffer  

Commits the transaction to the system configuration.

 

The following example creates a serial over LAN policy named Sol9600, provides a description for the policy, sets the speed to 9,600 baud, enables the policy, and commits the transaction: 

UCS-A# scope org /
UCS-A /org* # create sol-policy Sol9600
UCS-A /org/sol-policy* # set descr "Sets serial over LAN policy to 9600 baud."
UCS-A /org/sol-policy* # set speed 9600
UCS-A /org/sol-policy* # enable
UCS-A /org/sol-policy* # commit-buffer
UCS-A /org/sol-policy #

Viewing a Serial over LAN Policy

Procedure
 Command or ActionPurpose
Step 1 UCS-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 # show sol-policy policy-name 

Displays the serial over LAN definition (set by the create sol-config command). If the serial over LAN definition is not set, and if a policy is set (using the set sol-policy command), then the policy will be displayed.

 

The following example shows how to display serial over LAN information for a serial over LAN policy called Sol9600:

UCS-A# scope org /
UCS-A /org # show sol-policy Sol9600

SOL Policy:
Full Name: Sol9600
SOL State: Enable
Speed: 9600
Description:

Deleting a Serial over LAN 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 sol-policy policy-name  

Deletes the specified serial over LAN policy.

 
Step 3UCS-A /org # commit-buffer  

Commits the transaction to the system configuration.

 

The following example deletes the serial over LAN policy named Sol9600 and commits the transaction: 

UCS-A# scope org /
UCS-A /org* # delete sol-policy Sol9600
UCS-A /org* # commit-buffer
UCS-A /org #

Configuring Server Autoconfiguration Policies

Server Autoconfiguration Policy

Cisco UCS Manager uses this policy to determine how to configure a new server. If you create a server autoconfiguration policy, the following occurs when a new server starts:


  1. The qualification in the server autoconfiguration policy is executed against the server.

  2. If the server meets the required qualifications, the server is associated with a service profile created from the service profile template configured in the server autoconfiguration policy. The name of that service profile is based on the name given to the server by Cisco UCS Manager.

  3. The service profile is assigned to the organization configured in the server autoconfiguration policy.

Configuring a Server Autoconfiguration 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 server-autoconfig-policy policy-name  

Creates a server autoconfiguration policy with the specified policy name, and enters organization server autoconfiguration policy mode.

 
Step 3UCS-A /org/server-autoconfig-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/server-autoconfig-policy # set destination org org-name   (Optional)

Specifies the organization for which the server is to be used.

 
Step 5UCS-A /org/server-autoconfig-policy # set qualifier server-qual-name   (Optional)

Specifies server pool policy qualification to use for qualifying the server.

 
Step 6UCS-A /org/server-autoconfig-policy # set template profile-name   (Optional)

Specifies a service profile template to use for creating a service profile instance for the server.

 
Step 7UCS-A /org/server-autoconfig-policy # commit-buffer  

Commits the transaction to the system configuration.

 

The following example creates a server autoconfiguration policy named AutoConfigFinance, provides a description for the policy, specifies finance as the destination organization, ServPoolQual22 as the server pool policy qualification, and ServTemp2 as the service profile template, and commits the transaction: 

UCS-A# scope org /
UCS-A /org* # create server-autoconfig-policy AutoConfigFinance
UCS-A /org/server-autoconfig-policy* # set descr "Server Autoconfiguration Policy for Finance"
UCS-A /org/server-autoconfig-policy* # set destination org finance
UCS-A /org/server-autoconfig-policy* # set qualifier ServPoolQual22
UCS-A /org/server-autoconfig-policy* # set template ServTemp2
UCS-A /org/server-autoconfig-policy* # commit-buffer
UCS-A /org/server-autoconfig-policy #

Deleting a Server Autoconfiguration 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 server-autoconfig-policy policy-name  

Deletes the specified server autoconfiguration policy.

 
Step 3UCS-A /org # commit-buffer  

Commits the transaction to the system configuration.

 

The following example deletes the server autoconfiguration policy named AutoConfigFinance and commits the transaction: 

UCS-A# scope org /
UCS-A /org* # delete server-autoconfig-policy AutoConfigFinance
UCS-A /org* # commit-buffer
UCS-A /org #

Configuring Server Discovery Policies

Server Discovery Policy

This discovery policy determines how the system reacts when you add a new server. If you create a server discovery policy, you can control whether the system conducts a deep discovery when a server is added to a chassis, or whether a user must first acknowledge the new server. By default, the system conducts a full discovery.

If you create a server discovery policy, the following occurs when a new server starts:


  1. The qualification in the server discovery policy is executed against the server.

  2. If the server meets the required qualifications, Cisco UCS Manager applies the following to the server:


    • Depending upon the option selected for the action, either discovers the new server immediately or waits for a user to acknowledge the new server

    • Applies the scrub policy to the server

Configuring a Server Discovery Policy

Before You Begin

If you plan to associate this policy with a server pool, create server pool policy qualifications.


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

Enters the root organization mode.

Note   

Chassis discovery policies can only be accessed from the root organization.

 
Step 2UCS-A /org # create server-disc-policy policy-name  

Creates a server discovery policy with the specified policy name, and enters org server discovery policy mode.

 
Step 3UCS-A /org/server-disc-policy # set action {diag | immediate | user-acknowledged}  

Specifies when the system will attempt to discover new servers.

 
Step 4UCS-A /org/chassis-disc-policy # set descr description   (Optional)

Provides a description for the server discovery 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 5UCS-A /org/server-disc-policy # set qualifier qualifier   (Optional)

Uses the specified server pool policy qualifications to associates this policy with a server pool.

 
Step 6UCS-A /org/server-disc-policy # set scrub-policy  

Specifies the scrub policy to be used by this policy. The scrub policy defines whether the disk drive on a server should be scrubbed clean upon discovery.

 
Step 7UCS-A /org/server-disc-policy # commit-buffer  

Commits the transaction to the system configuration.

 

The following example creates a server discovery policy named ServDiscPolExample, sets it to immediately discover new servers, provides a description for the policy, specifies the server pool policy qualifications and scrub policy, and commits the transaction: 

UCS-A# scope org /
UCS-A /org # create server-disc-policy ServDiscPolExample
UCS-A /org/server-disc-policy* # set action immediate
UCS-A /org/server-disc-policy* # set descr "This is an example server discovery policy."
UCS-A /org/server-disc-policy* # set qualifier ExampleQual
UCS-A /org/server-disc-policy* # set scrub-policy NoScrub
UCS-A /org/server-disc-policy # commit-buffer
What to Do Next

Include the server discovery policy in a service profile and/or template.

Deleting a Server Discovery 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 server-disc-policy policy-name  

Deletes the specified server discovery policy.

 
Step 3UCS-A /org/server-disc-policy # commit-buffer  

Commits the transaction to the system configuration.

 

The following example deletes the server discovery policy named ServDiscPolExample and commits the transaction:

UCS-A# scope org /
UCS-A /org # delete server-disc-policy ServDiscPolExample
UCS-A /org* # commit-buffer
UCS-A /org #

Configuring Server Inheritance Policies

Server Inheritance Policy

This policy is invoked during the server discovery process to create a service profile for the server. All service profiles created from this policy use the values burned into the blade at manufacture. The policy performs the following:


  • Analyzes the inventory of the server

  • If configured, assigns the server to the selected organization

  • Creates a service profile for the server with the identity burned into the server at manufacture

You cannot migrate a service profile created with this policy to another server.

Configuring a Server Inheritance 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 server-inherit-policy policy-name  

Creates a server inheritance policy with the specified policy name, and enters organization server inheritance policy mode.

 
Step 3UCS-A /org/server-inherit-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/server-inherit-policy # set destination org org-name   (Optional)

Specifies the organization for which the server is to be used.

 
Step 5UCS-A /org/server-inherit-policy # set qualifier server-qual-name   (Optional)

Specifies server pool policy qualification to use for qualifying the server.

 
Step 6UCS-A /org/server-inherit-policy # commit-buffer  

Commits the transaction to the system configuration.

 

The following example creates a server inheritance policy named InheritEngineering, provides a description for the policy, specifies engineering as the destination organization and ServPoolQual22 as the server pool policy qualification, and commits the transaction: 

UCS-A# scope org /
UCS-A /org* # create server-inherit-policy InheritEngineering
UCS-A /org/server-inherit-policy* # set descr "Server Inheritance Policy for Engineering"
UCS-A /org/server-inherit-policy* # set destination org engineering
UCS-A /org/server-inherit-policy* # set qualifier ServPoolQual22
UCS-A /org/server-inherit-policy* # commit-buffer
UCS-A /org/server-inherit-policy #

Deleting a Server Inheritance 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 server-inherit-policy policy-name  

Deletes the specified server inheritance policy.

 
Step 3UCS-A /org # commit-buffer  

Commits the transaction to the system configuration.

 

The following example deletes the server inheritance policy named InheritEngineering and commits the transaction: 

UCS-A# scope org /
UCS-A /org* # delete server-inherit-policy InheritEngineering
UCS-A /org* # commit-buffer
UCS-A /org #

Configuring Server Pool Policies

Server Pool Policy

This policy is invoked during the server discovery process. It determines what happens if server pool policy qualifications match a server to the target pool specified in the policy.

If a server qualifies for more than one pool and those pools have server pool policies, the server is added to all those pools.

Configuring a Server Pool 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 pooling-policy policy-name  

Creates a server pool policy with the specified name, and enters organization pooling policy mode.

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

Provides a description for the server pool 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/pooling-policy # set pool pool-distinguished-name  

Specifies the server pool to use with the server pool policy. You must specify the full distinguished name for the pool.

 
Step 5UCS-A /org/pooling-policy # set qualifier qualifier-name  

Specifies the server pool qualifier to use with the server pool policy.

 
Step 6UCS-A /org/pooling-policy # commit-buffer  

Commits the transaction to the system configuration.

 

The following example creates a server pool policy named ServerPoolPolicy4 and commits the transaction: 

UCS-A# scope org /
UCS-A /org # create pooling-policy ServerPoolPolicy4
UCS-A /org/pooling-policy* # set pool org-root/compute-pool-pool3 
UCS-A /org/pooling-policy* # set qualifier ServPoolQual8
UCS-A /org/pooling-policy* # commit-buffer
UCS-A /org/pooling-policy #

Deleting a Server Pool 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 pooling-policy policy-name  

Deletes the specified server pool policy.

 
Step 3UCS-A /org # commit-buffer  

Commits the transaction to the system configuration.

 

The following example deletes the server pool policy named ServerPoolPolicy4 and commits the transaction:

UCS-A# scope org /
UCS-A /org # delete pooling-policy ServerPoolPolicy4
UCS-A /org/pooling-policy* # commit-buffer
UCS-A /org/pooling-policy #

Configuring Server Pool Policy Qualifications

Server Pool Policy Qualifications

This policy qualifies servers based on the inventory of a server conducted during the discovery process. The qualifications are individual rules that you configure in the policy to determine whether a server meets the selection criteria. For example, you can create a rule that specifies the minimum memory capacity for servers in a data center pool.

Qualifications are used in other policies to place servers, not just by the server pool policies. For example, if a server meets the criteria in a qualification policy, it can be added to one or more server pools or have a service profile automatically associated with it.

You can use the server pool policy qualifications to qualify servers according to the following criteria:


  • Adapter type

  • Chassis location

  • Memory type and configuration

  • CPU cores, type, and configuration

  • Storage configuration and capacity

  • Server model

Depending upon the implementation, you may configure several policies with server pool policy qualifications including the following:


  • Autoconfiguration policy

  • Chassis discovery policy

  • Server discovery policy

  • Server inheritance policy

  • Server pool policy

Creating a Server Pool Policy Qualification

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 server-qual server-qual-name  

Creates a server pool qualification with the specified name, and enters organization server qualification mode.

 
Step 3UCS-A /org/server-qual # commit-buffer  

Commits the transaction to the system configuration.

 

The following example creates a server pool qualification named ServPoolQual22 and commits the transaction:

UCS-A# scope org /
UCS-A /org* # create server-qual ServPoolQual22
UCS-A /org/server-qual* # commit-buffer
UCS-A /org/server-qual #
What to Do Next

Configure one or more of the following server component qualifications:


  • Adapter qualification

  • Chassis qualification

  • Memory qualification

  • Processor qualification

  • Storage qualification

Deleting a Server Pool Policy Qualification

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 server-qual server-qual-name  

Deletes the specified server pool qualification.

 
Step 3UCS-A /org/server-qual # commit-buffer  

Commits the transaction to the system configuration.

 

The following example deletes the server pool qualification named ServPoolQual22 and commits the transaction:

UCS-A# scope org /
UCS-A /org* # delete server-qual ServPoolQual22
UCS-A /org* # commit-buffer
UCS-A /org #

Creating an Adapter Qualification

Before You Begin

Create a server pool policy qualification.


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 # scope server-qual server-qual-name  

Enters organization server qualification mode for the specified server pool policy qualification.

 
Step 3UCS-A /org/server-qual # create adapter  

Creates an adapter qualification and enters organization server qualification adapter mode.

 
Step 4UCS-A /org/server-qual/adapter # create cap-qual adapter-type  

Creates an adapter capacity qualification for the specified adapter type and enters organization server qualification adapter capacity qualification mode. The adapter-type argument can be any of the following values:


  • fcoe—Fibre Channel over Ethernet

  • non-virtualized-eth-if—Non-virtualized Ethernet interface

  • non-virtualized-fc-if—Non-virtualized Fibre Channel interface

  • path-encap-consolidated—Path encapsulation consolidated

  • path-encap-virtual—Path encapsulation virtual

  • protected-eth-if—Protected Ethernet interface

  • protected-fc-if—Protected Fibre Channel interface

  • protected-fcoe—Protected Fibre Channel over Ethernet

  • virtualized-eth-if—Virtualized Ethernet interface

  • virtualized-fc-if—Virtualized Fibre Channel interface

  • virtualized-scsi-if—Virtualized SCSI interface

 
Step 5UCS-A /org/server-qual/adapter/cap-qual # set maximum {max-cap | unspecified}  

Specifies the maximum capacity for the selected adapter type.

 
Step 6UCS-A /org/server-qual/adapter/cap-qual # commit-buffer  

Commits the transaction to the system configuration.

 

The following example creates and configures an adapter qualification for a non-virtualized Ethernet interface and commits the transaction:

UCS-A# scope org /
UCS-A /org # scope server-qual ServPoolQual22
UCS-A /org/server-qual # create adapter
UCS-A /org/server-qual/adapter* # create cap-qual non-virtualized-eth-if
UCS-A /org/server-qual/adapter/cap-qual* # set maximum 2500000000
UCS-A /org/server-qual/adapter/cap-qual* # commit-buffer
UCS-A /org/server-qual/adapter/cap-qual #

Deleting an Adapter Qualification

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 # scope server-qual server-qual-name  

Enters organization server qualification mode for the specified server pool policy qualification.

 
Step 3UCS-A /org/server-qual # delete adapter  

Deletes the adapter qualification from the server pool policy qualification.

 
Step 4UCS-A /org/server-qual # commit-buffer  

Commits the transaction to the system configuration.

 

The following example deletes the adapter qualification from the server pool policy qualification named ServPoolQual22 and commits the transaction:

UCS-A# scope org /
UCS-A /org # scope server-qual ServPoolQual22
UCS-A /org/server-qual # delete adapter
UCS-A /org/server-qual* # commit-buffer
UCS-A /org/server-qual #

Configuring a Chassis Qualification

Before You Begin

Create a server pool policy qualification.


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 # scope server-qual server-qual-name  

Enters organization server qualification mode for the specified server pool policy qualification.

 
Step 3UCS-A /org/server-qual # create chassis min-chassis-num max-chassis-num  

Creates a chassis qualification for the specified chassis range and enters organization server qualification chassis mode.

 
Step 4UCS-A /org/server-qual/chassis # create slot min-slot-num max-slot-num  

Creates a chassis slot qualification for the specified slot range and enters organization server qualification chassis slot mode.

 
Step 5UCS-A /org/server-qual/chassis/slot # commit-buffer  

Commits the transaction to the system configuration.

 

The following example configures a chassis qualification for slots 1 to 4 on chassis 1 and 2 and commits the transaction:

UCS-A# scope org /
UCS-A /org* # scope server-qual ServPoolQual22
UCS-A /org/server-qual* # create chassis 1 2
UCS-A /org/server-qual/chassis* # create slot 1 4
UCS-A /org/server-qual/chassis/slot* # commit-buffer
UCS-A /org/server-qual/chassis/slot #

Deleting a Chassis Qualification

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 # scope server-qual server-qual-name  

Enters organization server qualification mode for the specified server pool policy qualification.

 
Step 3UCS-A /org/server-qual # delete chassis min-chassis-num max-chassis-num  

Deletes the chassis qualification for the specified chassis range.

 
Step 4UCS-A /org/server-qual # commit-buffer  

Commits the transaction to the system configuration.

 

The following example deletes the chassis qualification for chassis 1 and 2 and commits the transaction:

UCS-A# scope org /
UCS-A /org # scope server-qual ServPoolQual22
UCS-A /org/server-qual # delete chassis 1 2
UCS-A /org/server-qual* # commit-buffer
UCS-A /org/server-qual #

Creating a CPU Qualification

Before You Begin

Create a server pool policy qualification.


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 # scope server-qual server-qual-name  

Enters organization server qualification mode for the specified server pool policy qualification.

 
Step 3UCS-A /org/server-qual # create cpu  

Creates a CPU qualification and enters organization server qualification processor mode.

 
Step 4UCS-A /org/server-qual/cpu # set arch {any | dual-core-opteron | intel-p4-c | opteron | pentium-4 | turion-64 | xeon | xeon-mp}  

Specifies the processor architecture type.

 
Step 5UCS-A /org/server-qual/cpu # set maxcores {max-core-num | unspecified}  

Specifies the maximum number of processor cores.

 
Step 6UCS-A /org/server-qual/cpu # set mincores {min-core-num | unspecified}  

Specifies the minimum number of processor cores.

 
Step 7UCS-A /org/server-qual/cpu # set maxprocs {max-proc-num | unspecified}  

Specifies the maximum number of processors.

 
Step 8UCS-A /org/server-qual/cpu # set minprocs {min-proc-num | unspecified}  

Specifies the minimum number of processors.

 
Step 9UCS-A /org/server-qual/cpu # set maxthreads {max-thread-num | unspecified}  

Specifies the maximum number of threads.

 
Step 10UCS-A /org/server-qual/cpu # set minthreads {min-thread-num | unspecified}  

Specifies the minimum number of threads.

 
Step 11UCS-A /org/server-qual/cpu # set stepping {step-num | unspecified}  

Specifies the processor stepping number.

 
Step 12UCS-A /org/server-qual/cpu # set model-regex regex  

Specifies a regular expression that the processor name must match.

 
Step 13UCS-A /org/server-qual/cpu # commit-buffer  

Commits the transaction to the system configuration.

 

The following example creates and configures a CPU qualification and commits the transaction:

UCS-A# scope org /
UCS-A /org # scope server-qual ServPoolQual22
UCS-A /org/server-qual # create processor
UCS-A /org/server-qual/cpu* # set arch xeon
UCS-A /org/server-qual/cpu* # set maxcores 8
UCS-A /org/server-qual/cpu* # set mincores 4
UCS-A /org/server-qual/cpu* # set maxprocs 2
UCS-A /org/server-qual/cpu* # set minprocs 1
UCS-A /org/server-qual/cpu* # set maxthreads 16
UCS-A /org/server-qual/cpu* # set minthreads 8
UCS-A /org/server-qual/cpu* # set stepping 5
UCS-A /org/server-qual/cpu* # commit-buffer
UCS-A /org/server-qual/cpu #

Deleting a CPU Qualification

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 # scope server-qual server-qual-name  

Enters organization server qualification mode for the specified server pool policy qualification.

 
Step 3UCS-A /org/server-qual # delete cpu  

Deletes the processor qualification.

 
Step 4UCS-A /org/server-qual # commit-buffer  

Commits the transaction to the system configuration.

 

The following example deletes the processor qualification and commits the transaction:

UCS-A# scope org /
UCS-A /org # scope server-qual ServPoolQual22
UCS-A /org/server-qual # delete cpu
UCS-A /org/server-qual* # commit-buffer
UCS-A /org/server-qual #

Creating a Memory Qualification

Before You Begin

Create a server pool policy qualification.


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 # scope server-qual server-qual-name  

Enters organization server qualification mode for the specified server pool policy qualification.

 
Step 3UCS-A /org/server-qual # create memory  

Creates a memory qualification and enters organization server qualification memory mode.

 
Step 4UCS-A /org/server-qual/memory # set clock {clock-num | unspec}  

Specifies the memory clock speed.

 
Step 5UCS-A /org/server-qual/memory # set maxcap {max-cap-num | unspec}  

Specifies the maximum capacity of the memory array.

 
Step 6UCS-A /org/server-qual/memory # set mincap {min-cap-num | unspec}  

Specifies the minimum capacity of the memory array.

 
Step 7UCS-A /org/server-qual/memory # set speed {speed-num | unspec}  

Specifies the memory data rate.

 
Step 8UCS-A /org/server-qual/memory # set units {unit-num | unspec}  

Specifies the number of memory units (DRAM chips mounted to the memory board).

 
Step 9UCS-A /org/server-qual/memory # set width {width-num | unspec}  

Specifies the bit width of the data bus.

 
Step 10UCS-A /org/server-qual/memory # commit-buffer  

Commits the transaction to the system configuration.

 

The following example creates and configures a memory qualification and commits the transaction:

UCS-A# scope org /
UCS-A /org # scope server-qual ServPoolQual22
UCS-A /org/server-qual # create memory
UCS-A /org/server-qual/memory* # set clock 1067
UCS-A /org/server-qual/memory* # set maxcap 4096
UCS-A /org/server-qual/memory* # set mincap 2048
UCS-A /org/server-qual/memory* # set speed unspec
UCS-A /org/server-qual/memory* # set units 16
UCS-A /org/server-qual/memory* # set width 64
UCS-A /org/server-qual/memory* # commit-buffer
UCS-A /org/server-qual/memory #

Deleting a Memory Qualification

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 # scope server-qual server-qual-name  

Enters organization server qualification mode for the specified server pool policy qualification.

 
Step 3UCS-A /org/server-qual # delete memory  

Deletes the memory qualification.

 
Step 4UCS-A /org/server-qual # commit-buffer  

Commits the transaction to the system configuration.

 

The following example deletes the memory qualification and commits the transaction:

UCS-A# scope org /
UCS-A /org # scope server-qual ServPoolQual22
UCS-A /org/server-qual # delete memory
UCS-A /org/server-qual* # commit-buffer
UCS-A /org/server-qual #

Creating a Physical Qualification

Before You Begin

Create a server pool policy qualification.


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 # scope server-qual server-qual-name  

Enters organization server qualification mode for the specified server pool policy qualification.

 
Step 3UCS-A /org/server-qual # create physical-qual  

Creates a physical qualification and enters organization server qualification physical mode.

 
Step 4UCS-A /org/server-qual/physical-qual # set model-regex regex  

Specifies a regular expression that the model name must match.

 
Step 5UCS-A /org/server-qual/physical-qual # commit-buffer  

Commits the transaction to the system configuration.

 

The following example creates and configures a physical qualification and commits the transaction:

UCS-A# scope org /
UCS-A /org # scope server-qual ServPoolQual22
UCS-A /org/server-qual # create physical-qual
UCS-A /org/server-qual/physical-qual* # set model-regex  
UCS-A /org/server-qual/physical-qual* # commit-buffer
UCS-A /org/server-qual/physical-qual #

Deleting a Physical Qualification

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 # scope server-qual server-qual-name  

Enters organization server qualification mode for the specified server pool policy qualification.

 
Step 3UCS-A /org/server-qual # delete physical-qual  

Deletes the physical qualification.

 
Step 4UCS-A /org/server-qual # commit-buffer  

Commits the transaction to the system configuration.

 

The following example deletes a physical qualification and commits the transaction:

UCS-A# scope org /
UCS-A /org # scope server-qual ServPoolQual22
UCS-A /org/server-qual # delete physical-qual
UCS-A /org/server-qual* # commit-buffer
UCS-A /org/server-qual #

Creating a Storage Qualification

Before You Begin

Create a server pool policy qualification.


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 # scope server-qual server-qual-name  

Enters organization server qualification mode for the specified server pool policy qualification.

 
Step 3UCS-A /org/server-qual # create storage  

Creates a storage qualification and enters organization server qualification storage mode.

 
Step 4UCS-A /org/server-qual/storage # set blocksize {block-size-num | unspecified}  

Specifies the storage block size.

 
Step 5UCS-A /org/server-qual/storage # set maxcap {max-cap-num | unspecified}  

Specifies the maximum capacity of the storage array.

 
Step 6UCS-A /org/server-qual/storage # set mincap {min-cap-num | unspecified}  

Specifies the minimum capacity of the storage array.

 
Step 7UCS-A /org/server-qual/storage # set numberofblocks {block-num | unspecified}  

Specifies the number of blocks.

 
Step 8UCS-A /org/server-qual/storage # set perdiskcap {disk-cap-num | unspecified}  

Specifies the per-disk capacity.

 
Step 9UCS-A /org/server-qual/storage # set units {unit-num | unspecified}  

Specifies the number of storage units.

 
Step 10UCS-A /org/server-qual/storage # commit-buffer  

Commits the transaction to the system configuration.

 

The following example creates and configures a storage qualification and commits the transaction:

UCS-A# scope org /
UCS-A /org # scope server-qual ServPoolQual22
UCS-A /org/server-qual # create storage
UCS-A /org/server-qual/storage* # set blocksize 512
UCS-A /org/server-qual/storage* # set maxcap 420000
UCS-A /org/server-qual/storage* # set mincap 140000
UCS-A /org/server-qual/storage* # set numberofblocks 287277984
UCS-A /org/server-qual/storage* # set perdiskcap 140000
UCS-A /org/server-qual/storage* # set units 1
UCS-A /org/server-qual/storage* # commit-buffer
UCS-A /org/server-qual/storage #

Deleting a Storage Qualification

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 # scope server-qual server-qual-name  

Enters organization server qualification mode for the specified server pool policy qualification.

 
Step 3UCS-A /org/server-qual # delete storage  

Deletes the storage qualification.

 
Step 4UCS-A /org/server-qual/ # commit-buffer  

Commits the transaction to the system configuration.

 

The following example deletes the storage qualification and commits the transaction:

UCS-A# scope org /
UCS-A /org # scope server-qual ServPoolQual22
UCS-A /org/server-qual # delete storage
UCS-A /org/server-qual* # commit-buffer
UCS-A /org/server-qual #

Configuring vNIC/vHBA Placement Profiles

vNIC/vHBA Placement Policies

vNIC/vHBA placement policies are used to assign vNICs or vHBAs to the physical adapters on a server. Each vNIC/vHBA placement policy contains two virtual network interface connections (vCons) that are virtual representations of the physical adapters. When a vNIC/vHBA placement policy is assigned to a service profile, and the service profile is associated to a server, the vCons in the vNIC/vHBA placement policy are assigned to the physical adapters. For servers with only one adapter, both vCons are assigned to the adapter; for servers with two adapters, one vCon is assigned to each adapter.

You can assign vNICs or vHBAs to either of the two vCons, and they are then assigned to the physical adapters based on the vCon assignment during server association. Additionally, vCons use the following selection preference criteria to assign vHBAs and vNICs:

All

The vCon is used for vNICs or vHBAs assigned to it, vNICs or vHBAs not assigned to either vCon, and dynamic vNICs or vHBAs.

Assigned-Only

The vCon is reserved for only vNICs or vHBAs assigned to it.

Exclude-Dynamic

The vCon is not used for dynamic vNICs or vHBAs.

Exclude-Unassigned

The vCon is not used for vNICs or vHBAs not assigned to the vCon. The vCon is used for dynamic vNICs and vHBAs.

For servers with two adapters, if you do not include a vNIC/vHBA placement policy in a service profile, or you do not configure vCons for a service profile, Cisco UCS equally distributes the vNICs and vHBAs between the two adapters.

Configuring a vNIC/vHBA Placement Profile

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 vcon-policy policy-name  

Creates the specified vNIC/vHBA placement profile and enters organization vcon policy mode.

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

Provides a description for the vNIC/vHBA Placement Profile.

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/vcon-policy # set vcon {1 | 2} selection {all | assigned-only | exclude-dynamic | exclude-unassigned}  

Specifies the selection preference for the specified vCon.

 
Step 5UCS-A /org/vcon-policy # commit-buffer  

Commits the transaction.

 

The following example creates a vNIC/vHBA placement policy named Adapter1All, places all vNICs and vHBAs on adapter 1, and commits the transaction:

UCS-A# scope org /
UCS-A /org # create vcon-policy Adapter1
UCS-A /org/vcon-policy* # set descr "This profile places all vNICs and vHBAs on adapter 1."
UCS-A /org/vcon-policy* # set vcon 1 selection all
UCS-A /org/vcon-policy* # commit-buffer
UCS-A /org/vcon-policy* # 
UCS-A /org #

Deleting a vNIC/vHBA Placement Profile

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 vcon-policy policy-name  

Deletes the specified vNIC/vHBA placement profile.

 
Step 3UCS-A /org # commit-buffer  

Commits the transaction.

 

The following example deletes the vNIC/vHBA placement profile named Adapter1All and commits the transaction: 

UCS-A# scope org /
UCS-A /org # delete vcon-policy Adapter1All
UCS-A /org* # commit-buffer
UCS-A /org #