この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
目次
この章は、次の項で構成されています。
Cisco UCS Manager ブート ポリシーは、BIOS 設定メニューのブート順序をオーバーライドし、次のことを決定します。
たとえば、ローカル ディスクや CD-ROM(VMedia)などのローカル デバイスから関連するサーバを選択するか、または SAN ブートもしくは LAN(PXE)ブートを選択することができます。
1 つ以上のサービス プロファイルに関連付けることができる名前付きブート ポリシーを作成するか、特定のサービス プロファイルに対するブート ポリシーを作成できます。 ブート ポリシーを有効にするには、ブート ポリシーをサービス プロファイルに含め、このサービス プロファイルをサーバに関連付ける必要があります。 サービス プロファイルにブート ポリシーを含めない場合、Cisco UCS Manager によってデフォルトのブート ポリシーが適用されます。
(注) |
ブート ポリシーに対する変更は、そのブート ポリシーを含んでいる、更新中のサービス プロファイル テンプレートを使って作成されたすべてのサーバに伝播されます。 BIOS にブート順序情報を再書き込みするためのサービス プロファイルとサーバとの再アソシエーションは自動的にトリガーされます。 |
Unified Extensible Firmware Interface(UEFI)は、オペレーティング システムとプラットフォーム ファームウェア間のソフトウェア インターフェイスを定義する仕様です。 Cisco UCS Manager は、UEFI を使用して BIOS ファームウェア インターフェイスを置き換えします。 これにより、BIOS は従来のサポートを提供しながら、UEFI モードで動作できるようになります。
ブート ポリシーを作成する際は、レガシー ブート モードまたは UEFI ブート モードのいずれかを選択できます。 レガシー ブート モードは、すべての Cisco UCS サーバでサポートされます。 UEFI ブート モードは M3 および M4 サーバでのみサポートされ、ユーザは UEFI セキュア ブート モードを有効にすることができます。
UEFI ブート モードには以下の制限が適用されます。
UEFI ブート モードは、Cisco UCS B シリーズ M3 および M4 ブレードサーバと、Cisco UCS C シリーズ M3 および M4 ラック サーバでのみサポートされます。
UEFI ブート モードは、次の組み合わせではサポートされません。
同じサーバで UEFI ブート モードとレガシー ブート モードを混在させることはできません。
ブート ポリシーに設定されているブート デバイスに UEFI 対応オペレーティング システムがインストールされている場合にのみ、サーバは UEFI モードで正常に起動します。 互換性のある OS が存在しない場合、ブート デバイスは [Boot Order Details] 領域の [Actual Boot Order] タブに表示されません。
ごくまれですが、UEFI ブート マネージャ エントリが BIOS NVRAM に正しく保存されなかったため、UEFI ブートが成功しない場合があります。 UEFI シェルを使用すると、UEFI ブート マネージャ エントリを手動で入力することができます。 この状況は、以下の場合に発生する可能性があります。
Cisco UCS Manager は、Cisco UCS B シリーズ M3 および M4 ブレード サーバで UEFI セキュア ブートをサポートします。 UEFI セキュア ブートを有効にすると、すべての実行可能ファイル(ブート ローダ、アダプタ ドライバなど)はロードされる前に BIOS によって認証されます。 認証されるには、そのイメージに Cisco 認証局(CA)または Microsoft CA による署名が必要です。
UEFI セキュア ブートには次の制限が適用されます。UEFI ブート モードは、ブート ポリシーで有効にする必要があります。
Cisco UCS Manager ソフトウェアと BIOS ファームウェアは、リリース 2.2 以降である必要があります。
ユーザにより生成された暗号キーはサポートされません。
UEFI セキュア ブートは、Cisco UCS Manager でのみ制御できます。
サービス プロファイルまたはサービス プロファイル テンプレートに制限されたローカル ブート ポリシーを作成することもできます。 しかし、複数のサービス プロファイルまたはサービス プロファイル テンプレートに含むことのできるグローバルなブート ポリシーの作成を推奨します。
SAN LUN からサーバをブートするブート ポリシーを作成し、安定した SAN ブート操作が必要な場合は、ブート ポリシーを含むサービス プロファイルに関連付けられたサーバからすべてのローカル ディスクを最初に削除する必要があります。
(注) |
これは、Cisco UCS M3 および M4 サーバには適用されません。 |
以下の例では、boot-policy-LAN という名前のブート ポリシーを作成し、このポリシーを使用するサーバがブート順序が変更されたときに自動的にリブートされないよう指定し、UEFI ブート モードを設定し、UEFI ブート セキュリティをイネーブルにし、トランザクションをコミットする方法を示します。
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* # set boot-mode uefi UCS-A /org/boot-policy* # commit-buffer UCS-A /org/boot-policy # create boot-security UCS-A /org/boot-policy/boot-security* # set secure-boot yes UCS-A /org/boot-policy/boot-security* # commit-buffer UCS-A /org/boot-policy/boot-security #
次の 1 つ以上のオプションをブート ポリシーに設定し、ブート順序を設定します。
LAN Boot:中央集中型プロビジョニング サーバからブートします。 これは、このサーバから、別のサーバ上にオペレーティング システムをインストールするためによく使用されます。
LAN Boot オプションを選択した場合は、ブート ポリシー用 LAN ブート ポリシー設定に進みます。
SAN Boot:SAN のオペレーティング システム イメージからブートします。 プライマリおよびセカンダリ SAN ブートを指定できます。 プライマリ ブートが失敗した場合、サーバはセカンダリからのブートを試行します。
システムに最高のサービス プロファイル モビリティを提供する SAN ブート ポリシーの使用を推奨します。 SAN からブートした場合、あるサーバから別のサーバにサービス プロファイルを移動すると、移動後のサーバは、まったく同じオペレーティング システム イメージからブートします。 したがって、ネットワークからは、この新しいサーバはまったく同じサーバと認識されます。
SAN Boot オプションを選択した場合は、ブート ポリシー用 SAN ブート ポリシー設定に進みます。
Virtual Media Boot:サーバへの物理 CD の挿入を模倣します。 これは通常、サーバ上にオペレーティング システムを手動でインストールする場合に使用されます。
Virtual Media Boot オプションを選択した場合は、ブート ポリシー用仮想メディア ブート ポリシー設定に進みます。
ヒント |
ローカル ディスクと SAN LUN の両方がブート順序のストレージ タイプに設定されていて、オペレーティング システムまたは論理ボリューム マネージャ(LVM)の設定が誤っている場合、サーバが SAN LUN ではなくローカル ディスクからブートする場合があります。 たとえば、Red Hat Linux がインストールされているサーバで、LVM にデフォルトの LVM が設定されていて、ブート順序に SAN LUN とローカル ディスクが設定されている場合、Linux は同じ名前の LV が 2 つあるという通知を生成し、SCSI ID の値が最も小さい LV(ローカル ディスクの可能性があります)からブートします。 |
ブート ポリシーをサービス プロファイルとテンプレートのうち一方、または両方に含めます。
SAN 上のオペレーティング システム イメージから 1 つ以上のサーバがブートするように、ブート ポリシーを設定できます。 ブート ポリシーにはプライマリとセカンダリの SAN ブート含めることができます。 プライマリ ブートが失敗した場合、サーバはセカンダリからのブートを試行します。
システムに最高のサービス プロファイル モビリティを提供する SAN ブートの使用を推奨します。 SAN からブートした場合、あるサーバから別のサーバにサービス プロファイルを移動すると、移動後のサーバは、まったく同じオペレーティング システム イメージからブートします。 したがって、ネットワークからは、この新しいサーバはまったく同じサーバと認識されます。
SAN ブートを使用するには、次の項目が設定されていることを確認してください。
Cisco UCS ドメインが、オペレーティング システム イメージをホストしている SAN ストレージ デバイスと通信できること。
オペレーティング システム イメージが置かれているデバイス上のブート ターゲット LUN。
(注) |
SAN ブートは、Cisco UCS ブレードおよびラック サーバ上の Gen-3 Emulex アダプタではサポートされていません。 |
ヒント |
ローカル ディスクと SAN LUN の両方がブート順序のストレージ タイプに設定されていて、オペレーティング システムまたは論理ボリューム マネージャ(LVM)の設定が誤っている場合、サーバが SAN LUN ではなくローカル ディスクからブートする場合があります。 たとえば、Red Hat Linux がインストールされているサーバで、LVM にデフォルトの LVM が設定されていて、ブート順序に SAN LUN とローカル ディスクが設定されている場合、Linux は同じ名前の LV が 2 つあるという通知を生成し、SCSI ID の値が最も小さい LV(ローカル ディスクの可能性があります)からブートします。 |
この手順は、ブート ポリシーの作成 から直接続いています。
SAN ブート設定を含めるブート ポリシーを作成します。
(注) |
SAN LUN からサーバをブートするブート ポリシーを作成し、安定した SAN ブート操作が必要な場合は、ブート ポリシーを含むサービス プロファイルに関連付けられたサーバからすべてのローカル ディスクを最初に削除する必要があります。 これは、Cisco UCS M3 および M4 サーバには適用されません。 |
リリース 2.2 以降では、すべての SAN ブート関連 CLI コマンドが SAN スコープに移動されています。 org/boot-policy/san または org/service-profile/boot-definition/san の代わりにストレージ スコープ下の SAN ブートを使用する以前のリリースからの既存のスクリプトは、更新する必要があります。
コマンドまたはアクション | 目的 | |
---|---|---|
ステップ 1 | UCS-A# scope org org-name | 指定した組織の組織モードを開始します。 ルート組織モードに入るには、「/」を org-name として入力します。 |
ステップ 2 | UCS-A /org # scope boot-policy policy-name | 指定されたブート ポリシーの組織ブート ポリシー モードを開始します。 |
ステップ 3 | UCS-A /org/boot-policy # create san | ブート ポリシーの SAN ブートを作成し、組織ブート ポリシー ストレージ モードを開始します。 |
ステップ 4 | UCS-A /org/boot-policy/san # set order order_number | SAN ブートのブート順序を設定します。 1 ~ 16 の整数を入力します。 |
ステップ 5 | UCS-A /org/boot-policy/san # create san-image {primary | secondary} | SAN イメージの場所を作成し、san-image オプションが指定されている場合、組織ブート ポリシーのストレージ SAN イメージ モードを開始します。 Cisco UCS M3 サーバ、または M4 サーバの拡張ブート順序を使用している場合は、定義されたブート順序が使用されます。 標準ブート モードでは、「プライマリ」、「セカンダリ」という用語が使用されている場合これはブート順序を示すものではありません。 同じデバイス クラス内での実際のブート順序は、PCIe バス スキャン順序により決定されます。 |
ステップ 6 | UCS-A /org/boot-policy/ssn/san-image # set vhba vhba-name | SAN ブートに使用される vHBA を指定します。 |
ステップ 7 | UCS-A /org/boot-policy/san/san-image # create path {primary | secondary} | プライマリまたはセカンダリ SAN ブート パスを作成し、組織ブート ポリシーの SAN パス モードを開始します。 Cisco UCS M3 サーバ、または M4 サーバの拡張ブート順序を使用している場合は、定義されたブート順序が使用されます。 標準ブート モードでは、「プライマリ」、「セカンダリ」という用語が使用されている場合これはブート順序を示すものではありません。 同じデバイス クラス内での実際のブート順序は、PCIe バス スキャン順序により決定されます。 |
ステップ 8 | UCS-A /org/boot-policy/san/san-image/path # set {lun lun-id | wwn wwn-num} | ブート イメージへの SAN パスに使用される LUN または WWN を指定します。 |
ステップ 9 | UCS-A /org/boot-policy/san/san-image/path # commit-buffer | トランザクションをシステムの設定にコミットします。 |
次の例は、lab1-boot-policy という名前のブート ポリシーに入り、ポリシーの SAN ブートを作成し、ブート順序を 1 に設定し、vHBA2 という名前の vHBA を使用し、LUN 0 を使用してプライマリ パスを作成し、トランザクションをコミットします。
UCS-A# scope org / UCS-A /org* # scope boot-policy lab1-boot-policy UCS-A /org/boot-policy # create san UCS-A /org/boot-policy/san* # set order 1 UCS-A /org/boot-policy/san* # create san-image primary UCS-A /org/boot-policy/san/san-image* # set vhba vHBA2 UCS-A /org/boot-policy/san/san-image* # create path primary UCS-A /org/boot-policy/san/san-image/path* # set lun 0 UCS-A /org/boot-policy/san/san-image/path* # commit-buffer UCS-A /org/boot-policy/san/san-image/path #
次の例では、サービス プロファイル SP_lab1 用の SAN ブートを作成し、ブート順序を 1 に設定し、プライマリ SAN イメージを作成し、vHBA2 という名前の vHBA を使用し、LUN 0 を使用してプライマリ パスを作成し、トランザクションをコミットします。
UCS-A# scope org / UCS-A /org* # scope service-profile SP_lab1 UCS-A /org/service-profile # create boot-definition UCS-A /org/service-profile/boot-definition* # create san UCS-A /org/service-profile/boot-definition/san* # create san-image primary UCS-A /org/service-profile/boot-definition/san/san-image* # set vhba vHBA2 UCS-A /org/service-profile/boot-definition/san/san-image* # create path primary UCS-A /org/service-profile/boot-definition/san/san-image/path* # set lun 0 UCS-A /org/service-profile/boot-definition/san/san-image/path* # commit-buffer UCS-A /org/service-profile/boot-definition/san/san-image/path #
ブート ポリシーをサービス プロファイルとテンプレートのうち一方、または両方に含めます。
LAN の集中プロビジョニング サーバから 1 つまたは複数のサーバをブートするブート ポリシーを設定できます。 LAN(または PXE)ブートは、その LAN サーバからサーバに OS をインストールする際に頻繁に使用されます。
LAN ブート ポリシーには、複数のタイプのブート デバイスを追加できます。 たとえば、ローカル ディスクや仮想メディア ブートをセカンダリ ブート デバイスとして追加できます。
LAN ブート設定を含めるブート ポリシーを作成します。
コマンドまたはアクション | 目的 | |
---|---|---|
ステップ 1 | UCS-A# scope org org-name | 指定した組織の組織モードを開始します。 ルート組織モードに入るには、「/」を org-name として入力します。 |
ステップ 2 | UCS-A /org # scope boot-policy policy-name | 指定されたブート ポリシーの組織ブート ポリシー モードを開始します。 |
ステップ 3 | UCS-A /org/boot-policy # create lan | ブート ポリシーの LAN ブートを作成し、組織ブート ポリシー LAN モードを開始します。 |
ステップ 4 | UCS-A /org/boot-policy/lan # set order {1 | 2 | 3 | 4} | LAN ブートのブート順序を指定します。 |
ステップ 5 | UCS-A /org/boot-policy/lan # create path {primary | secondary} | プライマリまたはセカンダリ LAN ブート パスを作成し、組織ブート ポリシーの LAN パス モードを開始します。 |
ステップ 6 | UCS-A /org/boot-policy/lan/path # set vnic vnic-name | ブート イメージへの LAN パスとして vNIC を使用するよう指定します。 |
ステップ 7 | UCS-A /org/boot-policy/lan/path # commit-buffer | トランザクションをシステムの設定にコミットします。 |
次の例は、lab2-boot-policy というブート ポリシーに入り、ポリシーに LAN ブートを作成し、ブート順序を 2 に設定し、vNIC1 および vNIC2 という名前の vNIC を使用するプライマリとセカンダリのパスを作成し、トランザクションをコミットします。
UCS-A# scope org / UCS-A /org* # scope boot-policy lab2-boot-policy UCS-A /org/boot-policy* # create lan UCS-A /org/boot-policy/lan* # set order 2 UCS-A /org/boot-policy/lan* # create path primary UCS-A /org/boot-policy/lan/path* # set vnic vNIC1 UCS-A /org/boot-policy/lan/path* # exit UCS-A /org/boot-policy/lan* # create path secondary UCS-A /org/boot-policy/lan/path* # set vnic vNIC2 UCS-A /org/boot-policy/lan/path* # commit-buffer UCS-A /org/boot-policy/lan/path #
ブート ポリシーをサービス プロファイルとテンプレートのうち一方、または両方に含めます。
Cisco UCS Manager では、異なるローカル デバイスから起動することができます。
(注) |
Cisco UCS M3 および M4 ブレード/ラック サーバで拡張ブート順序を使用する場合は、最上位と第 2 レベルの両方のブート デバイスを選択できます。 標準のブート順序を使用している Cisco UCS M1 と M2 のブレード サーバとラック サーバの場合、トップレベルのブート デバイスのみを選択できます。 |
サーバにローカル ドライブがある場合は、ブート ポリシーを設定して、最上位のローカル ディスク デバイスまたは以下の第 2 レベルのデバイスからサーバを起動できます。
(注) |
第 2 レベルのデバイスは、Cisco UCS M3 および M4 ブレード/ラック サーバで拡張ブート順序を使用する場合にのみ使用できます。 標準のブート順序を使用している Cisco UCS M1 と M2 のブレード サーバとラック サーバの場合、トップレベルの [Add Local Disk] のみを選択できます。 |
ブート ポリシーを設定して、サーバからアクセスできる仮想メディア デバイスから 1 つ以上のサーバを起動できます。 仮想メディア デバイスは、物理 CD/DVD ディスク(読み取り専用)またはフロッピー ディスク(読み取り書き込み)のサーバへの挿入を疑似的に実行します。 このタイプのサーバ ブートは、通常、サーバに手動でオペレーティング システムをインストールするために使用されます。
(注) |
第 2 レベルのデバイスは、Cisco UCS M3 および M4 ブレード/ラック サーバで拡張ブート順序を使用する場合にのみ使用できます。 標準のブート順序を使用している Cisco UCS M1 と M2 のブレード サーバとラック サーバの場合、トップレベルの [Add CD/DVD] または [Add Floppy] のみを選択できます。 |
ブート ポリシーを設定して、サーバからアクセスできるリモート仮想ドライブから 1 つ以上のサーバを起動できます。
サービス プロファイルまたはサービス プロファイル テンプレートに制限されたローカル ブート ポリシーを作成することもできます。 しかし、複数のサービス プロファイルまたはサービス プロファイル テンプレートに含むことのできるグローバルなブート ポリシーの作成を推奨します。
ブート ポリシーには複数のタイプのブート デバイスを追加できます。 たとえば、セカンダリ ブート デバイスとして、仮想メディア ブートを追加できます。
(注) |
リリース 2.2 以降では、ブート順序にトップレベルのローカル ストレージ デバイスを追加するには、create local コマンドの後に create local-any を使用します。 ローカル ストレージ デバイスを含む以前のリリースからのポリシーがある場合は、それらはアップグレード中に local-any を使用するように変更されます。 |
コマンドまたはアクション | 目的 | |||
---|---|---|---|---|
ステップ 1 | UCS-A# scope org org-name | 指定した組織の組織モードを開始します。 ルート組織モードに入るには、「/」を org-name として入力します。 |
||
ステップ 2 | UCS-A /org # scope boot-policy policy-name | 指定されたブート ポリシーの組織ブート ポリシー モードを開始します。 |
||
ステップ 3 | UCS-A /org/boot-policy # create storage | ブート ポリシーのストレージ ブートを作成し、組織ブート ポリシー ストレージ モードを開始します。 |
||
ステップ 4 | UCS-A /org/boot-policy/storage # create local | ローカル ストレージ場所を作成し、ブート ポリシーのローカル ストレージ モードを開始します。 |
||
ステップ 5 | UCS-A /org/boot-policy/storage/local/ # create {local-any | local-lun | sd-card | usb-extern | usb-intern } | ローカル ストレージのタイプを指定します。 次のいずれかになります。
Cisco UCS M3 および M4 ブレード/ラック サーバで拡張ブート順序を使用する場合は、最上位と第 2 レベルの両方のブート デバイスを選択できます。 標準のブート順序を使用している Cisco UCS M1 と M2 のブレード サーバとラック サーバの場合、トップレベルのブート デバイスのみを選択できます。 |
||
ステップ 6 | UCS-A /org/boot-policy/storage/local/local-storage-device # set order order_number | 指定したローカル ストレージ デバイスのブート順序を設定します。 1 ~ 16 の整数を入力します。 Cisco UCS M3 サーバ、または M4 サーバの拡張ブート順序を使用している場合は、定義されたブート順序が使用されます。 標準ブート モードでは、「プライマリ」、「セカンダリ」という用語が使用されている場合これはブート順序を示すものではありません。 同じデバイス クラス内での実際のブート順序は、PCIe バス スキャン順序により決定されます。 |
||
ステップ 7 | UCS-A /org/boot-policy/storage/local/local-storage-device # commit-buffer | トランザクションをシステムの設定にコミットします。 |
次の例では、lab1-boot-policy という名前のブート ポリシーを作成し、そのポリシーのローカル ハード ディスク ドライブのブートを作成し、ブート順序を 3 に設定し、トランザクションをコミットする方法を示します。
UCS-A# scope org / UCS-A /org* # scope boot-policy lab1-boot-policy UCS-A /org/boot-policy* # create storage UCS-A /org/boot-policy/storage* # create local UCS-A /org/boot-policy/storage/local* # create local-lun UCS-A /org/boot-policy/storage/local/sd-card* # set order 3 UCS-A /org/boot-policy/storage/local/sd-card* # commit-buffer UCS-A /org/boot-policy/storage/local/sd-card #
次の例では、サービス プロファイル SP_lab1 のローカル SD カード ブートを作成し、ブート順序を 3 に設定し、トランザクションをコミットする例を示します。
UCS-A# scope org / UCS-A /org* # scope service-profile SP_lab1 UCS-A /org/service-profile # create boot-definition UCS-A /org/service-profile/boot-definition* # create storage UCS-A /org/service-profile/boot-definition/storage* # create local UCS-A /org/service-profile/boot-definition/storage/local* # create sd-card UCS-A /org/service-profile/boot-definition/storage/local* # set order 3 UCS-A /org/service-profile/boot-definition/storage/local* # commit-buffer UCS-A /org/service-profile/boot-definition/storage/local #
次の例では、サービス プロファイル SP_lab1 のトップレベルのローカル ドライブ ブートを作成し、ブート順序を 3 に設定し、トランザクションをコミットする例を示します。
UCS-A# scope org / UCS-A /org* # scope service-profile SP_lab1 UCS-A /org/service-profile # create boot-definition UCS-A /org/service-profile/boot-definition* # create storage UCS-A /org/service-profile/boot-definition/storage* # create local UCS-A /org/service-profile/boot-definition/storage/local* # create local-any UCS-A /org/service-profile/boot-definition/storage/local/local-any* # set order 3 UCS-A /org/service-profile/boot-definition/storage/local/local-any* # commit-buffer UCS-A /org/service-profile/boot-definition/storage/local/local-any #
ブート ポリシーをサービス プロファイルとテンプレートのうち一方、または両方に含めます。
(注) |
仮想メディアでは、USB を有効にする必要があります。 USB の機能に影響する BIOS 設定を変更した場合は、仮想メディアにも影響します。 したがって、最適なパフォーマンスを実現するためには、次の USB BIOS をデフォルト設定のままにしておくことをお勧めします。
|
仮想メディア ブート設定を含めるブート ポリシーを作成します。
コマンドまたはアクション | 目的 | |||
---|---|---|---|---|
ステップ 1 | UCS-A# scope org org-name | 指定した組織の組織モードを開始します。 ルート組織モードに入るには、「/」を org-name として入力します。 |
||
ステップ 2 | UCS-A /org # scope boot-policy policy-name | 指定されたブート ポリシーの組織ブート ポリシー モードを開始します。 |
||
ステップ 3 | UCS-A /org/boot-policy # create virtual-media {read-only | read-only-local | read-only-remote | read-write | read-write-drive | read-write-local | read-write-remote} | ブート ポリシーの指定仮想メディア ブートを作成し、組織ブート ポリシーの仮想メディア モードを開始します。 次のいずれかになります。
|
||
ステップ 4 | UCS-A /org/boot-policy/virtual-media # set order order_number | 仮想メディア ブートのブート順序を設定します。 1 ~ 16 の整数を入力します。 |
||
ステップ 5 | UCS-A /org/boot-policy/virtual-media # commit-buffer | トランザクションをシステムの設定にコミットします。 |
次の例では、lab3-boot-policy という名前のブート ポリシーを開始し、CD/DVD 仮想メディア ブートを作成し、ブート順序を 3 に設定し、トランザクションをコミットする方法を示します。
UCS-A# scope org / UCS-A /org* # scope boot-policy lab3-boot-policy UCS-A /org/boot-policy* # create virtual-media read-only-local UCS-A /org/boot-policy/virtual-media* # set order 3 UCS-A /org/boot-policy/virtual-media* # commit-buffer
ブート ポリシーをサービス プロファイルとテンプレートのうち一方、または両方に含めます。
サービス プロファイルまたはサービス プロファイル テンプレートに制限されたローカル ブート ポリシーを作成することもできます。 しかし、複数のサービス プロファイルまたはサービス プロファイル テンプレートに含むことのできるグローバルなブート ポリシーの作成を推奨します。
コマンドまたはアクション | 目的 | |
---|---|---|
ステップ 1 | UCS-A# scope org org-name | 指定した組織の組織モードを開始します。 ルート組織モードに入るには、「/」を org-name として入力します。 |
ステップ 2 | UCS-A /org # create boot-policy policy-name | ブート ポリシーを指定されたポリシー名で作成し、組織ブート ポリシー モードを開始します。 |
ステップ 3 | UCS-A /org/boot-policy* # create virtual-media ? | アクセスと起動が可能なローカルおよびリモートのデバイスのリストを表示します。 |
ステップ 4 | UCS-A /org/boot-policy* # create virtual-media {access | vMediaMappingName} | アクセスと起動が可能なローカルおよびリモートのデバイスのリストを表示します。 |
ステップ 5 | UCS-A /org/boot-policy* # create virtual-media read-write-remote-drive vMediaMap0} | 指定した vMedia に対する vMedia ブート デバイス構成を作成します。 |
ステップ 6 | UCS-A /org/boot-policy/virtual-media* # commit-buffer | トランザクションをシステムの設定にコミットします。 |
ステップ 7 | UCS-A /org/boot-policy/virtual-media* # show detail expand | 次のブート順序を表示します。 ブート仮想メディア: 順序:1 アクセス:読み取り/書き込みリモート vMedia ドライブ 名前:vmediaMap0 |
次に、CIMC vMedia ブート ポリシーを作成する例を示します。
UCS-A# scope org / UCS-A /org* # create boot-policy boot-policy vm-vmediamap-boot UCS-A /org/boot-policy* # create virtual-media
コマンドまたはアクション | 目的 | |
---|---|---|
ステップ 1 | UCS-A# scope server chassis_id/blade_id | 指定サーバのシャーシ サーバ モードを開始します。 |
ステップ 2 | UCS-A# /chassis/server # scope cimc | CIMC モードを開始します。 |
ステップ 3 | UCS-A /chassis/server/cimc # show vmedia-mapping-list detail expand | vMedia マッピングの詳細を表示します。 |
次に、CIMC vMedia のマウントを表示する例を示します。
UCS-A# scope server 1/2 UCS-A /chassis/server # scope cimc UCS-A /chassis/server/cimc # show vmedia-mapping-list detail expand vMedia Mapping List: vMedia Mapping: Disk Id: 1 Mapping Name: cdd Device Type: Cdd Remote IP: 172.31.1.167 Image Path: cifs Image File Name: ubunt-14.11-desktop-i386.iso Mount Protocol: Cifs Mount Status: Mounted Error: None Password: User ID: Adminstrator UCS-A /chassis/server/cimc #
コマンドまたはアクション | 目的 | |
---|---|---|
ステップ 1 | UCS-A# scope org org-name | 指定した組織の組織モードを開始します。 ルート組織モードを開始するには、org-name に / と入力します。 |
ステップ 2 | UCS-A /org # delete boot-policy policy-name | 指定されたブート ポリシーを削除します。 |
ステップ 3 | UCS-A /org # commit-buffer | トランザクションをシステムの設定にコミットします。 |
次の例では、boot-policy-LAN という名前のブート ポリシーを削除し、トランザクションをコミットします。
UCS-A# scope org / UCS-A /org # delete boot-policy boot-policy-LAN UCS-A /org* # commit-buffer UCS-A /org #
目次
この章は、次の項で構成されています。
ブート ポリシー
Cisco UCS Manager ブート ポリシーは、BIOS 設定メニューのブート順序をオーバーライドし、次のことを決定します。
たとえば、ローカル ディスクや CD-ROM(VMedia)などのローカル デバイスから関連するサーバを選択するか、または SAN ブートもしくは LAN(PXE)ブートを選択することができます。
1 つ以上のサービス プロファイルに関連付けることができる名前付きブート ポリシーを作成するか、特定のサービス プロファイルに対するブート ポリシーを作成できます。 ブート ポリシーを有効にするには、ブート ポリシーをサービス プロファイルに含め、このサービス プロファイルをサーバに関連付ける必要があります。 サービス プロファイルにブート ポリシーを含めない場合、Cisco UCS Manager によってデフォルトのブート ポリシーが適用されます。
(注)
ブート ポリシーに対する変更は、そのブート ポリシーを含んでいる、更新中のサービス プロファイル テンプレートを使って作成されたすべてのサーバに伝播されます。 BIOS にブート順序情報を再書き込みするためのサービス プロファイルとサーバとの再アソシエーションは自動的にトリガーされます。
UEFI ブート モード
Unified Extensible Firmware Interface(UEFI)は、オペレーティング システムとプラットフォーム ファームウェア間のソフトウェア インターフェイスを定義する仕様です。 Cisco UCS Manager は、UEFI を使用して BIOS ファームウェア インターフェイスを置き換えします。 これにより、BIOS は従来のサポートを提供しながら、UEFI モードで動作できるようになります。
ブート ポリシーを作成する際は、レガシー ブート モードまたは UEFI ブート モードのいずれかを選択できます。 レガシー ブート モードは、すべての Cisco UCS サーバでサポートされます。 UEFI ブート モードは M3 および M4 サーバでのみサポートされ、ユーザは UEFI セキュア ブート モードを有効にすることができます。
UEFI ブート モードには以下の制限が適用されます。
UEFI ブート モードは、Cisco UCS B シリーズ M3 および M4 ブレードサーバと、Cisco UCS C シリーズ M3 および M4 ラック サーバでのみサポートされます。
UEFI ブート モードは、次の組み合わせではサポートされません。
同じサーバで UEFI ブート モードとレガシー ブート モードを混在させることはできません。
ブート ポリシーに設定されているブート デバイスに UEFI 対応オペレーティング システムがインストールされている場合にのみ、サーバは UEFI モードで正常に起動します。 互換性のある OS が存在しない場合、ブート デバイスは [Boot Order Details] 領域の [Actual Boot Order] タブに表示されません。
ごくまれですが、UEFI ブート マネージャ エントリが BIOS NVRAM に正しく保存されなかったため、UEFI ブートが成功しない場合があります。 UEFI シェルを使用すると、UEFI ブート マネージャ エントリを手動で入力することができます。 この状況は、以下の場合に発生する可能性があります。
UEFI セキュア ブート
Cisco UCS Manager は、Cisco UCS B シリーズ M3 および M4 ブレード サーバで UEFI セキュア ブートをサポートします。 UEFI セキュア ブートを有効にすると、すべての実行可能ファイル(ブート ローダ、アダプタ ドライバなど)はロードされる前に BIOS によって認証されます。 認証されるには、そのイメージに Cisco 認証局(CA)または Microsoft CA による署名が必要です。
UEFI セキュア ブートには次の制限が適用されます。
UEFI ブート モードは、ブート ポリシーで有効にする必要があります。
Cisco UCS Manager ソフトウェアと BIOS ファームウェアは、リリース 2.2 以降である必要があります。
ユーザにより生成された暗号キーはサポートされません。
UEFI セキュア ブートは、Cisco UCS Manager でのみ制御できます。
- Cisco UCS Managerの以前のバージョンにダウングレードする必要があり、ブレード サーバがセキュア ブート モードになっている場合は、ダウングレードを実行する前に、ブレード サーバの関連付けを解除し、再び関連付ける必要があります。 これを行わないと、そのブレード サーバは正常に検出されません。
ブート ポリシーの作成
サービス プロファイルまたはサービス プロファイル テンプレートに制限されたローカル ブート ポリシーを作成することもできます。 しかし、複数のサービス プロファイルまたはサービス プロファイル テンプレートに含むことのできるグローバルなブート ポリシーの作成を推奨します。
はじめる前に手順SAN LUN からサーバをブートするブート ポリシーを作成し、安定した SAN ブート操作が必要な場合は、ブート ポリシーを含むサービス プロファイルに関連付けられたサーバからすべてのローカル ディスクを最初に削除する必要があります。
(注)
これは、Cisco UCS M3 および M4 サーバには適用されません。
コマンドまたはアクション 目的 ステップ 1 UCS-A# scope org org-name 指定した組織の組織モードを開始します。 ルート組織モードに入るには、「/」を org-name として入力します。
ステップ 2 UCS-A /org # create boot-policy policy-name [purpose {operational | utility}] ブート ポリシーを指定されたポリシー名で作成し、組織ブート ポリシー モードを開始します。
ブート ポリシーを作成する場合、operational オプションを指定します。 これにより、サーバは、サーバにインストールされているオペレーティング システムからブートするようにします。 utility オプションは予約されており、シスコの担当者が指示した場合にのみ使用するようにします。
ステップ 3 UCS-A /org/boot-policy # set descr description (任意) ブート ポリシーの説明を記入します。
(注) 説明にスペース、特殊文字、または句読点が含まれている場合、説明を引用符で括る必要があります。 引用符は show コマンド出力の説明フィールドには表示されません。
ステップ 4 UCS-A /org/boot-policy # set reboot-on-update {no | yes} このブート ポリシーを使用するサーバが、ブート順序の変更後に自動的に再起動されるかどうかを指定します。
ステップ 5 UCS-A /org/boot-policy # set enforce-vnic-name {no | yes} [yes] を選択すると、Cisco UCS Manager は設定エラーを表示し、[Boot Order] テーブルにリストされた 1 つ以上の vNIC、vHBA、iSCSI、vNIC がサーバ プロファイル内のサーバ設定に一致するかどうかをレポートします。
[no] を選択すると、Cisco UCS Managerはサービス プロファイルからvNIC、vHBA、または iSCSI vNIC(ブート オプションに適切なもの)を使用します。
ステップ 6 UCS-A /org/boot-policy # set boot-mode {legacy | uefi} このブート ポリシーを使用するサーバが UEFI またはレガシー ブート モードを使用するかどうかを指定します。
ステップ 7 UCS-A /org/boot-policy # commit-buffer トランザクションをシステムの設定にコミットします。
ステップ 8 UCS-A /org/boot-policy # create boot-security 指定したブート ポリシーでブート セキュリティ モードを開始します。
ステップ 9 UCS-A /org/boot-policy/boot-security # set secure-boot {no | yes} セキュア ブートがブート ポリシーに対してイネーブルにするかを指定します。
ステップ 10 UCS-A /org/boot-policy/boot-security # commit-buffer トランザクションをシステムの設定にコミットします。
次の作業以下の例では、boot-policy-LAN という名前のブート ポリシーを作成し、このポリシーを使用するサーバがブート順序が変更されたときに自動的にリブートされないよう指定し、UEFI ブート モードを設定し、UEFI ブート セキュリティをイネーブルにし、トランザクションをコミットする方法を示します。
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* # set boot-mode uefi UCS-A /org/boot-policy* # commit-buffer UCS-A /org/boot-policy # create boot-security UCS-A /org/boot-policy/boot-security* # set secure-boot yes UCS-A /org/boot-policy/boot-security* # commit-buffer UCS-A /org/boot-policy/boot-security #
次の 1 つ以上のオプションをブート ポリシーに設定し、ブート順序を設定します。
LAN Boot:中央集中型プロビジョニング サーバからブートします。 これは、このサーバから、別のサーバ上にオペレーティング システムをインストールするためによく使用されます。
LAN Boot オプションを選択した場合は、ブート ポリシー用 LAN ブート ポリシー設定に進みます。
SAN Boot:SAN のオペレーティング システム イメージからブートします。 プライマリおよびセカンダリ SAN ブートを指定できます。 プライマリ ブートが失敗した場合、サーバはセカンダリからのブートを試行します。
システムに最高のサービス プロファイル モビリティを提供する SAN ブート ポリシーの使用を推奨します。 SAN からブートした場合、あるサーバから別のサーバにサービス プロファイルを移動すると、移動後のサーバは、まったく同じオペレーティング システム イメージからブートします。 したがって、ネットワークからは、この新しいサーバはまったく同じサーバと認識されます。
SAN Boot オプションを選択した場合は、ブート ポリシー用 SAN ブート ポリシー設定に進みます。
Virtual Media Boot:サーバへの物理 CD の挿入を模倣します。 これは通常、サーバ上にオペレーティング システムを手動でインストールする場合に使用されます。
Virtual Media Boot オプションを選択した場合は、ブート ポリシー用仮想メディア ブート ポリシー設定に進みます。
ヒント
ローカル ディスクと SAN LUN の両方がブート順序のストレージ タイプに設定されていて、オペレーティング システムまたは論理ボリューム マネージャ(LVM)の設定が誤っている場合、サーバが SAN LUN ではなくローカル ディスクからブートする場合があります。
たとえば、Red Hat Linux がインストールされているサーバで、LVM にデフォルトの LVM が設定されていて、ブート順序に SAN LUN とローカル ディスクが設定されている場合、Linux は同じ名前の LV が 2 つあるという通知を生成し、SCSI ID の値が最も小さい LV(ローカル ディスクの可能性があります)からブートします。
ブート ポリシーをサービス プロファイルとテンプレートのうち一方、または両方に含めます。
SAN ブート
SAN 上のオペレーティング システム イメージから 1 つ以上のサーバがブートするように、ブート ポリシーを設定できます。 ブート ポリシーにはプライマリとセカンダリの SAN ブート含めることができます。 プライマリ ブートが失敗した場合、サーバはセカンダリからのブートを試行します。
システムに最高のサービス プロファイル モビリティを提供する SAN ブートの使用を推奨します。 SAN からブートした場合、あるサーバから別のサーバにサービス プロファイルを移動すると、移動後のサーバは、まったく同じオペレーティング システム イメージからブートします。 したがって、ネットワークからは、この新しいサーバはまったく同じサーバと認識されます。
SAN ブートを使用するには、次の項目が設定されていることを確認してください。
Cisco UCS ドメインが、オペレーティング システム イメージをホストしている SAN ストレージ デバイスと通信できること。
オペレーティング システム イメージが置かれているデバイス上のブート ターゲット LUN。
(注)
SAN ブートは、Cisco UCS ブレードおよびラック サーバ上の Gen-3 Emulex アダプタではサポートされていません。
ブート ポリシー用 SAN ブート ポリシー設定
ヒント
ローカル ディスクと SAN LUN の両方がブート順序のストレージ タイプに設定されていて、オペレーティング システムまたは論理ボリューム マネージャ(LVM)の設定が誤っている場合、サーバが SAN LUN ではなくローカル ディスクからブートする場合があります。
たとえば、Red Hat Linux がインストールされているサーバで、LVM にデフォルトの LVM が設定されていて、ブート順序に SAN LUN とローカル ディスクが設定されている場合、Linux は同じ名前の LV が 2 つあるという通知を生成し、SCSI ID の値が最も小さい LV(ローカル ディスクの可能性があります)からブートします。
この手順は、ブート ポリシーの作成 から直接続いています。
はじめる前に手順SAN ブート設定を含めるブート ポリシーを作成します。
(注)
SAN LUN からサーバをブートするブート ポリシーを作成し、安定した SAN ブート操作が必要な場合は、ブート ポリシーを含むサービス プロファイルに関連付けられたサーバからすべてのローカル ディスクを最初に削除する必要があります。
これは、Cisco UCS M3 および M4 サーバには適用されません。
リリース 2.2 以降では、すべての SAN ブート関連 CLI コマンドが SAN スコープに移動されています。 org/boot-policy/san または org/service-profile/boot-definition/san の代わりにストレージ スコープ下の SAN ブートを使用する以前のリリースからの既存のスクリプトは、更新する必要があります。
コマンドまたはアクション 目的 ステップ 1 UCS-A# scope org org-name 指定した組織の組織モードを開始します。 ルート組織モードに入るには、「/」を org-name として入力します。
ステップ 2 UCS-A /org # scope boot-policy policy-name 指定されたブート ポリシーの組織ブート ポリシー モードを開始します。
ステップ 3 UCS-A /org/boot-policy # create san ブート ポリシーの SAN ブートを作成し、組織ブート ポリシー ストレージ モードを開始します。
ステップ 4 UCS-A /org/boot-policy/san # set order order_number SAN ブートのブート順序を設定します。 1 ~ 16 の整数を入力します。
ステップ 5 UCS-A /org/boot-policy/san # create san-image {primary | secondary} SAN イメージの場所を作成し、san-image オプションが指定されている場合、組織ブート ポリシーのストレージ SAN イメージ モードを開始します。
Cisco UCS M3 サーバ、または M4 サーバの拡張ブート順序を使用している場合は、定義されたブート順序が使用されます。 標準ブート モードでは、「プライマリ」、「セカンダリ」という用語が使用されている場合これはブート順序を示すものではありません。 同じデバイス クラス内での実際のブート順序は、PCIe バス スキャン順序により決定されます。
ステップ 6 UCS-A /org/boot-policy/ssn/san-image # set vhba vhba-name SAN ブートに使用される vHBA を指定します。
ステップ 7 UCS-A /org/boot-policy/san/san-image # create path {primary | secondary} プライマリまたはセカンダリ SAN ブート パスを作成し、組織ブート ポリシーの SAN パス モードを開始します。
Cisco UCS M3 サーバ、または M4 サーバの拡張ブート順序を使用している場合は、定義されたブート順序が使用されます。 標準ブート モードでは、「プライマリ」、「セカンダリ」という用語が使用されている場合これはブート順序を示すものではありません。 同じデバイス クラス内での実際のブート順序は、PCIe バス スキャン順序により決定されます。
ステップ 8 UCS-A /org/boot-policy/san/san-image/path # set {lun lun-id | wwn wwn-num} ブート イメージへの SAN パスに使用される LUN または WWN を指定します。
ステップ 9 UCS-A /org/boot-policy/san/san-image/path # commit-buffer トランザクションをシステムの設定にコミットします。
次の作業次の例は、lab1-boot-policy という名前のブート ポリシーに入り、ポリシーの SAN ブートを作成し、ブート順序を 1 に設定し、vHBA2 という名前の vHBA を使用し、LUN 0 を使用してプライマリ パスを作成し、トランザクションをコミットします。
UCS-A# scope org / UCS-A /org* # scope boot-policy lab1-boot-policy UCS-A /org/boot-policy # create san UCS-A /org/boot-policy/san* # set order 1 UCS-A /org/boot-policy/san* # create san-image primary UCS-A /org/boot-policy/san/san-image* # set vhba vHBA2 UCS-A /org/boot-policy/san/san-image* # create path primary UCS-A /org/boot-policy/san/san-image/path* # set lun 0 UCS-A /org/boot-policy/san/san-image/path* # commit-buffer UCS-A /org/boot-policy/san/san-image/path #次の例では、サービス プロファイル SP_lab1 用の SAN ブートを作成し、ブート順序を 1 に設定し、プライマリ SAN イメージを作成し、vHBA2 という名前の vHBA を使用し、LUN 0 を使用してプライマリ パスを作成し、トランザクションをコミットします。
UCS-A# scope org / UCS-A /org* # scope service-profile SP_lab1 UCS-A /org/service-profile # create boot-definition UCS-A /org/service-profile/boot-definition* # create san UCS-A /org/service-profile/boot-definition/san* # create san-image primary UCS-A /org/service-profile/boot-definition/san/san-image* # set vhba vHBA2 UCS-A /org/service-profile/boot-definition/san/san-image* # create path primary UCS-A /org/service-profile/boot-definition/san/san-image/path* # set lun 0 UCS-A /org/service-profile/boot-definition/san/san-image/path* # commit-buffer UCS-A /org/service-profile/boot-definition/san/san-image/path #
ブート ポリシーをサービス プロファイルとテンプレートのうち一方、または両方に含めます。
LAN ブート
LAN の集中プロビジョニング サーバから 1 つまたは複数のサーバをブートするブート ポリシーを設定できます。 LAN(または PXE)ブートは、その LAN サーバからサーバに OS をインストールする際に頻繁に使用されます。
LAN ブート ポリシーには、複数のタイプのブート デバイスを追加できます。 たとえば、ローカル ディスクや仮想メディア ブートをセカンダリ ブート デバイスとして追加できます。
ブート ポリシー用 LAN ブート ポリシー設定
手順
コマンドまたはアクション 目的 ステップ 1 UCS-A# scope org org-name 指定した組織の組織モードを開始します。 ルート組織モードに入るには、「/」を org-name として入力します。
ステップ 2 UCS-A /org # scope boot-policy policy-name 指定されたブート ポリシーの組織ブート ポリシー モードを開始します。
ステップ 3 UCS-A /org/boot-policy # create lan ブート ポリシーの LAN ブートを作成し、組織ブート ポリシー LAN モードを開始します。
ステップ 4 UCS-A /org/boot-policy/lan # set order {1 | 2 | 3 | 4} LAN ブートのブート順序を指定します。
ステップ 5 UCS-A /org/boot-policy/lan # create path {primary | secondary} プライマリまたはセカンダリ LAN ブート パスを作成し、組織ブート ポリシーの LAN パス モードを開始します。
ステップ 6 UCS-A /org/boot-policy/lan/path # set vnic vnic-name ブート イメージへの LAN パスとして vNIC を使用するよう指定します。
ステップ 7 UCS-A /org/boot-policy/lan/path # commit-buffer トランザクションをシステムの設定にコミットします。
次の作業次の例は、lab2-boot-policy というブート ポリシーに入り、ポリシーに LAN ブートを作成し、ブート順序を 2 に設定し、vNIC1 および vNIC2 という名前の vNIC を使用するプライマリとセカンダリのパスを作成し、トランザクションをコミットします。
UCS-A# scope org / UCS-A /org* # scope boot-policy lab2-boot-policy UCS-A /org/boot-policy* # create lan UCS-A /org/boot-policy/lan* # set order 2 UCS-A /org/boot-policy/lan* # create path primary UCS-A /org/boot-policy/lan/path* # set vnic vNIC1 UCS-A /org/boot-policy/lan/path* # exit UCS-A /org/boot-policy/lan* # create path secondary UCS-A /org/boot-policy/lan/path* # set vnic vNIC2 UCS-A /org/boot-policy/lan/path* # commit-buffer UCS-A /org/boot-policy/lan/path #
ブート ポリシーをサービス プロファイルとテンプレートのうち一方、または両方に含めます。
ローカル デバイス ブート
Cisco UCS Manager では、異なるローカル デバイスから起動することができます。
(注)
Cisco UCS M3 および M4 ブレード/ラック サーバで拡張ブート順序を使用する場合は、最上位と第 2 レベルの両方のブート デバイスを選択できます。 標準のブート順序を使用している Cisco UCS M1 と M2 のブレード サーバとラック サーバの場合、トップレベルのブート デバイスのみを選択できます。
ローカル ディスク ブート
サーバにローカル ドライブがある場合は、ブート ポリシーを設定して、最上位のローカル ディスク デバイスまたは以下の第 2 レベルのデバイスからサーバを起動できます。
(注)
第 2 レベルのデバイスは、Cisco UCS M3 および M4 ブレード/ラック サーバで拡張ブート順序を使用する場合にのみ使用できます。 標準のブート順序を使用している Cisco UCS M1 と M2 のブレード サーバとラック サーバの場合、トップレベルの [Add Local Disk] のみを選択できます。
仮想メディア ブート
ブート ポリシーを設定して、サーバからアクセスできる仮想メディア デバイスから 1 つ以上のサーバを起動できます。 仮想メディア デバイスは、物理 CD/DVD ディスク(読み取り専用)またはフロッピー ディスク(読み取り書き込み)のサーバへの挿入を疑似的に実行します。 このタイプのサーバ ブートは、通常、サーバに手動でオペレーティング システムをインストールするために使用されます。
(注)
第 2 レベルのデバイスは、Cisco UCS M3 および M4 ブレード/ラック サーバで拡張ブート順序を使用する場合にのみ使用できます。 標準のブート順序を使用している Cisco UCS M1 と M2 のブレード サーバとラック サーバの場合、トップレベルの [Add CD/DVD] または [Add Floppy] のみを選択できます。
- ブート ポリシー用ローカル ディスク ブート ポリシー設定
- ブート ポリシー用仮想メディア ブート ポリシー設定
- CIMC vMedia ブート ポリシーの作成
- CIMC vMedia マウントの表示
ブート ポリシー用ローカル ディスク ブート ポリシー設定
手順サービス プロファイルまたはサービス プロファイル テンプレートに制限されたローカル ブート ポリシーを作成することもできます。 しかし、複数のサービス プロファイルまたはサービス プロファイル テンプレートに含むことのできるグローバルなブート ポリシーの作成を推奨します。
ブート ポリシーには複数のタイプのブート デバイスを追加できます。 たとえば、セカンダリ ブート デバイスとして、仮想メディア ブートを追加できます。
(注)
リリース 2.2 以降では、ブート順序にトップレベルのローカル ストレージ デバイスを追加するには、create local コマンドの後に create local-any を使用します。 ローカル ストレージ デバイスを含む以前のリリースからのポリシーがある場合は、それらはアップグレード中に local-any を使用するように変更されます。
コマンドまたはアクション 目的 ステップ 1 UCS-A# scope org org-name 指定した組織の組織モードを開始します。 ルート組織モードに入るには、「/」を org-name として入力します。
ステップ 2 UCS-A /org # scope boot-policy policy-name 指定されたブート ポリシーの組織ブート ポリシー モードを開始します。
ステップ 3 UCS-A /org/boot-policy # create storage ブート ポリシーのストレージ ブートを作成し、組織ブート ポリシー ストレージ モードを開始します。
ステップ 4 UCS-A /org/boot-policy/storage # create local ローカル ストレージ場所を作成し、ブート ポリシーのローカル ストレージ モードを開始します。
ステップ 5 UCS-A /org/boot-policy/storage/local/ # create {local-any | local-lun | sd-card | usb-extern | usb-intern } ローカル ストレージのタイプを指定します。 次のいずれかになります。
[local-any]:ローカル ストレージ デバイスのタイプ。 このオプションは、レガシーまたは UEFI のブート モードで使用できます。
(注) 標準のブート順序を使用している Cisco UCS M1 および M2 のブレード サーバおよびラック サーバのみが local-any を使用できます。 [local-lun]:ローカルのハード ディスク ドライブ。
[sd-card]:SD カード。
[usb-extern]:外部 USB カード。
[usb-intern]:内部 USB カード。
Cisco UCS M3 および M4 ブレード/ラック サーバで拡張ブート順序を使用する場合は、最上位と第 2 レベルの両方のブート デバイスを選択できます。 標準のブート順序を使用している Cisco UCS M1 と M2 のブレード サーバとラック サーバの場合、トップレベルのブート デバイスのみを選択できます。
ステップ 6 UCS-A /org/boot-policy/storage/local/local-storage-device # set order order_number 指定したローカル ストレージ デバイスのブート順序を設定します。 1 ~ 16 の整数を入力します。
Cisco UCS M3 サーバ、または M4 サーバの拡張ブート順序を使用している場合は、定義されたブート順序が使用されます。 標準ブート モードでは、「プライマリ」、「セカンダリ」という用語が使用されている場合これはブート順序を示すものではありません。 同じデバイス クラス内での実際のブート順序は、PCIe バス スキャン順序により決定されます。
ステップ 7 UCS-A /org/boot-policy/storage/local/local-storage-device # commit-buffer トランザクションをシステムの設定にコミットします。
次の作業次の例では、lab1-boot-policy という名前のブート ポリシーを作成し、そのポリシーのローカル ハード ディスク ドライブのブートを作成し、ブート順序を 3 に設定し、トランザクションをコミットする方法を示します。
UCS-A# scope org / UCS-A /org* # scope boot-policy lab1-boot-policy UCS-A /org/boot-policy* # create storage UCS-A /org/boot-policy/storage* # create local UCS-A /org/boot-policy/storage/local* # create local-lun UCS-A /org/boot-policy/storage/local/sd-card* # set order 3 UCS-A /org/boot-policy/storage/local/sd-card* # commit-buffer UCS-A /org/boot-policy/storage/local/sd-card #次の例では、サービス プロファイル SP_lab1 のローカル SD カード ブートを作成し、ブート順序を 3 に設定し、トランザクションをコミットする例を示します。
UCS-A# scope org / UCS-A /org* # scope service-profile SP_lab1 UCS-A /org/service-profile # create boot-definition UCS-A /org/service-profile/boot-definition* # create storage UCS-A /org/service-profile/boot-definition/storage* # create local UCS-A /org/service-profile/boot-definition/storage/local* # create sd-card UCS-A /org/service-profile/boot-definition/storage/local* # set order 3 UCS-A /org/service-profile/boot-definition/storage/local* # commit-buffer UCS-A /org/service-profile/boot-definition/storage/local #次の例では、サービス プロファイル SP_lab1 のトップレベルのローカル ドライブ ブートを作成し、ブート順序を 3 に設定し、トランザクションをコミットする例を示します。
UCS-A# scope org / UCS-A /org* # scope service-profile SP_lab1 UCS-A /org/service-profile # create boot-definition UCS-A /org/service-profile/boot-definition* # create storage UCS-A /org/service-profile/boot-definition/storage* # create local UCS-A /org/service-profile/boot-definition/storage/local* # create local-any UCS-A /org/service-profile/boot-definition/storage/local/local-any* # set order 3 UCS-A /org/service-profile/boot-definition/storage/local/local-any* # commit-buffer UCS-A /org/service-profile/boot-definition/storage/local/local-any #
ブート ポリシーをサービス プロファイルとテンプレートのうち一方、または両方に含めます。
ブート ポリシー用仮想メディア ブート ポリシー設定
手順
(注)
仮想メディアでは、USB を有効にする必要があります。 USB の機能に影響する BIOS 設定を変更した場合は、仮想メディアにも影響します。 したがって、最適なパフォーマンスを実現するためには、次の USB BIOS をデフォルト設定のままにしておくことをお勧めします。
[Make Device Non Bootable]:[disabled] に設定します。
[USB Idle Power Optimizing Setting]:[high-performance] に設定します。
コマンドまたはアクション 目的 ステップ 1 UCS-A# scope org org-name 指定した組織の組織モードを開始します。 ルート組織モードに入るには、「/」を org-name として入力します。
ステップ 2 UCS-A /org # scope boot-policy policy-name 指定されたブート ポリシーの組織ブート ポリシー モードを開始します。
ステップ 3 UCS-A /org/boot-policy # create virtual-media {read-only | read-only-local | read-only-remote | read-write | read-write-drive | read-write-local | read-write-remote} ブート ポリシーの指定仮想メディア ブートを作成し、組織ブート ポリシーの仮想メディア モードを開始します。 次のいずれかになります。
[read-only]:ローカルまたはリモート CD/DVD。 このオプションは、レガシーまたは UEFI のブート モードで使用できます。
[read-only-local]:ローカル CD/DVD。
[read-only-remote]:リモート CD/DVD。
[read-write]:ローカルまたはリモート フロッピー ディスク ドライブ。 このオプションは、レガシーまたは UEFI のブート モードで使用できます。
[read-write-drive]:リモート USB ドライブ。
[read-write-local]:ローカル フロッピー ディスク ドライブ。
[read-write-remote]:リモート フロッピー ディスク ドライブ。
(注) Cisco UCS M3 および M4 ブレード/ラック サーバで拡張ブート順序を使用する場合は、最上位と第 2 レベルの両方のブート デバイスを選択できます。 標準のブート順序を使用している Cisco UCS M1 と M2 のブレード サーバとラック サーバの場合、トップレベルのブート デバイスのみを選択できます。
ステップ 4 UCS-A /org/boot-policy/virtual-media # set order order_number 仮想メディア ブートのブート順序を設定します。 1 ~ 16 の整数を入力します。
ステップ 5 UCS-A /org/boot-policy/virtual-media # commit-buffer トランザクションをシステムの設定にコミットします。
次の作業次の例では、lab3-boot-policy という名前のブート ポリシーを開始し、CD/DVD 仮想メディア ブートを作成し、ブート順序を 3 に設定し、トランザクションをコミットする方法を示します。
UCS-A# scope org / UCS-A /org* # scope boot-policy lab3-boot-policy UCS-A /org/boot-policy* # create virtual-media read-only-local UCS-A /org/boot-policy/virtual-media* # set order 3 UCS-A /org/boot-policy/virtual-media* # commit-buffer
ブート ポリシーをサービス プロファイルとテンプレートのうち一方、または両方に含めます。
CIMC vMedia ブート ポリシーの作成
手順サービス プロファイルまたはサービス プロファイル テンプレートに制限されたローカル ブート ポリシーを作成することもできます。 しかし、複数のサービス プロファイルまたはサービス プロファイル テンプレートに含むことのできるグローバルなブート ポリシーの作成を推奨します。
コマンドまたはアクション 目的 ステップ 1 UCS-A# scope org org-name 指定した組織の組織モードを開始します。 ルート組織モードに入るには、「/」を org-name として入力します。
ステップ 2 UCS-A /org # create boot-policy policy-name ブート ポリシーを指定されたポリシー名で作成し、組織ブート ポリシー モードを開始します。
ステップ 3 UCS-A /org/boot-policy* # create virtual-media ? アクセスと起動が可能なローカルおよびリモートのデバイスのリストを表示します。
ステップ 4 UCS-A /org/boot-policy* # create virtual-media {access | vMediaMappingName} アクセスと起動が可能なローカルおよびリモートのデバイスのリストを表示します。
ステップ 5 UCS-A /org/boot-policy* # create virtual-media read-write-remote-drive vMediaMap0} 指定した vMedia に対する vMedia ブート デバイス構成を作成します。 ステップ 6 UCS-A /org/boot-policy/virtual-media* # commit-buffer トランザクションをシステムの設定にコミットします。 ステップ 7 UCS-A /org/boot-policy/virtual-media* # show detail expand 次のブート順序を表示します。 ブート仮想メディア:
順序:1
アクセス:読み取り/書き込みリモート vMedia ドライブ
名前:vmediaMap0
CIMC vMedia マウントの表示
手順
コマンドまたはアクション 目的 ステップ 1 UCS-A# scope server chassis_id/blade_id 指定サーバのシャーシ サーバ モードを開始します。
ステップ 2 UCS-A# /chassis/server # scope cimc CIMC モードを開始します。
ステップ 3 UCS-A /chassis/server/cimc # show vmedia-mapping-list detail expand vMedia マッピングの詳細を表示します。
次に、CIMC vMedia のマウントを表示する例を示します。
UCS-A# scope server 1/2 UCS-A /chassis/server # scope cimc UCS-A /chassis/server/cimc # show vmedia-mapping-list detail expand vMedia Mapping List: vMedia Mapping: Disk Id: 1 Mapping Name: cdd Device Type: Cdd Remote IP: 172.31.1.167 Image Path: cifs Image File Name: ubunt-14.11-desktop-i386.iso Mount Protocol: Cifs Mount Status: Mounted Error: None Password: User ID: Adminstrator UCS-A /chassis/server/cimc #