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.
Creating a Boot Policy
You can also create a local boot policy that is restricted to a
service profile
or service profile template.
However, except for iSCSI boot, 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 Action
Purpose
Step 1
UCS-A#
scope orgorg-name
Enters organization mode for the specified organization. To enter
the root organization mode, type
/ as the
org-name.
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 3
UCS-A /org/boot-policy #
set descrdescription
(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 4
UCS-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 5
UCS-A /org/boot-policy #
set enforce-vnic-name{no |
yes}
If you choose yes, Cisco UCS Manager uses any vNICs or vHBAs defined in the Boot Order.
If you choose no, Cisco UCS Manager uses the priority specified in the vNIC or vHBA.
Step 6
UCS-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 SAN 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 might 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.
SAN Boot
You can configure a boot policy to boot one or more servers from an operating system image on the SAN. The boot policy can include 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.
To use a SAN boot, ensure that the following is configured:
The Cisco UCS domain must be able to communicate with the SAN storage device that hosts the operating system image.
A boot target LUN on the device where the operating system image is located.
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 might 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.
Create a boot policy to contain the SAN boot configuration.
Note
If you are creating a boot policy that boots the server from a SAN LUN and you require reliable SAN boot operations, we recommend that you first remove all local disks from servers associated with a service profile that includes the boot policy.
Procedure
Command or Action
Purpose
Step 1
UCS-A# scope orgorg-name
Enters organization mode for the specified organization. To enter the root organization mode, type / as the org-name.
Step 2
UCS-A /org # scope boot-policypolicy-name
Enters organization boot policy mode for the specified boot policy.
Step 3
UCS-A /org/boot-policy #create storage
Creates a SAN boot for the boot policy and enters organization boot policy storage mode.
Creates a SAN image 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 6
UCS-A /org/boot-policy/storage/san-image # set vhbavhba-name
Creates a primary or secondary SAN 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 8
UCS-A /org/boot-policy/storage/san-image/path # set {lunlun-id | wwnwwn-num}
Specifies the LUN or WWN to be used for the SAN path to the boot image.
Commits the transaction to the system configuration.
The following example enters the boot policy named lab1-boot-policy, creates a SAN 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:
The Cisco UCS Manager iSCSI vNIC and iSCSI boot
information created for the service profile is used in the
association process to program the mezzanine adapter, located on
the blade server. After the adapter is programmed, the blade server
reboots with the latest service profile values. After the power on
self-test (POST), the adapter attempts to initialize using these
service profile values. If the adapter can use the values and log
in to its specified target, the adapter initializes and posts an
iSCSI Boot Firmware Table (iBFT) to the host memory and a valid
bootable LUN to the system BIOS. The iBFT that is posted to the
host memory contains the initiator and target configuration that is
programmed on the primary iSCSI VNIC.
Note
The iBFT only uses the first iSCSI vNIC
and only Target 1 for the initiator-to-target initialization. This
scenario is true even if a second target (Target 2) exists for the
first iSCSI vNIC.
The next step, which is the installation of the
operating system (OS), requires an OS that is iBFT capable. During
installation of the OS, the OS installer scans the host memory for
the iBFT table and uses the information in the iBFT to discover the
boot device and create an iSCSI path to the target LUN. In some
OS's a NIC driver is required to complete this path. If this step
is successful, the OS installer finds the iSCSI target LUN on which
to install the OS.
Note
The iBFT works at the OS installation software level and
might not work with HBA mode (also known as TCP offload).
Whether iBFT works with HBA mode depends on the OS capabilities
during installation.
Also, for a server that includes a Cisco UCS M51KR-B Broadcom BCM57711 adapter, the iBFT normally works at a maximum transmission unit (MTU)
size of 1500, regardless of the MTU jumbo configuration. If the OS supports HBA mode, you might need
to set HBA mode, dual-fabric support,
and jumbo MTU size after the iSCSI installation process.
iSCSI Boot Guidelines and Prerequisites
These guidelines and prerequisites must be met before configuring iSCSI boot:
To set up iSCSI boot from a Windows 2008 server where the second vNIC (failover vNIC) must boot from an iSCSI LUN, consult Microsoft Knowledge Base Article 976042. Microsoft has a known issue where Windows might fail to boot from an iSCSI drive or cause a bugcheck error if the networking hardware is changed. To work around this issue, follow the resolution recommended by Microsoft.
The storage array must be licensed for iSCSI boot and the array side LUN masking must be properly configured.
Two
IP addresses must be determined, one for each iSCSI initiator. If
possible, the IP addresses should be on the same subnet as the
storage array. The IP
addresses are assigned statically or dynamically
using the Dynamic Host Configuration Protocol (DHCP).
You cannot configure boot parameters in the Global boot policy. Instead, after configuring boot parameters, you need to include the boot policy in the appropriate service profile.
The operating system (OS) must be iSCSI Boot Firmware Table (iBFT) compatible.
For Cisco UCS M51KR-B Broadcom BCM57711 network adapters:
Blades that use iSCSI boot must contain the Cisco UCS M51KR-B Broadcom BCM57711
network adapter. For information on installing or replacing an adapter card, see the Cisco UCS
B250 Extended Memory Blade Server Installation and Service
Note. The service note is accessible from the Cisco UCS B-Series Servers Documentation Roadmap at http://www.cisco.com/go/unifiedcomputing/b-series-doc.
Set the MAC addresses on the iSCSI device.
If you are using the DHCP Vendor ID (Option 43), the MAC address of an iSCSI device needs to be configured in /etc/dhcpd.conf.
HBA mode (also known as TCP offload) and the boot to target setting are supported. However, only Windows OS supports HBA mode during installation.
Before installing the OS, disable the boot to target setting in the iSCSI adapter policy, then after installing the OS, reenable the boot to target setting.
Note
Each time you change an adapter policy setting, the adapter reboots to apply the new setting.
When installing the OS on the iSCSI target, the iSCSI target must be ordered before the device where the OS image resides. For example, if you are installing the OS on the iSCSI target from a CD, the boot order should be the iSCSI target and then the CD.
After the server has been iSCSI booted, do not modify the Initiator Name, Target name, LUN, iSCSI device IP, or Netmask/gateway using the Broadcom tool.
Do not interrupt the POST (power on self-test) process or the Cisco UCS M51KR-B Broadcom BCM57711 network adapter will fail to initialize.
For Cisco UCS M81KR Virtual Interface Card and Cisco UCS VIC-1240 Virtual Interface Card:
Do not set MAC addresses on the iSCSI device.
HBA mode and the boot to target setting are not supported.
When installing the OS on the iSCSI target, the iSCSI target must be ordered after the device where the OS image resides. For example, if you are installing the OS on the iSCSI target from a CD, the boot order should be the CD and then the iSCSI target.
If you are using the DHCP Vendor ID (Option 43), the MAC address of the overlay vNIC needs to be configured in /etc/dhcpd.conf.
After the server has been iSCSI booted, do not modify the IP details of the overlay vNIC.
The VMware ESX/ESXi operating system does not support storing a core dump file to an iSCSI boot target LUN. Dump files must be written to a local disk.
Enabling MPIO on Windows
Note
If you change the networking hardware, Windows may fail to boot from an iSCSI drive. For more information, see Microsoft support Article ID: 976042.
Before You Begin
The server on which you enable MPIO must have a Cisco VIC driver.
Procedure
Step 1
In the service profile associated with the server, configure the primary and secondary iSCSI vNICs.
If you plan to configure the iSCSI initiator to use an IP address from a pool of IP addresses, add a block of IP addresses to the iSCSI initiator pool.
Create a boot policy that can be used in any service profile. Alternatively, you can create a local boot policy only for the specific service policy. However, we recommend that you create a boot policy that can be shared with multiple service profiles.
For more information about creating a boot policy that can be used in any service profile, see Creating an iSCSI Boot Policy.
Step 5
If you created a boot policy that can be used in any service profile, you need to assign it to the service profile. Otherwise, proceed to the next step.
Cisco UCS B-Series Blade Servers Linux Installation Guide
Cisco UCS B-Series Blade Servers Windows Installation Guide
Step 13
Boot the server.
Creating an iSCSI Adapter Policy
Procedure
Command or Action
Purpose
Step 1
UCS-A#
scope orgorg-name
Enters organization mode for the specified organization. To enter
the root organization mode, type
/ as the
org-name.
Step 2
UCS-A /org #
create iscsi-policypolicy-name
Creates the iSCSI adapter policy.
Step 3
UCS-A /org/iscsi-policy #
set descrdescription
(Optional)
Provides a description for the iSCSI adapter policy.
Step 4
UCS-A /org/iscsi-policy #
set iscsi-protocol-item connection-timeouttimeout-secs
The number of seconds to wait until Cisco UCS assumes that the initial login has failed and the iSCSI adapter is unavailable.
Enter an integer between 0 and 255. If you enter 0, Cisco UCS uses the value set in the adapter firmware (default: 15 seconds).
Step 5
UCS-A /org/iscsi-policy #
set iscsi-protocol-item dhcp-timeouttimeout-secs
The number of seconds to wait before the initiator assumes that the DHCP server is unavailable.
Enter an integer between 60 and 300 (default: 60 seconds).
Step 6
UCS-A /org/iscsi-policy #
set iscsi-protocol-item lun-busy-retry-countnum
The number of times to retry the connection in case of a failure during iSCSI LUN discovery.
Enter an integer between 0 and 60. If you enter 0, Cisco UCS uses the value set in the adapter firmware (default: 15 seconds).
Step 7
UCS-A /org/iscsi-policy #
set iscsi-protocol-item tcp-time-stamp{no | yes}
Specifies whether to apply a TCP timestamp. With this setting, transmitted packets are given a time stamp of when the packet was sent so that the packet's round-trip time can be calculated, when needed. This setting applies only to Cisco UCS M51KR-B Broadcom BCM57711 adapters.
Step 8
UCS-A /org/iscsi-policy #
set iscsi-protocol-item hbamode{no | yes}
Specifies whether to enable HBA mode.
This option should only be enabled for servers with the Cisco UCS NIC M51KR-B adapter running the Windows operating system.
Step 9
UCS-A /org/iscsi-policy #
set iscsi-protocol-item boottotarget{no | yes}
Specifies whether to boot from the iSCSI target.
This option only applies to servers with the Cisco UCS NIC M51KR-B adapter. It should be disabled until you have installed an operating system on the server.
Step 10
UCS-A /org/iscsi-policy #
commit-buffer
Commits the transaction to the system configuration.
The following example shows how to create an iSCSI adapter policy called iscsiboot, set the connection timeout, DHCP timeout, and LUN busy retry count, apply a TCP timestamp, and commit the transaction:
UCS-A# scope org /
UCS-A /org # create iscsi-policy iscsiboot
UCS-A /org/iscsi-policy* # set iscsi-protocol-item connection-timeout 60
UCS-A /org/iscsi-policy* # set iscsi-protocol-item dhcp-timeout 200
UCS-A /org/iscsi-policy* # set iscsi-protocol-item lun-busy-retry-count 5
UCS-A /org/iscsi-policy* # set iscsi-protocol-item tcp-time-stamp yes
UCS-A /org/iscsi-policy* # set iscsi-protocol-item hbamode yes
UCS-A /org/iscsi-policy* # set iscsi-protocol-item boottotarget yes
UCS-A /org/iscsi-policy* # commit-buffer
UCS-A /org/iscsi-policy #
What to Do Next
Include the adapter policy in a service profile and/or template.
Deleting an iSCSI Adapter Policy
Procedure
Command or Action
Purpose
Step 1
UCS-A# scope orgorg-name
Enters organization mode for the specified organization. To enter the root organization mode, type / as the org-name.
Step 2
UCS-A /org # delete iscsi-policypolicy-name
Deletes the iSCSI adapter policy.
Step 3
UCS-A /org # commit-buffer
Commits the transaction to the system configuration.
The following example shows how to delete an iSCSI adapter policy named iscsi-adapter-pol and commit the transaction:
Adding a Block of IP Addresses to the Initiator Pool
You can create a group of IP addresses to be used for iSCSI boot. Cisco UCS Manager
reserves the block of IP addresses you specify.
The IP pool must not contain any IP addresses that have been assigned as static IP addresses for a server or service profile.
Procedure
Command or Action
Purpose
Step 1
UCS-A#
scope orgorg-name
Enters organization mode for the specified organization. To enter
the root organization mode, enter
/ as the
org-name.
Step 2
UCS-A /org# scope ip-pool iscsi-initiator-pool
Enters the mode to specify an iSCSI initiator pool.
Step 3
UCS-A /org/ip-pool #
set descrdescription
(Optional)
Provides a description for the IP pool.
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 4
UCS-A /org/ip-pool # set assignmentorder {default | sequential}
This can be one of the following:
default—Cisco UCS Manager selects a random identity from the pool.
sequential—Cisco UCS Manager selects the lowest available identity from the pool.
You can add up to two iSCSI vNICs per boot policy. One vNIC acts as the primary iSCSI boot source, and the other acts as the secondary iSCSI boot source.
Procedure
Command or Action
Purpose
Step 1
UCS-A#
scope orgorg-name
Enters organization mode for the specified organization. To enter
the root organization mode, type
/ as the
org-name.
Creates a boot policy with the specified policy name, and enters
organization boot policy mode.
This name can be between 1 and 16
alphanumeric characters. You cannot use spaces or any special characters other than - (hyphen), _ (underscore), : (colon), and . (period), and
you cannot change this name after the object has been saved.
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 3
UCS-A /org/boot-policy #
set descrdescription
(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 4
UCS-A /org/boot-policy #
set enforce-vnic-name{no |
yes}
(Optional)
If you choose yes, Cisco UCS Manager reports whether the device name specified in the boot policy matches what is specified in the service profile.
If you choose no, Cisco UCS Manager uses any vNIC, vHBA, or iSCSI device from the service profile and does not report whether the device name specified in the boot policy matches what is specified in the service profile.
Step 5
UCS-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.
In the Cisco UCS Manager GUI, if the Reboot on
Boot Order Change
check box is checked for a boot policy, and
if CD-ROM or Floppy is the last device in the boot order, deleting or adding the device does not directly affect the boot
order and the server does not reboot.
Specifies the primary and secondary paths that Cisco UCS Manager uses to reach the iSCSI target .With iSCSI boot, you set up two paths. Cisco UCS Manager uses the primary path first, and if that fails, then it uses the secondary path.
UCS-A /org/boot-policy/iscsi/path #
set orderorder-num
Specifies the order for the iSCSI boot in the boot order.
Step 11
Repeat steps 8-10 to create secondary iSCSI vNICs.
(Optional)
Step 12
UCS-A /org/boot-policy/iscsi #
commit-buffer
Commits the transaction to the system configuration.
The following example shows how to create an iSCSI boot policy named iscsi-boot-policy-LAN,
provide a description for the boot policy, specify that servers using this
policy are not automatically rebooted when the boot order is changed, set the boot order for iSCSI boot to 2, create an iSCSI boot and associate it with a vNIC called iscsienic1, and
commit the transaction:
UCS-A# scope org /
UCS-A /org* # create boot-policy iscsi-boot-policy-LAN purpose operational
UCS-A /org/boot-policy* # set descr "Boot policy that boots from iSCSI."
UCS-A /org/boot-policy* # set enforce-vnic-name yes
UCS-A /org/boot-policy* # set reboot-on-update no
UCS-A /org/boot-policy* # create iscsi
UCS-A /org/boot-policy/iscsi* # create path primary
UCS-A /org/boot-policy/iscsi/path* # set iscsivnicname iscsienic1
UCS-A /org/boot-policy/iscsi/path* # exit
UCS-A /org/boot-policy/iscsi* # set order 2
UCS-A /org/boot-policy/iscsi* # commit-buffer
UCS-A /org/boot-policy #
What to Do Next
Include the boot policy in a
service profile
and/or template.
After a server is associated with a service profile that includes this boot policy, you can verify the actual boot order in the Boot Order Details area on the General tab for the server.
Deleting iSCSI Devices from a Boot Policy
Procedure
Command or Action
Purpose
Step 1
UCS-A# scope orgorg-name
Enters organization mode for the specified organization. To enter the root organization mode, type / as the org-name.
Step 2
UCS-A /org # scope boot-policyboot-pol-name
Enters boot policy organization mode for the specified boot policy.
Step 3
UCS-A /org/boot-policy # delete iscsi
Deletes the iSCSI boot from the boot policy.
Step 4
UCS-A /org/boot-policy # commit-buffer
Commits the transaction to the system configuration.
The following example shows how to delete an iSCSI boot from the boot policy named boot-policy-iscsi and commit the transaction:
UCS-A /org/service-profile/vnic-iscsi* # set iscsi-adaptor-policyiscsi-adaptor-name
(Optional)
Specifies the iSCSI adapter policy that you have created for this iSCSI vNIC.
Step 5
UCS-A /org/service-profile/vnic-iscsi* # set auth-nameauthentication-profile-name
(Optional)
Sets the authentication profile to be used by the iSCSI vNIC. The authentication profile must already exist for it to be set. For more information, see Creating an Authentication Profile.
The MAC address is only set for Cisco UCS NIC M51KR-B adapters.
Step 7
UCS-A /org/service-profile/vnic-iscsi* # set iscsi-identity {initiator-nameinitiator-name | initiator-pool-nameiqn-pool-name}
Specifies the name of the iSCSI initiator or the name of an IQN pool from which the iSCSI initiator name will be provided. The iSCSI initiator name can be up to 223 characters.
Step 8
UCS-A /org/service-profile/vnic-iscsi* # set overlay-vnic-nameoverlay-vnic-name
Creates an Ethernet interface for a VLAN assigned to the iSCSI vNIC.
Step 10
UCS-A /org/service-profile/vnic-iscsi/eth-if* # set vlannamevlan-name.
Specifies the VLAN name. The default VLAN is default. For the Cisco UCS M81KR Virtual Interface Card and the Cisco UCS VIC-1240 Virtual Interface Card, the VLAN that you specify must be the same as the native VLAN on the overlay vNIC. For the Cisco UCS M51KR-B Broadcom BCM57711 adapter, the VLAN that you specify can be any VLAN assigned to the overlay vNIC.
Commits the transaction to the system configuration.
The following example shows how to create an iSCSI vNIC called scsivnic1, add it to an existing service profile called accounting, and commit the transaction:
An IQN pool is a collection of iSCSI Qualified Names (IQNs) for use as initiator identifiers by iSCSI vNICs in
a
Cisco UCS domain.
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.
Creating an IQN Pool
Note
In most cases, the maximum IQN size (prefix + suffix + additional characters) is 223 characters. When using the Cisco UCS NIC M51KR-B adapter, you must limit the IQN size to 128 characters.
Procedure
Command or Action
Purpose
Step 1
UCS-A#
scope orgorg-name
Enters organization mode for the specified organization. To enter
the root organization mode, enter
/ as the
org-name.
Step 2
UCS-A /org #
create iqn-poolpool-name
Creates an IQN pool with the specified pool name and enters
organization IQN pool mode.
This name can be between 1 and 32
alphanumeric characters. You cannot use spaces or any special characters other than - (hyphen), _ (underscore), : (colon), and . (period), and
you cannot change this name after the object has been saved.
Step 3
UCS-A /org/iqn-pool # set iqn-prefixprefix
Specifies the prefix for the IQN block members. Unless limited by the adapter card, the prefix can contain up to 150 characters.
Step 4
UCS-A /org/iqn-pool # set descrdescription
(Optional)
Provides a description for the IQN pool.
Enter up to 256 characters.
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 5
UCS-A /org/iqn-pool # set assignmentorder {default | sequential}
This can be one of the following:
default—Cisco UCS Manager selects a random identity from the pool.
sequential—Cisco UCS Manager selects the lowest available identity from the pool.
Step 6
UCS-A /org/iqn-pool #
create blocksuffixfromto
Creates a block (range) of IQNs, and enters organization
IQN pool block mode. You must specify the base suffix, the starting suffix number, and the ending suffix number. The resulting IQN pool members are of the form
prefix:suffix:number.
The suffix can be up to 64 characters.
Note
An IQN pool can contain more than one IQN block.
To create multiple blocks, enter multiple
create block commands from organization IQN pool mode.
Step 7
UCS-A /org/iqn-pool/block #
commit-buffer
Commits the transaction to the system configuration.
The following example shows how to create an IQN pool named pool4, provide
a description for the pool, specify a prefix and a block of suffixes to be used
for the pool, and commit the transaction:
Include the IQN suffix pool in a
service profile
and/or template.
Adding a Block to an IQN Pool
Procedure
Command or Action
Purpose
Step 1
UCS-A#
scope orgorg-name
Enters organization mode for the specified organization. To enter
the root organization mode, type
/ as the
org-name.
Step 2
UCS-A /org #
scope iqn-poolpool-name
Enters
organization IQN pool mode for the specified pool.
Step 3
UCS-A /org/iqn-pool #
create blocksuffixfromto
Creates a block (range) of IQN suffixes, and enters organization
IQN pool block mode. You must specify the base suffix, the starting suffix number, and the ending suffix number. The resulting IQN pool members are of the form
prefix:suffix:number.
Note
An IQN pool can contain more than one IQN block.
To create multiple blocks, enter multiple
create block commands from organization IQN pool mode.
Step 4
UCS-A /org/iqn-pool/block #
commit-buffer
Commits the transaction to the system configuration.
Step 5
UCS-A /org/iqn-pool/block #
exit
(Optional)
Returns to organization IQN pool mode.
Step 6
UCS-A /org/iqn-pool #
show block
(Optional)
Displays the blocks of suffixes.
This example shows how to add a block of IQN suffixes to an IQN pool named pool4 and commit the transaction:
If you delete an address block from a pool, Cisco UCS Manager does not reallocate any addresses in that block that have been assigned to vNICs or vHBAs. All assigned addresses from a deleted block remain with the vNIC or vHBA to which they are assigned until one of the following occurs:
The associated service profiles are deleted.
The vNIC or vHBA to which the address is assigned is deleted.
The vNIC or vHBA is assigned to a different pool.
Procedure
Command or Action
Purpose
Step 1
UCS-A#
scope orgorg-name
Enters organization mode for the specified organization. To enter
the root organization mode, type
/ as the
org-name.
Step 2
UCS-A /org #
scope iqn-poolpool-name
Enters
organization IQN pool mode for the specified pool.
Step 3
UCS-A /org/iqn-pool #
delete blocksuffix from to
Deletes a block (range) of IQNs. You must specify the base suffix and the first and last numbers
in the block to be deleted.
Step 4
UCS-A /org/iqn-pool #
commit-buffer
Commits the transaction to the system configuration.
This example shows how to delete a block of suffixes from an IQN pool named pool4 and commit the transaction:
If you delete a pool, Cisco UCS Manager does not reallocate any addresses from that pool that have been assigned to vNICs or vHBAs. All assigned addresses from a deleted pool remain with the vNIC or vHBA to which they are assigned until one of the following occurs:
The associated service profiles are deleted.
The vNIC or vHBA to which the address is assigned is deleted.
The vNIC or vHBA is assigned to a different pool.
Procedure
Command or Action
Purpose
Step 1
UCS-A#
scope orgorg-name
Enters organization mode for the specified organization. To enter
the root organization mode, enter
/ as the
org-name.
Step 2
UCS-A /org # delete iqn-poolpool-name
Deletes the specified IQN pool.
Step 3
UCS-A /org # commit-buffer
Commits the transaction to the system configuration.
The following example shows how to delete the IQN pool named pool4 and commit the transaction:
Enters organization mode for the specified organization. To enter
the root organization mode, enter
/ as the
org-name.
Step 2
UCS-A /org #
scope iqn-poolpool-name
Enters
organization IQN pool mode for the specified pool.
Step 3
UCS-A /org/iqn-pool # show pooled
Displays the assignments of the IQN block members.
The following example shows how to display the assignments of suffixes in the IQN pool named pool4:
UCS-A# scope org /
UCS-A /org # scope iqn-pool pool4
UCS-A /org/iqn-pool # show pooled
Pooled:
Name Assigned Assigned To Dn
---------- -------- --------------
beta:3 No
beta:4 No
beta:5 No
UCS-A /org/iqn-pool #
Creating an iSCSI Static Target
You can create a static target.
Before You Begin
You have already created an iSCSI vNIC.
Procedure
Command or Action
Purpose
Step 1
UCS-A# scope orgorg-name
Enters organization mode for the specified organization. To enter the root organization mode, type / as the org-name.
Step 2
UCS-A /org # scope service-profileprofile-name
Enters service profile organization mode for the service profile to which you want to add an iSCSI target.
Commits the transaction to the system configuration.
Step 15
Repeat steps 5 through 14 to create a second static target.
(Optional)
The following example shows how to create two iSCSI static target interfaces and commit the transaction:
UCS-A # scope org test
UCS-A /org # scope service-profile accounting
UCS-A /org/service-profile # scope vnic-iscsi iSCSI1
UCS-A /org/service-profile/vnic-iscsi # scope eth-if
UCS-A /org/service-profile/vnic-iscsi/eth-if # create static-target-if 1
UCS-A /org/service-profile/vnic-iscsi/eth-if/static-target-if* # set name statictarget1
UCS-A /org/service-profile/vnic-iscsi/eth-if/static-target-if* # set port 3260
UCS-A /org/service-profile/vnic-iscsi/eth-if/static-target-if* # set auth-name authprofile1
UCS-A /org/service-profile/vnic-iscsi/eth-if/static-target-if* # set ip-address 192.168.10.10
UCS-A /org/service-profile/vnic-iscsi/eth-if/static-target-if* # create lun
UCS-A /org/service-profile/vnic-iscsi/eth-if/static-target-if/lun* # set id 1
UCS-A /org/service-profile/vnic-iscsi/eth-if/static-target-if/lun* # exit
UCS-A /org/service-profile/vnic-iscsi/eth-if/static-target-if* # exit
UCS-A /org/service-profile/vnic-iscsi/eth-if* # commit-buffer
UCS-A /org/service-profile/vnic-iscsi/eth-if # create static-target-if 2
UCS-A /org/service-profile/vnic-iscsi/eth-if/static-target-if* # set ipaddress 192.168.10.11
UCS-A /org/service-profile/vnic-iscsi/eth-if/static-target-if* # set name statictarget2
UCS-A /org/service-profile/vnic-iscsi/eth-if/static-target-if* # set port 3260
UCS-A /org/service-profile/vnic-iscsi/eth-if/static-target-if* # set auth-name authprofile1
UCS-A /org/service-profile/vnic-iscsi/eth-if/static-target-if* # create lun
UCS-A /org/service-profile/vnic-iscsi/eth-if/static-target-if/lun* # set id 1
UCS-A /org/service-profile/vnic-iscsi/eth-if/static-target-if/lun* # exit
UCS-A /org/service-profile/vnic-iscsi/eth-if/static-target-if* # exit
UCS-A /org/service-profile/vnic-iscsi/eth-if* # commit-buffer
What to Do Next
To configure a second iSCSI device, repeat the steps for creating an iSCSI vNIC, initiator, and target.
Deleting an iSCSI Static Target
You can delete an iSCSI static target. However, you must have at least one iSCSI static target remaining after you delete one. Therefore, you must have two iSCSI static targets in order to delete one of them.
Note
If you have two iSCSI targets and you delete the first priority target, the second priority target becomes the first priority target, although the Cisco UCS Manager still shows it as the second priority target.
Procedure
Command or Action
Purpose
Step 1
UCS-A# scope orgorg-name
Enters organization mode for the specified organization. To enter the root organization mode, type / as the org-name.
Step 2
UCS-A /org # scope service-profileprofile-name
Enters service profile organization mode for the service profile to which you want to add an iSCSI target.
Use the KVM console to view the boot up messages as the adapter is booting. For information on how to access the KVM console, see the Starting the KVM Console chapter.
This step can only be performed using the Cisco UCS Manager GUI. For more information, see the Starting the KVM Console chapter in the UCS Manager GUI Configuration Guide.
For the Cisco UCS M51KR-B Broadcom BCM57711, the following message appears:
Logging in the 1st iSCSI Target…. Succeeded.
For the Cisco UCS M81KR Virtual Interface Card, the following message appears:
Option ROM installed successfully.
LAN Boot
You can configure a boot policy to boot one or more servers from a centralized provisioning server on the LAN. A LAN (or PXE) boot is
frequently used to install operating systems on a server from that LAN server.
You can add more than one type of boot device to a LAN boot policy. For example, you could add a local disk or virtual media boot as a secondary boot device.
Specifies the vNIC to use for the LAN path to the boot image.
Step 7
UCS-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:
Include the boot policy in a
service profile
and/or template.
Local Disk Boot
If a server has a local drive, you can configure a boot policy to boot the server 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.
You can also create a local boot policy that is restricted to a
service profile
or service profile template.
However, except for iSCSI boot, we recommend that you create a global boot policy that can be included in multiple service profiles or service profile templates.
You can add more than one type of boot device to a boot policy. For example, you could add a virtual media boot as a secondary boot device.
Procedure
Command or Action
Purpose
Step 1
UCS-A# scope orgorg-name
Enters organization mode for the specified organization. To enter the root organization mode, type / as the org-name.
Step 2
UCS-A /org # scope boot-policypolicy-name
Enters organization boot policy mode for the specified boot policy.
Step 3
UCS-A /org/boot-policy #create storage
Creates a storage boot for the boot policy and enters organization boot policy storage mode.
Step 4
UCS-A /org/boot-policy/storage # createlocal
Creates a local storage location.
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 5
UCS-A /org/boot-policy/storage # commit-buffer
Commits the transaction to the system configuration.
The following example enters the boot policy named lab1-boot-policy, creates a local boot for the policy, and commits the transaction:
Include the boot policy in a
service profile
and/or template.
Virtual Media Boot
You can configure a boot policy to boot one or more servers from a virtual media device that is accessible from the server. A virtual media device mimics the insertion of a physical CD-ROM disk (read-only)
or floppy disk (read-write) into a server. This type of server boot is typically used to manually
install operating systems on a server.
Configuring a Virtual Media Boot for a Boot Policy
Note
Virtual Media requires the USB to be enabled. If you modify the BIOS settings that affect the USB functionality, you also affect the Virtual Media. Therefore, we recommend that you leave the following USB BIOS defaults for best performance:
Make Device Non Bootable—set to disabled
USB Idle Power Optimizing Setting—set to high-performance
Before You Begin
Create a boot policy to contain the virtual media boot configuration.
Procedure
Command or Action
Purpose
Step 1
UCS-A# scope orgorg-name
Enters organization mode for the specified organization. To enter the root organization mode, type / as the org-name.
Step 2
UCS-A /org # scope boot-policypolicy-name
Enters organization boot policy mode for the specified boot policy.
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.
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: