configure

In Cisco Intersight, a Server Profile enables resource management by streamlining policy alignment, and server configuration. To view the Server Profiles table view, choose Configure > Profiles > UCS Server Profiles. You can create Server Profiles using the Server Profile wizard or you can import the configuration details of C-series servers in standalone mode and FI-attached servers in Intersight Managed Mode (IMM), directly from Cisco IMC. You can create Server Profiles using the Server Profile wizard to provision servers, create policies to ensure smooth deployment of servers, and eliminate failures that are caused by inconsistent configuration. The Server Profiles wizard groups the server policies into the following four categories to provide a quick Summary View of the policies that are attached to a profile:

• Compute Policies—BIOS, Boot Order, Firmware, Persistent Memory, Memory, Power, Scrub, Thermal, and Virtual Media.

• Network Policies—Adapter Configuration, iSCSI Boot, LAN Connectivity, and SAN Connectivity policies.

  • The LAN Connectivity policy requires you to create Ethernet Network Policy, Ethernet Adapter Policy, and Ethernet QoS Policy. When you attach a LAN Connectivity policy to a server profile, the addresses of the MAC address Pool, or the static MAC address, are automatically assigned.

    Note: A LAN Connectivity policy that has a static MAC address can be attached to only one server profile.

  • The SAN Connectivity policy requires you to create Fibre Channel Network Policy, Fibre Channel Adapter Policy, and Fiber Channel QoS Policy. When you attach a SAN Connectivity policy to a server profile, the addresses of the WWPN and WWNN Pools, or the static WWPN and WWNN addresses, are automatically assigned.

    Note: A SAN Connectivity policy that has a static WWPN, or a static WWNN can be attached to only one server profile.

• Storage Policies—Drive Security, SD Card, and Storage policies.

• Management Policies—Certificate Management, Device Connector, IPMI Over LAN, LDAP, Local User, Network Connectivity, NTP, Serial over LAN, SMTP, SNMP, SSH, Syslog, and Virtual KVM policies.

Certain server configurations applied through policies are automatically cleared and reset to default settings in Intersight Managed Mode servers. This occurs under the following conditions: when policies are detached and the profile is re-deployed, when a server is unassigned from a profile, during first-time discovery, decommissioning, or during recommissioning of a server. For more information, see Clearing and Resetting Server Configurations.

For more information and descriptions of the policies, see the Server Policies section. For an example of the policy creation workflow, see Creating Network Policies.

Server Profile List View

When you select Profiles > UCS Server Profiles in the Intersight UI, the UCS server profile list view is seen.

The list view shows the following details in a tabular format:

• Name—The name of the server profile.

• Status—The deployment status of the server profile.

  The Status of the profiles can have any of the following values:

  • Activating—A transient state is observed during the Activation workflow.

  • Analyzing—A transient state that occurs when the policy impact estimation is in progress.

  • Configuring—A transient state that occurs during the Deploy workflow when the deploy tasks for the various policies are in progress.

  • Evaluating—A transient state is observed during the policy change evaluation workflow.

  • Failed—Server profile validation, configuration, or deployment has failed.

  • Inconsistent—Indicates that the policy configuration has changes that have not yet been deployed or activated. It may also indicate that the policy configuration at the endpoint is not in sync with the last deployed policy configuration in the server profile. If the endpoint settings are altered manually after a server profile is deployed, Intersight automatically detects the configuration changes and they will be shown on the server profile as Inconsistent. For more information, see the Server Profile Drift and the Deploying and Activating a Server Profile sections.

  • Not Assigned—Server is not assigned to the server profile.

    Note:

    • Once you deploy policies to the server profile, the status changes automatically from Not Assigned to the new status depending on the outcome. You may need to refresh your screen to view the updated status.

    • You must do the Power Cycle/Power ON after each profile deployment.

  • Not Complete—The configuration import for the profile has not been completed.

  • Not Deployed—The server is assigned to the profile, but the configuration has not yet been applied to the endpoint.

  • OK—Policies deployed successfully on the server profile.

  • Unconfiguring—A transient state occurs during the Undeploy workflow for FI-attached servers only.

  • Validating—A transient state is currently in progress during policy validation for the server assigned to the profile.

  • Waiting for Resources—The profile is pending resource allocation.

• Inconsistency Reason—The reason for the status being shown as Inconsistent. Example—Not Deployed, Not Activated, Out of Sync.

• Target Platform—Indicates if the platform for which the profile is applicable is a Standalone UCS server or FI-attached UCS server.

• UCS Server Profile Template—The template attached to the server profile or from which the profile has been derived.

• Template Sync Status—The sync status between the server profile and the template from which the server profile has been derived.

• Server—The name of the server to which the profile is attached.

• Resource Pool—The pool to which the profile belongs.

• User Label—Displays the assigned user label that helps in identification of the server profiles.

• Last Update—The date on which the profile was last updated.

• Organization—The name of the organization.

Server Profile Actions

After creating server profiles, actions that can be performed on a server profile are as follows:

• Deploy—Deploy the profile to the attached server.

• Activate—Activate the profile on the attached server. The server gets power cycled on activation.

• Assign Server—Assign a server to the server profile.

• Edit Assignment—Modify the assigned server in the server profile, provided that the profile has not yet been deployed.

  Note:

  To modify the server assignment for a deployed profile, first unassign the existing server, and then assign the new server using the Server Profile Actions menu.

• Unassign Server—Unassign the server from the profile. This action will cause the server configurations to reset to defaults. For more information, see Clearing and Resetting Server Configurations.

• Clone—Clone the profile.

• Edit—Edit the profile.

• Delete—Delete the profile.

• Set User Label—Allows you to set, update, or delete user labels for each server. It must be between 1 and 64 alphanumeric characters, containing only the following special characters: ! # $ % & * + , ( ) [ ] { } | / . ? @ _ : ; ~

• Attach to Template—Attach the server profile to any of the available templates.

  Note:

  • While template creation, if you toggle ON the Attach UCS Server Profile to Profile Template button, the selected profile gets attached to the template under creation.

  • If you keep the toggle button OFF, the selected profile's properties are carried to the template but the profile does not get attached to it.

• Create a Template—A server profile can be used to create a template. This template can then be used to create multiple profiles with same configurations and deployed on multiple servers.

• Detach from Template—Detach the profile from the template.

  Note:

  • Create a Template and Attach to Template actions can be performed only if a server profile is not attached to any template.

  • A server profile can be attached to an existing template. This attachment overrides the config properties of the profile and replaces them with the template properties.

  • A server profile attached to a template cannot be modified. The modifications can only be done in the associated template.

  • A server profile can be detached from a template and modified as per the requirements.

  • A detached server profile can always be reattached to a template.

• Sync With Template—Synchronize the Out of Sync profiles to ensure alignment with template configurations.

• Server Actions—Allows you to perform following actions on the assigned server:

  • Power

  • Install Operating System

  • Launch vKVM

  • Launch Tunneled vKVM

  For a detailed description of these actions, refer to Server Actions.

Server Profile Details View

From the Server Profile List View, click a profile name to open the Server Profile Details View. This page has four tabs: General, Server, Inventory, and Connectivity. The General tab shows profile information and real-time status of any pending changes from previous server deployments. The other three tabs display detailed information about the assigned server.

General — The General tab has two sections: Details and Configuration.

• Details section displays the Status, Name, Description, User Label, Target Platform, Template Name, and Organization. You can also view Server Assignment fields (Assigned Server and Assignment Type) and any configured Tags.

• Configuration section displays Policies (attached policies), Identifiers (UUID assignments), vNICs/vHBAs (placement details), and any Errors & Warnings.

You can edit Server Profile configurations directly from this tab, in addition to using the Edit action under Server Profile Actions. This method simplifies the workflow and saves time by eliminating the need to navigate through the wizard.

Editing a Server Profile

To edit a server profile from Server Profile Details View:

1. Log in to Cisco Intersight with Account Administrator or Server Administrator role.

2. Choose Configure > Profiles > UCS Server Profiles.

3. Select the desired profile to edit by clicking its Name. The Server Profile Details View appears.

   Note:

   You can also modify the Server Profile by using the Edit action under Server Profile Actions. This will guide you through the full wizard to apply your changes. For more information, see Configuring UCS Server Profiles.

4. To modify the general information, under Details section:

   1. Click Edit next to General.

   2. On the Edit General Details page, edit the Name, Description, or User Label as required.

   3. Click Save.

5. To modify the server assignment, scroll down to Server Assignment under Details section:

   1. Click on Assign to assign a server to the server profile.

   2. On Assign Server to UCS Server Profile: <Profile Name> page, choose to assign a specific server, either from a resource pool, by chassis slot location or by serial number.

   3. Click Assign.

      Note:

      If a server is already assigned to a UCS Server Profile and the profile is deployed, you cannot modify the server assignment. To change the server assignment, first unassign the server from the profile, then assign the new server. However, if the profile has not been deployed, you can modify the server assignment.

6. To modify the policies attached, go to Configuration > Policies:

   1. Toggle off the Show Attached Policies button. All the available policies under Compute, Management, Storage, and Network categories appears.

      Note:

      The Show Attached Policies toggle is enabled by default, displaying only the list of attached policies.

   2. To attach a policy, hover over the policy name and click Select Policy . Select the required policy or create a new policy in the side navigation window. For more information on the Server Policies, see Server Policies.

   3. To detach a policy, hover over the attached policy name and click Detach . A confirmation message “Policy <policy name> will be detached, and default configuration will be applied.” appears. Click Detach to confirm.

   4. Click Preview to view the details of the attached policy.

   5. Click Edit to edit the attached policy.

      Note:

      If you modify or add a policy to a deployed Server Profile, its Status changes to Inconsistent, indicating pending changes that differ from the previously deployed configuration.

7. To modify the UUID, go to Configuration > Identifiers:

   1. In Identifiers section, hover over the UUID and click Assign. The Assign UUID page appears.

   2. Choose the appropriate UUID from Pool or Static options:

      • Pool— Allows UUID Pool association to the server. Select the required pool from the list available. For more information on pools, see Pools.

      • Static— Allows UUID association to the server using Static UUID address, by entering the full UUID address for the server. It must include both the UUID prefix and the UUID suffix. For example, the prefix could be 69F8FB36-67F3-4BC3 and the suffix could be 0002-000000000001.

   3. Click Assign.

   4. To detach a UUID, hover over the Assigned UUID Pool and click to detach. A confirmation message “UUID pool <pool name> will be detached from the profile.” appears. Click Detach to confirm. For more information, see UUID Pools.

      Note:

      If you modify or add a UUID pool to a deployed Server Profile, its Status changes to Inconsistent, indicating pending changes that differ from the previously deployed configuration.

8. To modify vNIC/vHBA placements, go to Configuration > vNICs / vHBAs:

   1. In vNICs/vHBAs section, scroll down to Auto Placement Configuration and click Edit Placement. Make the required changes in vNICs & vHBAs and click Save.

      • Auto Placement Configuration is available only for IMM Servers.

      • Graphical representation of vNICs & vHBAs placement is only applicable for Auto Configuration mode.

9. To view errors and warnings, go to Configuration > Errors/Warnings, and review the listed items.

Server—The Server tab displays the details of the assigned server and its properties.

Inventory—The Inventory tab displays the inventory details of the assigned server.

Connectivity— The Connectivity tab displays the network connectivity details such as vNIC/vHBA, Network Adapter, Virtual Circuit, FI details and so on.

For more information, see Servers Details View.

Server Profile Drift

A server profile drift occurs when the policy configuration at the endpoint is not in sync with the last deployed policy configuration in the Server Profile.

Cisco Intersight supports Server Profile Drift detection for standalone servers and Intersight Managed Mode servers. For Intersight Managed Mode servers, the firmware versions required for drift detection are:

• For 4.2 release, the Cisco IMC version must be 4.2(1b) or above.

• For 4.1 release, the Cisco IMC versions must be:

  • For rack servers - 4.1(3d) or above

  • For blade servers - 4.1(33e) or above

The check to look up for any configuration change at the endpoint is performed every 30 min.

To see the policy configurations that have changed at the endpoint relative to the currently deployed policy configuration in Intersight, navigate to server profile details view and click View Changes. You can choose to view the Changes Only or All the policy configuration details.

To move the Server Profile status back to OK, you can either redeploy the profile or change the values at the endpoint. You can use the Device Connector Policy in Intersight to control configuration changes allowed from Cisco IMC. In the Device Connector Policy, choose Configuration from Intersight only to stop allowing configuration changes from Cisco IMC directly.

Limitations of Server Profile Drift - Standalone Servers

For standalone servers, configuration changes at the endpoint will not be detected for the following policies under the specified conditions:

Limitations of Server Profile Drift - Intersight Managed Mode Servers

For Intersight Managed Mode servers, server configuration changes at the endpoint will not be detected for the following policies under the specified conditions:

Server Profile Import

Intersight provides the capability to import configuration details of C-series servers in standalone mode and FI-attached servers in Intersight Managed Mode (IMM), directly from Cisco IMC. The Server Profile import enables you to migrate the configuration of your existing servers to Intersight without having to create a profile and the policies manually. The Server Profile import operation creates a profile and the associated policies based on the server configuration. You can create a golden configuration profile and clone it and apply to another server already claimed in Intersight.

You can import a server profile configuration from the following locations in Intersight:

• Servers table view—Select a Cisco UCS C-Series Standalone server in Intersight Managed Mode (IMM) from the table view and click the ellipses (…) and select Import Server Profile.

• Click a C-series server in standalone mode in Intersight Managed Mode (IMM) in the Servers table view to access the Server details page. Click Actions on the top-right corner and select Import Server Profile. This option is enabled only when no server profile is associated with the server.

For more information on how to import a Server Profile Import and about the detection of manual configuration changes at the endpoint, see Importing a Server Profile in Resources.

Estimate Impact

The Estimate Impact workflow, for standalone and Intersight Managed Mode servers, analyzes the disruptions that would be caused by the various policies attached to a server profile, when the server profile is deployed. The analyze impact workflow is triggered when a policy is attached, detached, or updated. The Disruption is indicated against each policy. The disruptions, which could be caused by the policies, are:

• Immediate reboot is required for standalone server policies such as Persistent Memory policy or Adapter policy. In such cases, the disruption indicated against the policy is Immediate Reboot.

• An Activate action on the server profile needs the server to reboot and activate the policy configuration on the server. In such cases, the disruption indicated against the policy is Activate Requires Reboot.

• Some policies, such as IMC Access policy, cause a brief outage of the server management network. In such cases, the disruption indicated against the policy is Network Management Outage.

Deploying and Activating a Server Profile

Deploy and Activate are two explicit actions that can be performed on server profiles. Policy configuration staging happens as a part of server profile deployment. Policy staging allows you to stage the policy configurations and get an idea of the pending actions for activating the policies. You can activate the policy by rebooting servers manually or using the Activate action of the Server Profile during a maintenance window. Policy activation failures are identified when the Activate action is triggered.

The Status widget in the Server Profiles table view shows the number of profiles in Inconsistent state. A server profile will be in the Inconsistent state when it has policy changes that have not yet been deployed or activated. The Inconsistency Reason widget shows the reason why a profile is in the Inconsistent state. A server profile could be in an Inconsistent state because:

• There are changes in the policies attached to the server profile assigned to the server.

• The policy configuration is out-of-sync with the configuration deployed in the endpoints.

• The policy is in Not Activated state.

You can use Deploy action to stage the configuration changes. By default, only the modified policies along with any dependent policies are deployed. For more information on dependent policies, see the Policy Dependency Matrix below.

• You can check the Deploy all associated policies whether modified or not check box to deploy all the policies attached to the server profile.

• You can check the Reboot Immediately to Activate check box to enable the server to reboot and activate the server profile immediately. If unchecked, the policy configuration changes are activated at the next reboot.

• You must check the I understand that potential disruption may occur during profile deployment check box to proceed.

  Note:

  The third check box appears when profile changes might lead to potential disruptions, such as reboots or network outages. If this checkbox appears, you must acknowledge it to proceed.

Click Deploy to proceed.

The Activate action reboots the server and activates the configuration on the server. You can also opt to trigger Deploy to stage the configuration changes and later trigger Activate, during the maintenance window, to activate the deployed configuration.

On the Policy Edit page, when you edit a policy, the Save & Deploy option, deploys only the edited policy and its dependents from where the deployment is initiated, by default. This action applies the changes to all server profiles associated with the policy.

• You can check the Deploy all associated policies whether modified or not check box to deploy all the policies attached to the server profile.

• You can check the Reboot Immediately to Activate check box to enable the server to reboot and activate the server profile immediately. If unchecked, the policy configuration changes are activated at the next reboot.

• You must check the I understand that potential disruption may occur during profile deployment check box to proceed.

  Note:

  The third check box appears when profile changes might lead to potential disruptions, such as reboots or network outages. If this checkbox appears, you must acknowledge it to proceed.

Policy Dependency Matrix

In Cisco Intersight, Server Profile Templates enable the user to define a template from which multiple server profiles can be derived and deployed. Any property modification made in the template syncs with all the derived profiles. You can deploy these modified profiles individually. This feature helps in the quick and easy configuration as multiple profiles can be created and edited simultaneously.

Choose Configure > Templates, to launch the Profile Template Table view.

Server Profile Template List View

When you select Templates in the Intersight UI, the UCS Server Profile Templates list view is seen.

The list view shows the following details in a tabular format:

• Name—The name of the Server Profile Template.

• Sync Status—The sync status between the template and its derived profiles. The status of the template changes to Out of Sync, even if one of its derived profile is out of sync.

• Usage—The count of the server profiles derived from the template.

• Target Platform—Indicates if the platform for which the profile is applicable is a Standalone UCS server or FI-attached UCS server.

• Description—The description of the template provided during template creation.

• Last Update—The date on which the template was last updated.

• Organization—The name of the organization.

For more information on how to create a UCS Server Profile Template, see Creating Server Profile Template

Server Profile Template Actions

Actions that can be performed on a Server Profile Template are as follows:

• Derive Profiles—You can derive multiple profiles from a single template. You can use the option of Derive Profiles while creating a template or use the option of Derive Profiles present on the template list view.

  Note: A maximum of 100 profiles can be derived from a template in a single action at any given time. The derive action can be repeated multiple times to derive a maximum of 400 profiles from a template.

• Sync Profiles with Template—You can synchronize the Out of Sync profiles with their templates.

• Clone—You can clone the server profile template to create multiple copies across one or more Organizations. Each copy can have a unique name, description, and tags. For more information, see Cloning a Server Profile Template Across Organizations.

• Delete—You can delete a server profile template only if its corresponding usage value (the number of derived profiles) is 0.

• Edit—You can edit the template at any time. Any edit made in the template gets reflected in the derived server profiles. The Status of all the derived profiles changes to Not Deployed Changes after template update.

  Note: Not Deployed Changes will be shown only for deployed profiles whose status is OK else it will not be shown.

Server Profile Template Detail View

Clicking on the name of the template redirects to the Server Profile Template Detail View.

The detail view shows the configuration properties of the template, details of the attached profiles, and vNIC/vHBA details. It also displays an Action button that lists out the actions that can be performed on the template.

Policies in Cisco Intersight provide different configurations for UCS servers including BIOS settings, Simple Mail Transfer Protocol (SMTP), Intelligent Platform Management Interface (IPMI) settings and more. A policy that is once configured can be assigned to any number of servers in order to provide a configuration baseline. Policies in Cisco Intersight are native to the application and are not directly imported from the UCS Systems. Policy-based configuration with Server Profiles is a Cisco Intersight Essentials license tier functionality.

Certain server configurations applied through policies are automatically cleared and reset to default settings in Intersight Managed Mode servers. This occurs under the following conditions: when policies are detached and the profile is re-deployed, when a server is unassigned from a profile, during first-time discovery, decommissioning, or during recommissioning of a server. For more information, see Clearing and Resetting Server Configurations.

To launch the Policies Table View, choose Configure > Policies.

The Server Policy creation wizard in Cisco Intersight has two pages:

• General—The general page allows to select the organization and enter a name for policy. Optionally, include a short description and tag information to help identify the policy. Tags must be in the key:value format. For example, Org: IT or Site: APJ.

• Policy Details—The policy details page has properties that are applicable to standalone UCS servers, FI-attached UCS servers, or both. You can view these properties separately for All Platforms, UCS Servers (Standalone), and UCS Servers (FI-Attached) by clicking on these options.

Server Policies can be imported as part of importing configuration details (server profiles and policies) of a Cisco C-Series Standalone server from Cisco IMC. For more information, see Importing a Server Profile.

Server Policies can also be cloned by using the Policy Clone wizard with properties that are similar to the existing policies. The clone policy action is available on both the policies list and detailed views. For more information, see Cloning a Policy.

You can compare up to five policies of the same type from the Policies List View page to identify configuration differences, maintain consistency, and simplify troubleshooting.

To compare policies, select the checkboxes next to the desired policies, click the ellipsis (…) at the top left of the page, and choose Compare. On the Compare side drawer, only the differences between the selected policies are shown by default. To display all parameters, select All from the Display drop-down menu.

The Policies List View displays the Name of the policy, Platform Type to which the policy is applicable, Type of the policy, Usage of the policy in profiles and templates, and the Last Updated timestamp for the policy. For more information on policy usage, see Policy Usage Details.

Clicking on a policy redirects to the Policies Detail View which shows the details of the policy usage such as the Name, Status, Platform Type, Type (whether template or profile), Device Name and Last Updated time stamp of the template/profile to which the policy is attached.

The following list describes the server policies that you can configure in Cisco Intersight.

• Adapter Configuration Policy—Configures the Ethernet and Fibre-Channel settings for the VIC adapter.

• BIOS Policy—Automates the configuration of BIOS settings on the managed devices. You can create one or more BIOS policies which contain a specific grouping of BIOS settings. If you do not specify a BIOS policy for a server, the BIOS settings remain as they are. If a BIOS policy is specified, the values that are specified in the policy replace any previously configured values on a server (including bare metal server configuration settings). To apply the BIOS policy settings, you must reboot the server.

  To simplify creating a BIOS policy, you can use a pre-defined Cisco Provided BIOS Configuration. These configurations are ready to use without requiring any modifications. For more information, see BIOS Policy.

  Note:

  If you are using a Cisco Provided Configuration in a policy, you can still modify the configurations while you create the policy. However, you cannot modify the default Cisco Provided Configurations.

• Boot Order Policy—Allows you to configure the boot mode and your preferred boot device(s). You can specify the order in which the server attempts to boot from the configured devices. The supported boot devices are listed in the Policy Details.

  The inventory view enables you to view the actual boot order configured on a server. The boot order displays the details that include device name, device type, configuration details such as Boot Mode (Legacy or UEFI), and Secure Boot Mode (Enabled or Disabled).

  Note:

  • The boot mode configured in the server profile of Boot Order Policy will take effect only after the next host reboot.

  • A device configured in the server profile of Boot Order Policy may not appear in the actual boot order, if the server BIOS does not detect the device during server boot.

  Device Naming Guidelines: The reserved keywords that cannot be used as boot device names include: all, ALL, CDROM, EFI, EOD, FDD, HDD, HDDANY, HTTP, ISCSI, ISCSIANY, LOCALCDD, LOCALHDD, NULL, NVME, NVMEANY,PCHSTORAGE, PCHSTORANY, PXE, SAN, SANANY, SDANY, SDCARD, UEFISHELL, USB, USBCD, USBFDD, USBHDD, VMCIMCCD, VMCIMCHDD, VMEDIA, VMFDD, VMKVMCD, and VMKVMHDD. However, these keywords can be combined with other characters, such as letters, numbers, underscores, and hyphens (e.g., EU_PXE-3), and then used as boot device names.

  Intersight provides a One-Time Boot (OTB) option to set a boot device that temporarily overrides the Boot Order Policy and the existing boot order. To set a One-Time Boot Device, select Power Cycle or Power On from the Servers Table view or from the Server Details page and toggle ON the Set One Time Boot Device Option. This operation attempts to boot from the One Time Boot device as part of the power cycle or power on action. After power cycle or power on, OTB configuration will be cleared to enable the next reboot to follow the default Boot Order.

  Note:

  • The OTB option is available for servers that have been configured with a Boot Order Policy that is associated with a server profile. For a successful OTB configuration, you must deploy a server profile with a Boot Order Policy in Intersight in advance.

  • Any out-of-band-boot order change will not reflect on the Intersight UI for OTB device configuration.

  In the case of HTTP Boot configuration, configure the HTTP Boot drive as bootable in the UEFI mode. To use HTTP Boot, configure a vNIC with its name or MAC address and add both HTTP Boot and PXE Boot to the boot policy. Note that adding PXE Boot to the boot policy enables PXE Boot on the same vNIC, which is a prerequisite for HTTP Boot to work.

  In the case of PXE Boot configuration, importing the server policy will not create the PXE device under boot policy if either the MAC address or both the slot and port are not present for a given PXE device under the Boot policy on the server. However, if both slot and port are present, boot order is set to ANY for the bootable interface on a given slot on the server. For non-VIC adapters you can configure PXE Boot with the MAC address, or both the slot and port, or slot only.

  In the case of SAN Boot device configuration in the legacy mode, provide the boot target Logical Unit Number (LUN), device slot ID, interface name, and target WWPN. For SAN Boot device configuration in the Unified Extensible Firmware Interface (UEFI) mode, provide the bootloader name, description, and path in addition to the fields listed in the legacy mode.

  In the case of iSCSI Boot provide the target interface details, authentication mechanism, and initiator IP source. You can configure iSCSI boot using either IPv4 or IPv6.

  In the case of Nonvolatile Memory Express (NVMe) Boot, configure the NVMe drive as bootable in the UEFI mode. During the server profile deployment, this NVMe configuration setting enables selecting the BIOS in a defined order.

• Certificate Management Policy—Allows you to specify the certificate details for an external certificate and attach the policy to servers. Cisco Intersight currently supports the following certificates:

  • Root CA certificates

  • IMC certificates

• Device Connector Policy—Lets you choose the Configuration from Intersight only option to control configuration changes allowed from Cisco IMC. The Configuration from Intersight only option is enabled by default. You will observe the following changes when you deploy the Device Connector policy in Intersight:

  • Validation tasks will fail:

    • If Intersight Read-only mode is enabled in the claimed device.

    • If the firmware version of the Cisco UCS Standalone C-Series Servers is lower than 4.0(1).

  • If Intersight Read-only mode is enabled, firmware upgrades will be successful only when performed from Intersight. Firmware upgrade performed locally from Cisco IMC will fail.

  • IPMI over LAN privileges will be reset to read-only level if Configuration from Intersight only is enabled through the Device Connector policy, or if the same configuration is enabled in the Device Connector in Cisco IMC.

    Attention: The Device Connector Policy will not be imported as part of the Server Profile Import.

• Disk Group Policy—Disk Group Policy is now a part of Storage Policy.

