ドメインはハードウェアによるパーティショニング方式です。ですから、パーティショニングはハードウェアレベルで行われます。Solarisゾーンは、Solarisコンテナ・テクノロジの一部です。そのようなものとして、ゾーンはコンテナに対する名前空間の分離（例えば独立したIPアドレス、ユーザなど）を管理します。コンテナ及びゾーンは、OSによる仮想化方式です。ハードウェアレベルではパーティショニングは行われず、正しくはOS内部で行われます。

そうでもありません。Solaris 10コンテナの正式な定義は、リソース管理機能を利用するSolarisゾーンです。しかし普段の会話では、ゾーンとコンテナを区別する人はほとんどいません。

Solarisコンテナは、大きく分けて、SolarisゾーンとSRM（Solaris Resource Manager）の2つの要素で構成されています。SRMは、各コンテナが受けている物理的なシステムリソースを管理し、Solarisゾーンは名前空間の分離を管理します。これら2つが合わせらて、Solarisコンテナの基礎が形成されます。

LPARは、ハードウェアとOSの間にハイパーバイザ層がある典型的な仮想マシン技術です。これに対し、SolarisコンテナはOSによる仮想化技術です。仮想ドメイン及び仮想マシンでは、同じ物理マシン上で様々なOSを同時に実行できます。しかし、あらゆる仮想マシン技術がそうであるように、この方式では、パフォーマンスに大きなオーバーヘッドがあります。これに対し、Solarisコンテナは非常に軽量で、ほとんどパフォーマンス上のオーバーヘッドがありません。ただし、1つのコンテナで実行できるのは1つのバージョンのOSだけです。

Solarisコンテナには、多くの利点があります。例えば、OSのライセンスコスト、サポートコストが軽減され、きめの細かい対応ができることからハードウェアコストの節減にもなります。また、管理作業の負荷軽減、アプリケーションの可用性向上にもなります。

コンテナは、厳格なセキュリティ管理及びリソース管理機能を持つ、分離された複数の作業負荷環境を提供します。OSイメージは1つだけですから、非常に効率的であり、細かな管理作業が不要になります。VMwareは、いくつかの種類のOS（Linux、Solaris、Windows）を選択して、同時に複数のOSイメージをホスティングできます。しかし、あらゆる仮想マシンがそうであるように、VMwareには、パフォーマンス面のデメリットがあります。また、他の仮想マシン技術同様、OSイメージをそれぞれ独立して管理する必要があります。

可能です。Solarisコンテナは、任意のSolaris 10インスタンス内で動作します。ですから、実際の環境おいて、仮想マシン内でOSによる仮想化を実現することのメリットを評価できます。

ゾーンは、大域ゾーンと非大域ゾーンの2種類あります。「非グローバル」ゾーンは、「ローカル」ゾーンの正式名です。1つの大域ゾーンには、完全に機能し、システムハードウェアが起動可能なSolaris OSインスタンス1つが含まれます。このため、Solaris OSインスタンスがシステムハードウェアによって起動されると、それが大域ゾーンになります。動作する大域ゾーンは、1つのシステムで1つだけです。大域ゾーンを起動したら、Zonecfg（1M）及びZoneadm（1M）を使って非大域ゾーンを作成します。あらゆる非大域ゾーンのインストール、保守、操作、及び破壊は、大域ゾーンによって制御されます。

1台のサーバが処理可能なゾーンの最大数は、使用可能なメモリ容量とディスク容量によって制限されます。ゾーンの構成によって異なりますが、1つのゾーンで150Mバイトから3Gバイトのディスク容量が占有されます。また、システムプロセス用に多少のメモリも占有します。とはいえ、ゾーンの管理はシステムの管理に非常によく似ています。1つのコマンドで全てのゾーンのパッチあるいはバックアップを行えますから、管理のしやすさの点ではゾーンの方が簡単です。

SolarisゾーンはCPUを共有します。管理者はSolaris 動的資源プールを使い、1つのSolarisゾーンに1つないし複数のCPUを割り当てることができます。Solaris 公平配分スケジューラにより、特定のSolarisゾーンに、事前に決められた最小処理パワーが割り当てられるようにすることもできます。加えて、Solaris 公平配分スケジューラは、CPUパワーが浪費されないようにする上でも役立ちます。システムの利用率が100%に達しない限り、処理リソースが制約を受けることはありません。RAMについていえば、Solarisゾーンはシステムで使用可能な量の物理メモリを共有します。現状では1つのゾーンが使用する物理メモリ量を制限することはできませんが、サンではこの問題に取り組んでいて、ほどなく解決する予定です。

リソース管理によるコンテナへの割り当ては、コンテナを再起動することなくいつでも変更できます。リソースの割り当てと分離については、Sun BluePrints（英語）の詳細な情報で確認できます。

コンテナが少数の場合、オーバーヘッドはほとんど測定できません。1%にもならないことは確かです。数百のゾーンからなる非常に大きな構成では4%ほどで、やはり相対的に非常に小さなオーバーヘッドです。

1つ目の質問については、複数のゾーンで同じアプリケーションインスタンスを共有できます。しかし、そうするかどうかの決定は、全てのゾーンがアクセスできるディレクトリ（例えばApacheで/usrなど）にアプリケーションをインストールするかどうかによります。そうしない場合、Solarisゾーンのそれぞれに専用のものが必要です。2つ目の質問については、あらゆるゾーン内の各アプリケーションは、互いに完全に分離された専用のインスタンス（とプロセス）を持ちます。サンがSolarisゾーンをそのように構築した根本的な理由は、分離にあります。

パッチについては、patchad（1M）やSun BigAdminポータルサイト（英語）で、詳しく解説しています。要約すると、大域ゾーンから全てのゾーンにパッチを適用することも、あるいは大域ゾーンまたは非大域ゾーンのどちらからでも個別にゾーンにパッチを適用することもできます。

いいえ。大域ゾーンにパッチを適用するときに非大域ゾーンを停止する必要はありません。ただし、カーネルパッチが含まれる場合、パッチを有効にするには、大域ゾーンの再起動が必要になります。大域ゾーンが再起動すると、非大域ゾーンが全て停止させられます。

カーネルのパニックが起きた場合は、一緒に全てのゾーンが停止します。これは、1つのカーネルインスタンスで全てのゾーンをサポートしているためです。しかし、通常の環境では、他に影響を与えることなく、ゾーンは個々に停止することができます。1つのゾーンがクラッシュしても、他のゾーンはその影響を受けません。

Solaris Container ManagerというSun Management Center（Sun MC）のアドオンがあり、これがコンテナ管理用のGUIです。

可能です。複数のデータベースインスタンスがそれぞれ独立したマシンにあるかのように、OracleデータベースとSolarisコンテナを自由に組み合わせることができます。また、コンテナは、共有メモリがそれぞれ異なるマシンのメモリであるかのように分離します。これについては、BigAdminに詳しい情報があります。

サンでは、個々のSolarisコンテナに割り当てられる資源プールに基づくライセンスにするよう、データベースベンダに推奨しています。これまでのところ、Oracleがこのライセンス方針をすでに採用しています。

Sun Fire T2000サーバでは、スレッド1つがCPU（仮想CPU）1つになります。ですから、Solaris Resource Managerはスレッド単位でセットを作成できます。つまり、その例では、16個あるスレッドの全てを割り当てられることを意味します。

コンテナは、Solaris 10をサポートするのであれば、ラップトップからハイエンドサーバまで、あらゆるシステムにインストールできます。

はい、あります。Solaris Ready Test Suiteをダウンロードし、Solarisの適格性検査ツールにアクセスすることもできます。このツールセットに、非大域ゾーンでは使用できない権限とデバイスノードをチェックするためのDTraceスクリプトと、非大域ゾーン対応APIの使用を検査するためのソース走査ツールがあります。