solaris-kz - solaris カーネルゾーン
solaris-kz ブランドは brands(7) で説明しているブランドゾーンフレームワークを使用して、大域ゾーンで使用されているものと別のカーネルおよび OS インストールでゾーンを実行します。
solaris-kz インストールは大域ゾーンのインストールから独立しており、pkg でリンクされたイメージではなく、大域ゾーンの内容に関係なく、変更できます。solaris-kz ゾーンは、大域ゾーンから直接、または下記のようにブートメディア経由で、ほかのブランドと同じ方法でインストールできます。
インストールのマニフェストを指定する場合、使用するマニフェストは大域ゾーンのインストールに適したものにすべきです。カーネルゾーンは常にルートプールの既知の場所にインストールされるため、インストールターゲットディスクは指定できません。
ブート環境 (BE) 管理は大域ゾーンから独立しています。大域ゾーン内の BE の作成では、ゾーン内に新しい BE を作成しません。詳細は、beadm(8) のマニュアルページを参照してください。
ほかのブランドと異なり、solaris-kz ゾーンは個別のカーネルを実行するため、大域ゾーンからゾーンを調べた場合にいくつかの違いが見られます。
solaris-kz ゾーンで実行しているプロセスは、大域ゾーンから直接アクセスできません。たとえば、kz-zone というカーネルゾーンのプロセスのリストを表示するには、–z kz-zone オプションを付けて ps コマンドを使用するのではなく、次のコマンドを使用する必要があります。
# zlogin kz-zone ps -e
大域ゾーンと各カーネルゾーンはそれぞれ独自のプロセス ID 空間を管理します。そのため、process 1234 が大域ゾーンおよび 1 つ以上のカーネルゾーン内に存在することがあります。それらは一意のプロセスです。大域ゾーンの管理者が kz-zone 内の process 1234 を強制終了したいと考える場合、次のコマンドまたは同等のコマンドで実行してください。
# zlogin kz-zone kill 1234
大域ゾーンから実行される ps(1) および同様のツールは、kzhost や zlogin-kz などの solaris-kz ゾーンインスタンスの管理に関連付けられたプロセスを表示します。これはデバッグに役立ちますが、それ以外はプライベート実装の詳細です。
同様に、リソース管理機能が異なります。たとえば、max-processes などのリソース制御は、単一のカーネルインスタンスを共有する場合にのみ意味があるため、solaris-kz ゾーンを構成する場合に使用できません。つまり、カーネルが独立しているため、solaris-kz ゾーン内で実行中のプロセスは大域ゾーンのプロセステーブルスロットを占有できません。
zonestat ユーティリティーはゾーンのリソース使用量を表示します。この出力は一般に正しいですが、ホスト値を反映していることがあります。たとえば、lwps などのリソース制御値は、ゾーン内で使用されているものではなく、ホストで使用されている lwps を示します。
solaris-kz ブランドで使用される一部のハードウェア機能は、古いシステムや仮想化環境では利用できないこともあります。システムが solaris-kz brand をサポートするかどうかを検出するには、brand-solaris-kz パッケージをインストールし、virtinfo コマンドを実行します。
# virtinfo -c supported list kernel-zone
サポートされるリストに kernel-zone が表示されない場合、syslog を表示して詳細を確認できます。カーネルゾーンに関連するメッセージには、文字列 kernel-zone が含まれています。
mpstat(8)、iostat(8)、vmstat(8) やその他のユーティリティーによって報告される横取りされた時間には、ホストが CPU リソースをほかの目的に使用しているためにカーネルゾーンが動作できなかった時間が直接反映されています。
solaris-kz ブランドゾーンは 1 つ以上のデバイスに存在する必要があります。デフォルトの zfs(8) ボリュームは、インストールの前に構成がカスタマイズされていない場合、大域ゾーンのルート zpool に作成されます。ゾーンのインストール先のデバイスは、任意の正の整数値に設定された bootpri プロパティーを持つデバイスリソースで指定されます。デバイスをブートデバイスとして使用しない場合、bootpri プロパティーを設定しないでください。bootpri の設定を解除するには、デバイスのリソース範囲で bootpri のクリアを使用します。ブート可能な複数のデバイスがインストール中に存在する場合、これらのデバイスはゾーン内のミラー化ルート ZFS プールで使用されます。bootpri プロパティーは、ほかの bootpri エントリに対する相対的な順序を指定します。デフォルトのブート順は、最初に bootpri でエントリをソートし (値の小さいエントリが大きいエントリより前の順番になる)、複数のデバイスが同じ bootpri を持つ場合は次に id でソートして決定されます。例:
# zonecfg -z vzl-129 info device device: storage: dev:dsk/c0t0d0s0 id: 0 bootpri: 2 device: storage: dev:dsk/c0t1d0s0 id: 1 bootpri: 2 device: storage: dev:dsk/c0t2d0s0 id: 2 bootpri: 1
上の例の場合、ブート順は C、A、B になります。
zonepath をカーネルゾーンに対して設定することはできません。実装の詳細として、これは tmpfs(4FS) を使用して、固定の場所に設定されます。これは、永続的データも、ユーザーが運用可能なその他のデータも含みません。ゾーンルートは、ルート ZFS ボリュームに含まれるため、従来のゾーンと異なり、大域ゾーン内のゾーンパス下にマウントされません。ゾーンルートへのアクセスは、zlogin など、ゾーン自体からしか実行できません。
solaris-kz ゾーンは、ZFS データセットやファイルシステムマウントなどの共有カーネル機能を直接利用できません。代わりに、raw ディスク、ZFS ボリューム、lofi デバイスなどのブロックデバイス経由でゾーンからストレージを使用できます。
solaris-kz ゾーンのルートは常にアクセス可能です。ストレージは zonecfg で add device を使用して追加できます。storage プロパティーのみを設定できます。match プロパティーはサポートされていません。ディスクデバイスの構成にはストレージ URI が使用されます。詳細は、suri(7) のマニュアルページを参照してください。
ローカルデバイスパスのストレージ URI を storage プロパティーで設定できます。これは、ZFS ボリューム、raw ディスク、または lofi デバイスにできます。指定するデバイスはディスク全体か LUN である必要があります。パーティション/スライス接尾辞なしで、デバイスパスを使用できます。例:
# zonecfg -z myzone zonecfg:myzone> add device zonecfg:myzone:device> set storage=dev:/dev/rdsk/c4t9d0 zonecfg:myzone:device> set id=4 zonecfg:myzone:device> set bootpri=1
id を指定して、ゾーン内のディスクアドレスを修正できます。指定しない場合、自動的に割り当てられます。
ゾーンの構成をほかのホストシステムに移植可能にするために、移植可能なストレージ URI を storage プロパティーで構成することもできます。
例:
# zonecfg -z myzone zonecfg:myzone> add device zonecfg:myzone:device> set storage=nfs://user1:staff@host1/export/file1 zonecfg:myzone:device> set create-size=4g
デバイスリソースの現在の構成についての情報を参照するには、info サブコマンドを使用してください。例:
# zonecfg -z myzone info device
device:
storage: dev:/dev/zvol/dsk/rpool/VARSHARE/zones/myzone/disk0
id: 0
bootpri: 0
device:
storage: nfs://user1:staff@host1/export/file1
create-size: 4g
id: 1
bootpri not specified
id を指定して出力を短くすることもできます。
# zonecfg -z myzone info device id=1
device:
storage: nfs://user1:staff@host1/export/file1
create-size: 4g
id: 1
bootpri not specified
ゾーンを iSCSI 論理ユニットなどのデフォルト以外の場所にインストールするには、ルートディスクのデバイスリソースを変更する必要があります。例:
# zonecfg -z myzone zonecfg:myzone> select device id=0 zonecfg:myzone:device> set storage=iscsi://host/luname.naa.0000abcd
デバイスがブート可能であることを示すために、少なくとも 1 つのデバイスで bootpri が正の整数に設定される必要があります。カーネルゾーン内では、ルート ZFS プールのミラーまたはスペアとして機能するすべてのデバイスが、ブート可能である必要があります。ブート時に、デバイスが見つからない、iSCSI ストレージがオフラインになっている、などの理由によりデバイスの URI をマッピングできなかった場合、そのようなゾーンのブートは失敗します。
ストレージデバイスは、solaris-kz ブランドの add device によってのみサポートされています。
allow-mhd プロパティーを「true」に設定すると、アプリケーションは特定のデバイスに対して mhd(4I) の SCSI 予約 ioctl を使用できるようになります。これが可能なのは、バックエンドの SCSI デバイスが予約をサポートしている場合に限られます。このプロパティーを設定すると、ゾーンに次の影響があります。
ゾーンのライブ移行および中断/再開ができなくなります。
そのようなデバイスに対してライブゾーン再構成ができなくなります。
ホスト上のほかの実行中のゾーンによってそのデバイスを同時に共有できなくなります。
カーネルゾーンは排他的スタックである必要があります。ネットワークアクセスは、Ethernet データリンクに net または anet リソースを追加し、IPoIB データリンクに anet を追加することによって提供されます。これらのリソースによって指定されたデータリンクは、ゾーンに表示されるデータリンクのバックエンドとして使用されます。IPoIB と Ethernet の両方のネットワークリソースを指定でき、ゾーンに表示されるデータリンクが対応するメディアタイプになります。ストレージデバイスと同様に、ゾーン内の仮想 NIC アドレスを識別するために ID を指定できます。net リソースによる InfiniBand ネットワークリンクの追加はサポートされていません。
カーネルゾーンはそれ自体ホストゾーンになることがあります (その場合、それらのゾーンの大域ゾーンの役割を持ちます)。ホストされているゾーンへのネットワークアクセスは Ethernet データリンク経由でのみ提供され、IPoIB データリンク経由では提供されません。ただし、カーネルゾーンのネットワーク構成はそのゾーン構成によって部分的に定義されるため、MAC アドレスを使用できるホストされているゾーンは制限されます。
mac-address が random に設定されたゾーンのブートの試みが許可されるのは、次の場合です。
anet の allowed-mac-address が any に構成されている。
anet の allowed-mac-address が 2:8:20 に構成されている (2:8:20 は VNIC のデフォルトの OUI)。
mac-address が特定の MAC アドレスに設定されたゾーンのブートの試みが実行されるのは、ユーザー指定の MAC アドレスが allowed-mac-address リスト内のいずれかに一致した場合です。allowed-mac-address anet プロパティーの詳細は、zonecfg(8) のマニュアルページを参照してください。
カーネルゾーンに追加の MAC アドレスを提供するには、それらを関連リソースの mac-address プロパティーに追加します。詳細は、zonecfg(8) のマニュアルページを参照してください。これにより、その mac-address をカーネルゾーン内の出荷時アドレスとして使用できるようになります。
それにより、ホストされるゾーンでその MAC アドレス自体を使用できます。これを実行するには、ホストされているゾーンの mac-address プロパティーを、構成済みの明示的な MAC アドレスとして構成する (mac-address プロパティーを使用) か、または auto を指定します。これらの設定の詳細は、zonecfg(8) のマニュアルページを参照してください。
ホスト RAM の修正済みの量がカーネルゾーンに割り当てられる必要があります。これは、zonecfg(8) にある上限が定義されたメモリーリソースの physical プロパティーによって構成されます。指定した値はサポートされるプラットフォーム値に丸められることがあります。割り当てられたメモリーがロックされるため、スワップデバイスにページングできません。
physical プロパティーを指定する場合は、zonecfg(8) にある上限が定義されたメモリーリソースの pagesize-policy プロパティーも指定する必要があります。pagesize-policy プロパティーは、solaris-kz ブランドにポリシーを指定して、その物理メモリーに大きいページを使用するために使われます。pagesize-policy プロパティーは、physical プロパティーとともにのみ使用できます。pagesize-policy プロパティーに使用できるキーワードは次のとおりです。
カーネルゾーンの物理メモリーに使用できる最大のページサイズのみが割り当てられます。すべてのページの割り当てに失敗すると、ゾーンをブートできません。
使用できる最大のページサイズの指定を試みることができます。特定のページサイズですべての物理メモリーを割り当てられない場合はページサイズを縮小します。ゾーンをブートすることが優先されます。
特定のプラットフォームでカーネルゾーンをブートするために必要な使用できる最小のページサイズが選択されます。
古い suspend イメージ形式をサポートするには、pagesize-policy プロパティーをクリアするか、またはこのプロパティーが存在しないことが必要です。これにより、新しいシステムから古いシステムへの KZ のライブ移行および再開が可能になります。特定のプラットフォームでカーネルゾーンをブートするために必要な使用できる最小のページサイズが選択されます。
zonecfg(8) で説明しているように、仮想 CPU リソースと専用 CPU リソースを使用すれば、カーネルゾーンで使用可能な CPU を定義できます。通常、専用 CPU が、CPU リソースをカーネルゾーン専用として隔離するために使用されるのに対し、仮想 CPU は、CPU を共有してカーネルゾーンで使用可能な CPU リソースをきめ細かく制御できるようにする場合に使用されます。
仮想 CPU リソースと専用 CPU リソースをどのように構成するかによって、CPU 構成の動作は変わります。
カーネルゾーンは、物理ホストシステム上のほかのすべてのアプリケーションスレッドと計算時間のために競合する、4 つの仮想 CPU スレッドを取得します。
virtual-cpu:ncpus の値が N の場合、カーネルゾーンは、物理ホストシステム上のほかのすべてのアプリケーションスレッドと計算時間のために競合するか計算時間を共有する、N 個の仮想 CPU スレッドを取得します。
カーネルゾーンは、専用 CPU リソース内の CPU の相当数 (CPU 数、コア数、ソケット数など) と等しい数の仮想 CPU スレッドを取得します。仮想 CPU スレッドは専用の計算リソースを独占し、同じ物理ホスト上で実行中のほかのアプリケーションスレッドと計算リソースを共有しません。
これは一般的な使用例ではありません。この場合、仮想 CPU スレッド数をオーバーライドできるので、その数は、専用 vCPU リソースの相当数と正確には一致しない可能性があります。多くの仮想 CPU が指定されても、それらの仮想 CPU は専用 CPU リソースを独占します。仮想 CPU 数が専用 CPU 数を超えることはできません。
専用 CPU リソースで範囲を使用することは、推奨されません。カーネルゾーンで作成される仮想 CPU の数は、カーネルゾーンのブート時に固定されます。ある ncpu 範囲を持つ専用 CPU のゾーンでは、CPU 数はその範囲内の任意の値になります。いくつかの CPU がゾーンの pset に自動的に追加されても、カーネルゾーンはそれらの CPU を使用できず、アイドル状態となります。CPU がゾーンの pset から自動的に削除されると、ゲストがきわめて過剰にコミットされた状態、つまり仮想 CPU が実際の CPU より格段に多い状態となり、パフォーマンスが低下します。
カーネルゾーンは、zoneadm suspend コマンドによって、ディスクに対して中断できます。ゾーンの実行状態がディスクに書き込まれます。これにはゾーンによって使用される RAM 全体が含まれるため、大量の時間と領域をとることがあります。
カーネルゾーンの構成に中断リソースがある場合のみ、カーネルゾーンの中断および再開がサポートされます。中断リソース内では、パスまたはストレージ (両方ではない) を指定する必要があります。path プロパティーは、中断イメージを格納するファイルの名前を指定します。ファイルを格納するディレクトリが存在し、root ユーザーによってディレクトリに書き込み可能である必要があります。svc:/system/zones:default の開始より前にマウントされるすべてのファイルシステムを使用できます。storage プロパティーには、中断イメージを格納するディスクデバイスのストレージ URI (suri(7) を参照) が指定されます。デバイス全体が使用されます。このデバイスは、ほかのものと共有できません。
中断イメージは、書き込み前に圧縮されます。したがって、中断イメージのサイズはゾーンの RAM のサイズよりも一般的に著しく小さくなっています。中断中に、中断イメージのサイズを示すメッセージが出力されてコンソールログに記録されます。
圧縮の後、中断イメージは AES-128-CCM を使用して暗号化されます。暗号化鍵は、/dev/random (random(4D) のマニュアルページを参照) によって自動的に生成され、keysource リソースの raw プロパティーに保管されます。
ゾーンが中断されている場合、zoneadm boot コマンドによって再開します。再開を希望しない場合は、boot –R オプションを使用して、最初からブートすることができます。
suspend イメージおよびゾーンのストレージの残りの部分が複数のホストから (通常は suspend:storage および device:storage プロパティーを使用して) アクセス可能な場合は、その中断イメージを使用すると、zoneadm(8) の zoneadm migrate コマンドによってウォーム移行をサポートできますが、移行の前には zoneadm shutdown の代わりに zoneadm suspend を使用します。これにより、再開にかかる時間を除き、目的のホストでのすべてのゾーン起動コストを回避します。
ウォーム移行では、ソースホストと宛先ホストの間の互換性をチェックしません。
ソースと目的のホストは同じプラットフォームである必要があります。x86 では、ベンダー (AMD/Intel) や CPU モデル名が一致している必要があります。SPARC では、ハードウェアプラットフォームが同じである必要があります。たとえば、T4 ホストから T5 ホストにウォーム移行することはできません。異なるハードウェアプラットフォーム間で移行する場合、cpu-arch プロパティーで移行クラスを適切に指定する必要があります。
SPARC プラットフォームで可能性のある移行クラスは次のとおりです。
カーネルゾーンは CPU タイプに依存しない移行を実行できますが、T4 よりも古いシステムに対しては実行できません。
カーネルゾーンは、SPARC T4、SPARC T5、SPARC M5、SPARC M6、SPARC M7、SPARC T7、および SPARC S7 の間で、CPU タイプ間移行を実行できます。
カーネルゾーンは、Fujitsu M10 と Fujitsu SPARC M12 の間で CPU タイプ間移行を実行できます。
値が設定されていない場合、カーネルゾーンの CPU 移行クラスはホストと同じです。これはホスト CPU クラスの互換性がある CPU タイプ間で移行できます。
カーネルゾーンの CPU 移行クラスは、ホストの CPU クラスの制限を超えることはできません。
また、パフォーマンスカウンタは cpu-arch が移行クラスに設定されている場合には使用できません。
Intel プラットフォームで、可能性のある移行クラスは次のとおりです。
カーネルゾーンは、Nehalem 以降のマイクロアーキテクチャーの CPU 間の CPU タイプ間移行を実行できます。このクラスによってサポートされている機能は、sse、sse2、sse3、sse4.1、sse4.2、ssse、cx8、cx16、pdcm、popcnt、fpu、pse、pse36、tsc、tscp、msr、pae、mce、sep、pge、cmov、clfsh、mmx、fxsr、htt、ss、ahf64、sysc、nx-bit、long-mode です。
カーネルゾーンは、Westmere 以降のマイクロアーキテクチャーの CPU 間の CPU タイプ間移行を実行できます。このクラスによってサポートされている機能は、migration-class1 によってサポートされているすべての機能と pclmulqdq、aes、1g-page です。
カーネルゾーンは、Sandy Bridge 以降のマイクロアーキテクチャーの CPU 間の CPU タイプ間移行を実行できます。このクラスによってサポートされている機能は、migration-class2 によってサポートされているすべての機能と xsave、avx です。
カーネルゾーンは、Ivy Bridge 以降のマイクロアーキテクチャーの CPU 間の CPU タイプ間移行を実行できます。このクラスによってサポートされている機能は、migration-class3 によってサポートされているすべての機能と f16c、rdrand、efs です。
カーネルゾーンは、Haswell 以降のマイクロアーキテクチャーの CPU 間の CPU タイプ間移行を実行できます。このクラスによってサポートされている機能は、migration-class4 によってサポートされているすべての機能と fma、movbe、bmi1、bmi2、avx2、lzcnt です。
カーネルゾーンは、Broadwell 以降のマイクロアーキテクチャーの CPU 間の CPU タイプ間移行を実行できます。このクラスによってサポートされている機能は、migration-class5 によってサポートされているすべての機能と rdseed、adx、prfchw です。
パフォーマンスカウンタは cpu-arch が移行クラスに設定されている場合には使用できません。使用できる CPU パフォーマンスカウンタは、ストランドまたはハイパースレッドに固有のものだけです。このため、busstat や daxstat など、ほかの種類のカウンタを参照する一部のコマンドは、カーネルゾーンでは動作しない可能性があります。
AMD CPU で使用できる移行クラスはありません。
値が設定されていない場合、カーネルゾーンは同じマイクロアーキテクチャー、またはマイクロアーキテクチャーを認識できない場合は正確に同じタイプの CPU 間で移行できます。
また、移行クラスのほかに、host-compatible プロパティーでホスト互換性レベルを指定して、ソースホストとターゲットホストで動作中の Oracle Solaris バージョンでサポートされているハードウェア機能が一致しているかどうかを確認することが必要な場合もあります。
再開時は、ゾーンの現在の構成を使用して、ブートおよび新規構成の指定が許可されます。ただし、再開するゾーンによって特定の設定が求められるため、制限事項があります。何らかの非互換性があると、ブートは失敗します。たとえば、ブートプロセスは次の場合に失敗することがあります。
CPU が異なる機能をサポートする (たとえば、cpuid(4D) を参照)
構成の capped-memory 値が異なる
構成で定義される仮想 CPU の数が異なる
ディスクが存在しない (適切な id プロパティーを持つ device リソースがない)
仮想 NIC が存在しない (適切な id プロパティーを持つ net または anet リソースがない)
ストレージの識別のための固有のチェックは実行されません。特定の ID の下に一覧表示されるデバイスを、ゾーンで表示が必要なデバイスにするのは管理者の責任です。
zoneadm(8) のマニュアルページで説明されているように、zoneadm migrate コマンドを使用して、カーネルゾーンを互換性のあるホストにコールド移行またはライブ移行できます。
ライブおよびコールド移行の場合は、次のサービスおよびパッケージを構成する必要があります。
ターゲットシステムとソースシステムの両方にパッケージ pkg://system/management/rad/module/rad-zonemgr がインストールされている必要があります。
zoneadm migrate コマンドで使用する RAD URI に応じて、インスタンス svc:/system/rad:local または svc:/system/rad:remote が有効になっている必要があります。
ソースシステム上でインスタンス svc:/system/rad:local が有効になっている必要があります。
特にライブ移行の場合のみ、宛先システム上でサービス svc:/network/kz-migr:stream が有効になっている必要があります。
ライブ移行には、上の「中断、再開、およびウォーム移行」セクションで説明されているのと同じ互換性の制限があります。
このブランドには、次の補助状態 (zoneadm list -is によって示される) が定義されています。
ゾーンは中断されており、次のブート時に再開されます。この状態を表示できるようにするには、ゾーンに接続している必要があります。
ゾーンは running 状態ですが、カーネルデバッガはゾーン内で実行しているため、ネットワークリクエストなどにサービスできません。ゾーンコンソールに接続して、デバッガと対話処理を行なってください (kmdb)。
ゾーンは running 状態ですが、ゾーンはパニックを起こしており、ホストは影響を受けません。
このゾーンは完全に実行されていますが、別のホストにライブ移行されています。
このゾーンはホスト上でブートされ、ライブ移行イメージを受信しているため、移行が完了するまでまだ完全には実行されていません。
このゾーンはシステムに認識されていますが、その構成がありません。ゾーンの状態は常に不完全です。
カーネルゾーンのブート可能な各デバイスには、ホストデータとして知られる状態情報が含まれています。このデータは、ゾーンが使用中の場所や、中断されているかどうか、およびその他の状態情報を追跡します。ホストデータは、中断イメージに使用されるのと同じ暗号化鍵を使用して、AES-128-CCM で暗号化および認証されます。
カーネルゾーンの準備ができたかブートされた場合、ホストデータが読み取られて、カーネルゾーンのブートストレージがほかのシステムで使用中かどうかが判別されます。別のシステムによって使用中の場合、カーネルゾーンは使用不可の状態に移行し、エラーメッセージによって、カーネルゾーンを使用中のシステムが示されます。ストレージがほかのシステムで使用中でないことがたしかな場合、カーネルゾーンは zoneadm attach の -x force-takeover extended オプションを使用して修復できます。このコマンドを実行する前に、次の警告を参照してください。
暗号化鍵にアクセスできない場合、ホストデータとすべての中断イメージを読み取ることはできません。そのような状況では、ゾーンを準備またはブートするすべての試行によって、ゾーンが使用不可状態に移行します。暗号化鍵を復元できない場合、zoneadm attach サブコマンドの -x initialize-hostdata extended オプションを使用して、新しい暗号化鍵およびホストデータを生成できます。このコマンドを実行する前に、次の警告を参照してください。
手動のウォームまたはコールド移行中の暗号化鍵の損失を防ぐには、ソースシステム上で zonecfg export を使用して、宛先システムで使用されるコマンドファイルを生成します。例:
root@host1# zonecfg -z myzone export -f /net/.../myzone.cfg root@host2# zonecfg -z myzone -f /net/.../myzone.cfg
この例の myzone.cfg には暗号化鍵が含まれているため、内容を開示しないように保護することが重要です。
solaris-kz ブランドゾーンは SYSsolaris-kz テンプレートを使用して構成できます。
次の zonecfg(8) リソースおよびプロパティーは、このブランドでサポートされていません。
anet:address capped-memory:locked capped-memory:swap dataset device:allow-partition device:allow-raw-io fs file-mac-profile fs-allowed ip-type limitpriv global-time max-lwps max-msg-ids max-processes max-sem-ids max-shm-memory rctl:zone.max-lofi rctl:zone.max-swap rctl:zone.max-locked-memory rctl:zone.max-shm-memory rctl:zone.max-shm-ids rctl:zone.max-sem-ids rctl:zone.max-msg-ids rctl:zone.max-processes rctl:zone.max-lwps rootzpool zpool
次の zonecfg(8) リソースおよびプロパティーは、このブランドのライブゾーン再構成によってサポートされています。
anet (with exceptions stated below) device ib-vhca ib-vhca:port net (with exceptions stated below) virtual-cpu
次の zonecfg(8) リソースおよびプロパティーは、このブランドのライブゾーン再構成によってサポートされていません。
anet:allowed-address anet:configure-allowed-address anet:defrouter anet:evs anet:vport capped-cpu (zone.cpu-cap) capped-memory cpu-shares (zone.cpu-shares) dedicated-cpu hostid keysource net:allowed-address net:configure-allowed-address net:defrouter pool rctl scheduling-class cpu-arch tenant host-compatible
永続的な構成に一覧表示されているサポートされないリソースおよびプロパティーが、実行中のゾーンに適用された場合、そのリソースおよびプロパティーに加えたあらゆる変更は、ライブゾーン再構成によって無視されます。
ライブ構成に一覧表示されているサポートされないリソースおよびプロパティーを変更するあらゆる試行は拒否されます。
virtual-cpu のライブ再構成は、その最初の一時停止まで、仮想 NUMA トポロジを使用したカーネルゾーンに対して有効にされます。virtual-cpu を再開すると、その次のリブートまで、そのようなカーネルゾーンのライブ再構成は無効になります。仮想 NUMA トポロジを使用しないカーネルゾーンはこの制限によって影響を受けません。
solaris-kz ブランドでサポートされている anet および net プロパティーは、同じメディアタイプに対して変更する必要があります。
次に一覧表示されているように、solaris-kz ブランドについてサポートされているプロパティーの固有のデフォルト値があります。
Resource Property Default Value
global zonepath /system/zones/%{zonename}
autoboot false
ip-type exclusive
auto-shutdown shutdown
net configure-allowed-address true
anet mac-address auto
lower-link auto
link-protection mac-nospoof
linkmode cm
anet:mac mac-address auto
ib-vhca smi-enabled off
ib-vhca:port pkey auto
次の solaris-kz ブランド固有のサブコマンドオプションは、zoneadm(8) によってサポートされています。
指定された solaris-kz ブランドゾーンイメージをゾーンにアタッチします。ゾーンのブート可能デバイスは、すでに正しく入力されているものとします。
-c config_profile.xml | dir オプションは、適用するプロファイルまたはプロファイルのディレクトリを提供します。詳細は、sysconfig(8) のマニュアルページを参照してください。
すべてのプロファイルは、.xml 拡張子を持つ必要があります。デフォルトでは、プロファイルは sysconfig-profile smf レイヤーにインストールされます。プロファイルファイルが enterprise、site、または node という名前の dir のサブディレクトリ内に存在する場合、そのプロファイルは enterprise-profile、site-profile、または node-profile レイヤーで適用されます。その他のすべてのプロファイルは、sysconfig-profile レイヤーで適用されます。詳細は、smf(7) のマニュアルページを参照してください。
拡張オプション -x force-takeover は、ゾーンが別のシステム上にインストールされているか、または実行中であることを示す状態情報をクリアします。このオプションは注意して使用してください。同一のストレージがゾーンの 2 つのインスタンスによって同時に使用される場合、ファイルシステムが破壊されます。
拡張オプション -x initialize-hostdata は、暗号化鍵およびホストデータを再初期化します。-x force-takeover と同様、このオプションを使用する前に、ゾーンが別のシステムで使用されていないことを確認してください。
このオプションは、使用中のチェックを無効にするほかに、格納されているデータ (ゾーンの時刻など) をリセットします。これは、暗号化鍵が失われたときの回復のためにのみ使用するようにしてください。
ゾーンが中断されている場合、-R オプションは、中断されたイメージを無視し (次に削除される)、新規にブートするために使用できます。
diskn オプションは、ブートローダーに特定のディスクからブートするように伝えます。zonecfg のデバイス ID は 0 から始まりますが、diskn の n はシステムから見たディスクの数で、1 から始まります。diskn の n は、zonecfg のデバイス ID + 1 になります。zonecfg のデバイス 0 からブートするには、次を実行する必要があります。
zoneadm -z zonename boot -- disk1
disk0 ではありません。
–L オプションはブートローダーに使用可能なブート環境を一覧表示するように伝えます。ブートする BE は対話的に選択できます。
–Z オプションは、ブートローダーに特定の BE をブートするように伝えます。
リポジトリからのインストール後に適用するプロファイルまたはプロファイルのディレクトリを指定します。
すべてのプロファイルは、.xml 拡張子を持つ必要があります。デフォルトでは、プロファイルは sysconfig-profile smf レイヤーにインストールされます。プロファイルファイルが enterprise、site、または node という名前の dir のサブディレクトリ内に存在する場合、そのプロファイルは enterprise-profile、site-profile、または node-profile レイヤーで適用されます。その他のすべてのプロファイルは、sysconfig-profile レイヤーで適用されます。詳細は、smf(7) のマニュアルページを参照してください。
zoneadm clone について、ストレージが自動的に作成される場合、ストレージはソースゾーンのディスクと同じサイズで作成されます。
インストール後に少なくとも 1 回完全にブートされたカーネルゾーンのみが、サポートされます。ゾーンのすべてのパブリッシャーにゾーン内からアクセスできる必要があります。
カーネルゾーンは、大域ゾーンのパブリッシャーとデフォルトの AI マニフェスト、カスタム AI マニフェスト、Solaris インストールメディアの ISO イメージ、または統合アーカイブを使用してインストールできます。
–a、–b、または –m オプションを使用しない場合、デフォルトの AI マニフェスト (/usr/share/auto_install/manifest/default.xml) および大域ゾーンの pkg パブリッシャーが、インストールを実行するために使用されます。サポートされるメディアのタイプは、テキストインストーラおよび自動インストーラです。これによりサポートされる任意の Oracle Solaris バージョンをインストールできます。カーネルゾーンでサポートされる最初の Solaris バージョンは、Oracle Solaris 11.2 です。
AI マニフェストを –m オプションとともに指定した場合、AI マニフェストの内容に基づいて、IPS または統合アーカイブのインストールが実行されます。ai_manifest(5) を参照してください。
ブート可能な Oracle Solaris インストールメディアの ISO イメージが –b オプションとともに指定された場合、カーネルゾーンはインストールメディアからブートされ、インストールプログラムはゾーンのコンソールで実行されます。インストール中にコンソールのログインセッションが確立され、インストールプログラムの操作および監視を行うことができます。
統合アーカイブが –a オプションとともに指定された場合、インストールは統合アーカイブから実行されます。統合アーカイブに複数のゾーンが含まれている (archiveadm info の出力の配備可能システム) 場合は、インストールするアーカイブゾーンを指定するために、–z オプションを使用します。統合アーカイブは、archiveadm(8) で作成されます。
指定された統合アーカイブからインストールします。archived_zone には、大域ゾーン、カーネルゾーン、または solaris ブランドゾーンを指定できます。アーカイブされたゾーンが solaris ブランドゾーンである場合は、非大域から大域への pkg のイメージ変換が実行されます。変換を正常に実行するには、すべての pkg パブリッシャーにアクセスできるように、ゾーンのインストール環境に十分なネットワークアクセス権限がある必要があります。これをもっとも簡単に実現するには、カーネルゾーンのネットワークを DHCP を使用して構成することを許可します。
指定されたメディアからブートし、インストールします。
リポジトリからのインストール後に適用するプロファイルまたはプロファイルのディレクトリを指定します。
すべてのプロファイルは、.xml 拡張子を持つ必要があります。デフォルトでは、プロファイルは sysconfig-profile smf レイヤーにインストールされます。プロファイルファイルが enterprise、site、または node という名前の dir のサブディレクトリ内に存在する場合、そのプロファイルは enterprise-profile、site-profile、または node-profile レイヤーで適用されます。その他のすべてのプロファイルは、sysconfig-profile レイヤーで適用されます。詳細は、smf(7) のマニュアルページを参照してください。
インストールを実行する AI メディアでブートするときに、適用するプロファイルまたはプロファイルのディレクトリをインストール環境に提供します。
すべてのプロファイルは、.xml 拡張子を持つ必要があります。
Automated Installer に対して指定されるマニフェストファイル。
ルートファイルシステムのサイズを明示的に設定します (デフォルトは 16g)。このサイズは、「t」、「g」、「m」、「k」、「b」などの文字を末尾に付けて指定することもできますし、バイトであることを示すために末尾に文字を付けないで指定することもできます。最大サイズは rpool の空き領域に依存します。
インストール後にカーネルゾーンをコンソールにログインしたままにして、インストールシステムとの対話を可能にします。このオプションは、–a または –b オプションとともに使用した場合にのみ有効です。
https URI にある統合アーカイブからインストールする場合に、指定された証明書、CA 証明書、または鍵を使用します。–a オプションでのみ有効です。
インストールプロセスの詳細情報を出力します。
統合アーカイブから archived_zone を使用してゾーンをインストールします。特定の統合アーカイブで有効な値のリストについては、archiveadm(8) info コマンドの出力にある「Deployable Systems」を参照してください。–a オプションでのみ有効です。
指定された cipher を使用して、メモリー転送を暗号化します。値「none」は暗号化を無効にします。値「list」は、サポートされている暗号をリストする場合に使用できます。指定されていない場合、cipher は、ソースと宛先の機能に基づいて自動的に選択されます。
実行する移行のタイプを指定します。ライブ移行が指定されている場合は、実行中のゾーンの移行のみがサポートされます。auto が選択されている場合、ゾーンはインストール済みゾーンに対してコールド移行され、実行中のゾーンに対してライブ移行されます。タイプが指定されていない場合、デフォルトは auto です。
# zoneadm -z myzone boot -- -Z rpool/ROOT/solaris使用例 2 代替ブートデバイスからのブート
# zoneadm -z myzone halt # zoneadm -z myzone boot -- disk2
VirtualBox はカーネルゾーンと同じホストで使用できますが、適切に構成されている必要があります。詳細は VirtualBox のドキュメントを参照してください。カーネルゾーンは別の Oracle Solaris カーネル環境で実行されているため、クラッシュして、ベアメタルで実行されている大域ゾーン内のカーネルの場合と同じコアをダンプする可能性があります。このような場合、ダンプはカーネルゾーンのストレージに保存され、dumpadm(8) によって構成されたクラッシュダンプパラメータに従って、すべての Oracle Solaris クラッシュダンプが存在するのと同じ場所に存在します。カーネルゾーンにはまた、zoneadm savecore サブコマンドを使用して、ホスト環境からコアダンプが生成されるようにする機能もあります。さらに、カーネルゾーンがクラッシュし、コアイメージをダンプしようとしたが、コアをカーネルゾーンのストレージ内に正常に保存できない場合は、zoneadm savecore サブコマンドが発行されたかのように、ホストにコアイメージの保存を試みるよう要求します。このコアは、coreadm(8) によって指定された場所に保存されます。これは、coreadm(8) がカーネルゾーンのコアダンプのための場所を構成し、かつそれを有効にしている場合にのみ成功します。