• Ethernet Adapter Policy—Governs the host-side behavior of the adapter, including how the adapter handles traffic. For each VIC Virtual Ethernet Interface, you can configure various features like VXLAN, NVGRE, ARFS, Interrupt settings, and TCP Offload settings.

  To simplify creating an Ethernet Adapter policy, you can use a pre-defined Cisco Provided Ethernet Adapter Configuration. These configurations are ready to use without requiring any modifications. For more information, see Ethernet Adapter Policy.

  Note:

  If you are using a Cisco Provided Configuration in a policy, you can still modify the configurations while you create the policy. However, you cannot modify the default Cisco Provided Configurations.

• Ethernet Network Policy—Determines if the port can carry single VLAN(Access) or multiple VLANs(Trunk) traffic. You can specify the VLAN to be associated with an Ethernet packet if no tag is found.

• Ethernet Network Control Policy—Configures the network control settings for the appliance ports, appliance port channels, or vNICs.

• Ethernet Network Group Policy—Configures the allowed VLAN and native VLAN for the appliance ports, appliance port channels, or vNICs.

  You can add multiple Ethernet Network Group Policies (ENGPs) on vNICs for LAN Connectivity Policy or vNIC templates, For more information, see LAN Connectivity Policy.

• Ethernet QoS Policy—Assigns a system class to the outgoing traffic for a vNIC. This system class determines the quality of service for the outgoing traffic. For certain adapters, you can also specify additional controls like burst and rate on the outgoing traffic.

• FC Zone Policy—Allows you to set up access control between hosts and storage devices. You can create a Single Initiator Single Target, or Single Initiator Multiple Target Zone on a VSAN with the scope FC Storage, and attach the Zone policy to the SAN Connectivity policy using the vHBA.

  Note:

  You can configure zones only when the Fabric Interconnect is in FC switching mode

  Configuration drift is not supported for the FC Zone policy

• Fibre Channel Adapter Policy—Governs the host-side behavior of the adapter, including how the adapter handles traffic. You can enable FCP Error Recovery, change the default settings of Queues, and Interrupt handling for performance enhancement.

  To simplify creating an Fibre Channel Adapter policy, you can use a pre-defined Cisco Provided Fibre Channel Adapter Configuration. These configurations are ready to use without requiring any modifications. For more information, see Fibre Channel Adaptor Policy.

  Note:

  If you are using a Cisco Provided Configuration in a policy, you can still modify the configurations while you create the policy. However, you cannot modify the default Cisco Provided Configurations.

• Fibre Channel Network Policy—Governs the VSAN configuration for the virtual interfaces.

• Fibre Channel QoS Policy—Assigns a system class to the outgoing traffic for a vHBA. This system class determines the quality of service for the outgoing traffic. For certain adapters, you can also specify additional controls like burst and rate on the outgoing traffic.

• ID Mapping Policy—Links resource groups or organizations to specific IP blocks within an IP pool, allowing you to control IP address allocation during deployments. Create this policy at the organization or shared organization level.

• IMC Access Policy—Enables configuration and management of the network by mapping IP pools to the server profile. It allows In-Band and Out-of-Band configurations, with association to an IP address from the IP pool. The policy also permits forwarding SNMP traffic over In-Band and Out-of-Band configurations.

  In-Band IP address, Out-of-Band IP address, or both In-Band and Out-of-Band IP addresses can be configured using IMC Access Policy and are supported on the following:

  • Drive Security, SNMP, Syslog, and vMedia policies

  • vKVM, IPMI, SOL, and vMedia policies using vKVM client

  Note:

  When both In-Band and Out-of-Band IP addresses are configured, In-Band IP address is the default preference. For more information, see Creating IMC Access Policy.

• IPMI over LAN Policy—Defines the protocols for interfacing with a service processor that is embedded in a server platform. The Intelligent Platform Management Interface (IPMI) enables an operating system to obtain information about the system health and control system hardware and directs the Cisco IMC to perform required actions. You can create an IPMI Over LAN policy to manage the IPMI messages through Cisco Intersight. You can assign these user roles to an IPMI user per session:

  • admin—IPMI users can perform all available actions. If you select this option, IPMI users with the "Administrator" user role can create admin, user, and read-only sessions on this server.

  • read-only—Can view information but cannot make any changes. IPMI users with the "Administrator", "Operator", or "User" user roles can only create read-only IPMI sessions, regardless of their other IPMI privileges.

  • user—IPMI users can perform some functions but cannot perform administrative tasks. If you select this option, IPMI users with the "Administrator" or "Operator" user role can create user and read-only sessions on this server.

  Important: The encryption key to use for IPMI communication should have an even number of hexadecimal characters and not exceed 40 characters. You can use "00" to disable the encryption key use. If the encryption key specified is less than 40 characters, then the IPMI commands must add zeroes to the encryption key to achieve a length of 40 characters.

• LAN Connectivity Policy—Determines the connections and the network communication resources between the server and the LAN on the network. You must create the Ethernet Adapter, Ethernet QoS, and Ethernet Network policies as part of the LAN connectivity policy. For IMM servers, use a MAC pool, or static MAC addresses, to assign MAC addresses to servers and to identify the vNICs that the servers use to communicate with the network. For more information about creating Network Policies, see Creating Network Policies.

• LDAP Policy—Specifies the LDAP configuration settings and preferences for an endpoint. The endpoints support LDAP to store and maintain directory information in a network. The LDAP policy determines configuration settings for LDAP Servers, DNS parameters including options to obtain a domain name used for the DNS SRV request, Binding methods, Search parameters, and Group Authorization preferences. Through an LDAP policy, you can also create multiple LDAP groups and add them to the LDAP server database.

• Local User Policy—Automates the configuration of local user preferences. You can create one or more Local User policies which contain a list of local users that need to be configured.

  Note: If the user already exists on the endpoint (from a previous UCS server profile deployment) and if password history is enabled, then associating a new local user policy with the same username and password will cause password getting configured at the endpoint during UCS server profile deployment. This will result in UCS server profile deployment failure. To disable password history on the endpoint, set the value to 0.

• NTP Policy—Allows you to enable the NTP service on an Intersight Managed Cisco IMC (Standalone) server. The NTP service synchronizes the time with an NTP server. You must enable and configure the NTP service by specifying the IP address or DNS of a minimum of one to a maximum of four NTP servers.

  NTP policy also allows you to configure the timezone on Cisco IMC (Standalone) server. When you enable the NTP service and select Timezone, Cisco Intersight configures the NTP details and Timezone on the endpoint.

• Persistent Memory Policy—Persistent Memory Modules (PMem Modules) are non-volatile memory modules that bring together the low latency of memory and the persistence of storage. PMem Modules provide faster access to data and retain across power cycles, based on the mode. Intersight supports the configuration of Intel® Optane™ PMem Module. These modules can be used only with the Second-Generation Intel® Xeon® Scalable processors. The Persistent Memory Policy allows the configuration of security, Goals, and Namespaces of Persistent Memory Modules:

  • Security—Used to configure the secure passphrase for all the persistent memory modules.

  • Goal—Used to configure volatile memory and regions in all the PMem Modules connected to all the sockets of the server. Intersight supports only the creation and modification of a Goal as part of the Persistent Memory policy. Some data loss occurs when a Goal is modified during the creation or modification of a Persistent Memory Policy. For information on the data loss, see the Data Loss during Persistent Memory Policy Configuration and Deployment table in Resources.

  • Namespaces—Used to partition a region mapped to a specific socket or a PMem Module on a socket. Intersight supports only the creation and deletion of Namespaces as part of the Persistent Memory Policy. Modifying a Namespace is not supported. Some data loss occurs when a Namespace is created or deleted during the creation of a Persistent Memory policy. For information on the data loss, see the Data Loss during Persistent Memory Policy Configuration and Deployment table in Resources.

    It is important to consider the memory performance guidelines and population rules of the Persistent Memory Modules before they are installed or replaced, and the policy is deployed. The population guidelines for the PMem Modules can be divided into the following categories, based on the number of CPU sockets:

    • Dual CPU for UCS X210c M6 and UCS X210c M7

    • Dual CPU for UCS C220 M7 and UCS C240 M7 servers.

    • Dual CPU for UCS C220 M6, C240 M6, and B200 M6 servers

    • Dual CPU for UCS C220 M5, C240 M5, and B200 M5 servers

    • Quad CPU for UCS C480 M5 and B480 M5 servers

    • Dual CPU for UCS S3260 M5 servers

    For more information about creating a Persistent Memory policy, exceptions to the policy, and other caveats regarding the policy, see Persistent Memory Policy in Resources section.

• Power Policy—Enables the management of power for FI-attached servers and chassis. This policy allows you to set the power profiling, power priority of the server, and the power restore state of the system. For more information, see Creating a Power Policy for Server

• SAN Connectivity Policy—Determines the network storage resources and the connections between the server and the SAN on the network. This policy enables you to configure vHBAs that the servers use to communicate with the Storage Area Network. You can use WWPN and WWNN address pools, or static WWPN and WWNN addresses, to add vHBAs and to configure them. You must create the Fibre Channel Adapter, Fibre Channel QoS, and Fibre Channel Network policies as part of the SAN connectivity policy. For more information about creating Network policies, see Creating Network Policies.

• SD Card Policy—Configures the Cisco FlexFlash and FlexUtil Secure Digital (SD) cards for the Cisco UCS C-Series M4, M5 servers in standalone mode and Cisco UCS C-Series M5, B-Series M5 servers in Intersight Managed Mode. This policy specifies details of virtual drives on the SD cards. You can configure the SD cards in the Operating System Only, Utility Only, or Operating System + Utility modes.

  When two cards are present in the Cisco FlexFlash controller and Operating System is chosen in the SD card policy, the configured OS partition is mirrored. If only single card is available in the Cisco FlexFlash controller, the configured OS partition is non-RAID. The utility partitions are always set as non-RAID.

  Note:

  1. This policy is not supported M6 server onwards.

  2. You can enable up to two utility virtual drives on M5 servers, and any number of supported utility virtual drives on M4 servers.

  3. Diagnostics is supported only for the M5 servers.

  4. UserPartition drives can be renamed only on the M4 servers.

  5. FlexFlash configuration is not supported on C460 M4 servers.

  6. For the Operating System+Utility mode, the M4 servers require two FlexFlash cards, and the M5 servers require at least 1 FlexFlash + 1 FlexUtil card.

• Server Pool Qualification Policy— The Server Pool Qualification policy includes qualifiers that act as criteria for the automatic inclusion of servers in a resource pool. You can associate one or more Server Pool Qualification Policies (up to a maximum of 10) with a resource pool. When multiple policies are applied, the resource pool members will consist of the combined set of servers that meet the criteria of each policy. For more information, see Server Pool Qualification Policy.

• Simple Mail Transfer Protocol (SMTP) Policy—Sets the state of the SMTP client in the managed device. You can specify the preferred settings for outgoing communication and select the fault severity level to report and the mail recipients.

• Simple Network Management Protocol (SNMP) Policy—Configures the SNMP settings for sending fault and alert information by SNMP traps from the managed devices. Any existing SNMP Users or SNMP Traps configured previously on the managed devices are removed and replaced with users or traps that you configure in this policy. If you have not added any users or traps in the policy, the existing users or traps on the server are removed but not replaced.

• Serial Over LAN (SOL) Policy—Enables the input and output of the serial port of a managed system to be redirected over IP. You can create one or more Serial over LAN policies which contain a specific grouping of Serial over LAN attributes that match the needs of a server or a set of servers.

• SSH Policy—Enables an Secure Shell (SSH) client to make a secure, encrypted connection. You can create one or more SSH policies that contain a specific grouping of SSH properties for a server or a set of servers.

• Storage Policy—Allows you to create drive groups and virtual drives, configure the storage capacity of a virtual drive, and configure the M.2 RAID controllers.

• Syslog Policy—Defines the logging level (minimum severity) to report for a log file collected from an endpoint, the target destination to store the Syslog messages, and the Hostname/IP Address, port information, and communication protocol for the Remote Logging Server(s).

• Virtual Media Policy—Enables you to install an operating system on the server using the KVM console and virtual media, mount files to the host from a remote file share, and enable virtual media encryption. You can create one or more Virtual Media policies which contain virtual media mappings for different OS images, and configure up to two virtual media mappings, one for ISO files (through CDD), and the other for IMG files (through HDD).

  For more information about the various mount options for the Virtual Media volumes, see Virtual Media Mount options.

• Virtual KVM—Enables specific grouping of virtual KVM properties. This policy lets you specify the number of allowed concurrent KVM sessions, port information, and video encryption options.

When you select Configure > Policies in the Intersight UI, the Policies List View is seen.

The list view shows the 'Usage' column which shows the consumption details of the policy.

Usage is categorized as:

• Used: The policy is being directly used by one or more profiles and/or templates. The profiles and templates using the policy can be viewed on the Policies Details View page.

  Note:

  An Account Administrator can view the total usage count of all profiles and templates where the policy is used.

• Not Used: The policy is not being used by any profile or template.

• Used - Indirect: The policy is a sub-policy that is being used by one or more policies, which are directly attached to profiles and/or templates.

  The profiles and templates using the sub-policy can be viewed under the Profiles and Templates tab on the Policies Details View page. The policies that directly reference this sub-policy are listed under the Policies tab on the Policies Details View page.

• Not Used - Indirect: The policy is a sub-policy that is not being used by any policy, profile, or template.

  The policies that directly reference this sub-policy can be viewed under the Policies tab on the Policies Details View page.

The list view shows two widgets above the table. These are:

Platform Type: A pie chart showing the distribution of server, chassis, and domain policies.

Usage: A pie chart indicating the proportion of policies that are Used, Not Used, or Indirect.

Click on segments within the pie charts to filter the list view accordingly.

Cisco Intersight automatically clears and resets endpoint configurations associated with certain server policies in Intersight Managed Mode. This functionality reverts endpoint configurations to their default settings, ensuring reliable and consistent configuration management. It prevents issues caused by residual configurations during various server lifecycle events. Intersight resets server configurations in the following scenarios:

• During the first-time discovery of a server.

• During the recommissioning of a server.

• When a server is unassigned from a profile.

• When policies are detached from a deployed profile and the profile is re-deployed on a server.

The configuration reset causes the following changes to the server configurations:

• BIOS Policy—All the tokens are reset to default values. For more information on the default values, see Cisco UCS Server BIOS Tokens.

• Boot Order Policy—Boot devices are removed. Boot mode is set to UEFI and Secure boot is disabled. Server boots to UEFI shell on restart.

• Certificate Management Policy—When a server is unassigned from a server profile, the Root CA certificates and IMC certificates are deleted. However, during the first-time discovery or recommissioning of the server, the certificates are not deleted.

• IMC Access Policy—In-Band and Out-Of-Band settings are cleared.

• IPMI over LAN Policy—IPMI over LAN is disabled, and the Encryption Key is set to 0.

• LAN Connectivity Policy—vNICs are removed.

• Local User Policy—The admin account is assigned a random, undisclosed password, effectively disabling it. You can deploy the Server Profile to set the admin account password. All other user accounts are deleted.

• Memory Policy—DIMM blocklisting is disabled.

• Power Policy—Power profiling is enabled, Power Priority is set to Low, and Power Restore is set to Always Off.

• SAN Connectivity Policy—vHBAs are removed.

• Serial Over LAN Policy—Serial over LAN is disabled and the Baud Rate is set to 115200.

• SNMP Policy—SNMP is disabled, the Port is set to 161, and all SNMP users and traps are deleted.

• Syslog Policy—Minimum Severity to Report is set to Debug in Local Logging, and the remote logging servers are removed.

• Thermal Policy—FanControlMode is set to Acoustic mode.

• Virtual KVM Policy—Virtual KVM is enabled and Remote Port is set to 2068.

• Virtual Media Policy—Virtual Media is enabled, and the Virtual Media mounts are removed.

• UUID—The UUID address is cleared.

• Asset Tag—Is cleared.

• User Label—Is cleared.

The following server policy configurations will not be impacted or modified by this functionality:

• Firmware Policy

• Drive Security Policy

• SD Card Policy

• Storage Policy

• Scrub Policy

About Pools

Pools are the basic building blocks for uniquely identifying hardware resources. They form the foundation of the UCS management model, enabling the association of Server Profiles with blade servers while maintaining the same ID and presentation to the upstream LAN or SAN.

Pools are classified into Resource Pools and Identity (ID) Pools.

Using the Pools Table View, you can monitor the utilization of Server Pools, track Available and Used identifiers, and make informed decisions regarding pool capacity and allocation.

Resource Pools

Pools enable you to logically group and manage resources (servers and other endpoints) more efficiently. You can assign servers to a resource pool and can continue with the automated server profile assignment. For more information on the server profile association using resource pools, see Configuring Server Profiles.

Persistent Resource Pool Assignment

When a server that is a part of a pool is decommissioned, it appears in the Decommissioned Resources section of the Resource Pool Details View and Server Details View. When the server is recommissioned, it gets assigned to the same pool again. The same behavior occurs when a server is decommissioned, moved to a different chassis or slot, and then recommissioned. Thus, you do not need to manage the pool reassignment for that server when physical changes occur in the deployment environment.

Change in Behavior for API or Terraform Users

API or Terraform users can use APIs to create new Resource Pools using either Managed Object IDs (MOIDs) or Serial selectors.

However, if an API user edits a Resource Pool that uses a MOID from the UI to enable persistent Resource Pool assignment, the system will internally convert these MOID selectors to Serial selectors, and the MOIDs will no longer be accessible through APIs. For more information on the payload for creating Resource Pools, see API documentation.

Identity (ID) Pools

ID Pools are further classified into the following categories:

• IP pool: Provides the flexibility of dynamically assigning IP addresses to services running on a network element.

• MAC address pool: Provides unique IDs for network interface ports.

• UUID pool: Provides unique IDs for each server associated with the server profile.

• WWNN and WWPN pool: Provides unique IDs for Fibre Channel resources on a server (Fibre Channel nodes and ports).

• IQN pool: Provides a collection of iSCSI Qualified Names (IQNs) for use as initiator identifiers by iSCSI vNICs.

Pool Allocation

To ensure consistent and repeatable ID allocation across multiple allocation iterations, the smallest available ID is allocated sequentially during pool allocation iterations.

For example, consider a pool with a range of 1 to 20 IDs. The following table describes the ID allocation and reallocation iterations.

You can have overlapping pools, where some IDs are shared between different pools across organizations. Since IDs are unique across the account, whether they are used in different organizations or not, if an ID is consumed in one pool, it will also be marked as Used in all pools where it is used. The Pools Table View provides a summary of allocated IDs, providing the capability to track ID usage in Pools across Organizations. The Source column in the Pools Table View indicates the pool from which the ID is being allocated. If the ID is being allocated from the current pool, the Source column will be marked as Self. If the ID is allocated from another pool, the Source column will be marked as Other.

Deleting Pools

You can delete a pool or address block in an Organization where none of the IDs are allocated. It will not impact allocations in any pool in another Organization.

Follow these steps to delete a pool:

1. Check if the ID is not currently associated with a Server Profile:

   1. In the Pools Table View, review the Source column to analyze the pool usage.

   2. If Source is marked as Other, you can proceed to delete the ID as it is allocated from some other overlapping pool.

   3. Do not attempt to delete pools marked as Source = Self as it is not allowed since they are in use in one of the profiles.

2. Click Delete.

Identity Retention

IP Addresses, MAC addresses, IQNs, UUIDs, WWNNs, and WWPNs are the typical identifiers that a physical server gets from a Server Profile.

Intersight uses best efforts to retain the LAN Connectivity Policy (LCP) identifiers, such as MAC, IQN, and iSCSI IP, as well as the SAN Connectivity Policy (SCP) identifiers, such as WWPN and WWNN, when modifying policies, profiles or templates.

If you change the LCP or SCP to a new policy that accesses different Pools with non-overlapping IDs, then expect all the IDs to change. Furthermore, expect changes if the new Pool does not have the exact ID available.

In the following scenarios, you can expect ID retention during edits or changes:

• When adding a vNIC or vHBA to an LCP or SCP.

• When changing policy LCP1/SCP1 to LCP2/SCP2 that uses the same Pool Reference.

• When changing policy LCP1/SCP1 to LCP2/SCP2 that uses a different Pool Reference, but with the same IDs available.

• When changing policy LCP1/SCP1 that uses Static Identifiers to LCP2/SCP2 that uses a Pool Reference with the same IDs available.

• When detaching a Server Profile from Template T1 and attaching the Server Profile to Template T2 with the same IDs available.

• When editing a Server Profile Template and changing LCP1/SCP1 to LCP2/SCP2 as above.

• When editing an existing LCP/SCP Policy and changing the Identifier Reference from Static to a Pool with the same IDs available.

Identity Reservation

Identities can be reserved prior to allocation to allow selecting a specific value from a pool, for purposes such as migration across environments. For example, Cisco UCSM to IMM.

Reserved Identifiers Guidelines

• The identifiers can be reserved only via the IMM Transition Tool or by using available pool Reservation APIs, such as https://intersight.com/apidocs/apirefs/macpool/Reservations/model/.

• The reservation of the identifiers can be done only for Fabric Interconnect-attached servers.

• Reserved identifiers are meant for one-time use and are removed from the reservation pool once consumed.

The reserved ID gets consumed either when a policy (with the reserved identifier) is attached to a server profile, or when the server profile is deployed.

The Reserved Identifiers tab shows the list of reserved identifier values, their type, and the corresponding Pool membership. The Pool membership appears blank when the allocation type is Static. You can select and delete any reserved identifier.

Pool Configuration

For more information on configuring pools, see Configuring Pools.

Pool Details (By Type)

IP Pools

IP pools support both IPv4 and IPv6 addresses. However, Out-of-band IP addresses support only IPv4, while In-band IP addresses support both IPv4 and IPv6.

An IP Pool contains one or more IP blocks. By default, the system consumes IP addresses sequentially from these blocks, beginning with the lowest-ordered block.

You can also directly map specific IP blocks within an IP pool to Resource Groups or Organizations. To enable this, first create an ID Mapping policy at either the target or shared organization level. Then, associate this ID Mapping policy with one or more IP blocks within an IP pool. This configuration directs IP requests from the policy’s assigned organizations or resource groups to their designated IP blocks.

When you deploy a server or chassis profile to a resource group or organization linked to an ID Mapping policy, the system allocates an IP address exclusively from the mapped IP block. This ensures that deployments receive IP addresses from their intended subnets. For more information, see Creating an ID Mapping Policy under Supported UCS Server Policies.

Limitation:

IP Address Reassignment on Redeployment

When you redeploy a server profile to a different server under a new ID Mapping policy, the system currently retains the previously allocated IP address. It does not automatically reassign the IP address based on the new mapping.

Workaround- To force an IP address reassignment in this scenario, you must either:

• Modify the IP pool referenced in the policy.

• Delete the server profile and then recreate it from its template.

Subnet Configuration in an IP Pool

You can create IP pools with either common subnet configurations for all IP blocks (pool-level) or different subnet configurations for each IP block (block-level).

After defining a pool with subnet configuration at the block level, you can migrate it to pool-level subnet configuration and vice versa. When migrating from a pool-level to a block-level subnet configuration, the subnet configuration will be replicated across each existing IP block. When migrating from block-level to pool-level subnet configuration, you need to reconfigure the common subnet settings at the pool-level.

If an IP block already has existing leases, migration is allowed only in the following scenarios:

• Migrating from Pool-Level to Block-Level Configuration with Existing Leases:

  When you migrate from pool-level to block-level configuration with existing leases, the subnet configuration is moved to block-level without any changes. This means that the same subnet configuration previously set at the pool level is copied to each block. In such cases, the migration is allowed even if there are existing leases. After migration, if you observe that you cannot modify the subnet configuration of any block, it could be because it has existing active leases. Note that you cannot change the subnet configuration of any block if it already has active leases.

• Migrating from Block-Level to Pool-Level Configuration with Existing Leases:

  When you migrate from block-level to pool-level configuration with existing leases, you must specify the subnet configuration at the pool level. If all the previous block-level subnet configurations are the same as the new pool-level subnet configuration, the migration is allowed. In this scenario, the migration is permitted even if there are existing leases.

IP Pool Details View

MAC Pools

A MAC pool is a collection of network identities, or MAC addresses, that are unique in their Layer 2 environment and are available to be assigned to vNICs on a server. If you use MAC pools in server profiles, you do not have to manually configure the MAC addresses to be used by the server associated with the server profile.

To assign a MAC address to a server, you must include the MAC pool while adding a vNIC to a LAN Connectivity policy. The LAN Connectivity policy is then included in the server profile assigned to that server.

MAC Pool Details

UUID Pools

A Universally Unique Identifier (UUID) pool is a collection of UUIDs that are assigned to servers. The prefix and suffix of the UUID are variable values. A UUID pool ensures that these variable values are unique for each server associated with a server profile that uses a particular pool to avoid conflicts.

Supported Servers and Minimum Firmware Versions

The supported servers and its minimum firmware or Cisco IMC versions required for UUID pool are mentioned below:

For more information on the server profile association using UUID Pool and UUID Static, see Configuring Server Profiles.

UUID Pool Details View

WWN Pools

A World Wide Name (WWN) pool is a collection of WWNs for use by the Fibre Channel vHBAs in a Cisco UCS Domain. You create separate pools for the following:

• WW node names assigned to the server

• WW port names assigned to the server

If you use WWN pools in server profiles, you do not have to manually configure the WWNs that will be used by the server associated with the server profile. In a system that implements multi-tenancy, you can use a WWN pool to control the WWNs used by each organization. You assign WWNs to pools in blocks.

WWNN Pools: A WWNN pool is a WWN pool that contains only WW node names. If you include a pool of WWNNs in a server profile, the associated server is assigned a WWNN from that pool.

WWPN Pools: A WWPN pool is a WWN pool that contains only WW port names. If you include a pool of WWPNs in a server profile, the port on each vHBA of the associated server is assigned a WWPN from that pool.

WWxN Pool Details View

To ensure the uniqueness of the Cisco UCS WWxNs in the SAN fabric, Cisco recommends using the following:

WWN prefix 20:00:00:25:b5:00:00:01

IQN Pools

An IQN pool is a collection of iSCSI Qualified Names (IQNs) for use as initiator identifiers by iSCSI vNICs. IQN pool members are of the form prefix: suffix: number, where you can specify the prefix, suffix, and a block (range) of numbers.

An IQN pool can contain more than one IQN block, with different number ranges and different suffixes, but sharing the same prefix.

IQN Pool Details View

Resource Pools

A resource pool represents a collection of resources that can be associated to the configuration entities such as server profiles. For more information on the server profile association using resource pool, see Configuring Server Profiles.

Resource Pool Details View

Virtual Routing and Forwarding

Virtual Routing and Forwarding (VRF) is an IP technology that allows multiple instances of a routing table to coexist on the same router at the same time. Because the routing instances are independent, the same or overlapping IP addresses can be used without conflict. A VRF creates a namespace for IP address management. IP pools are VRF-aware in Cisco Intersight.

VRF Guidelines

The following guidelines and limitations apply for VRF instances:

• Intersight creates a default VRF for an account, and manages IP address allocation within the context of this default VRF.

• Within a single VRF instance, IP addresses must be unique. Between different VRF instances, you can have overlapping IP addresses.

• If IP Pools are shared between VRF instances, ensure that there are no overlapping IP addresses.

For more information on creating VRF instances, see Configuring Pools.