Oracle VM Command Line Interface（OracleVM CLI）が
使用できるようになりました。
これは、OVMM に SSH で接続することで使用できます。
- アクセスするときのアドレス（ホスト名/IPアドレス）は OVMM のもの。
- デフォルトのポート番号は、TCP の10000番。
- ユーザ/パスワードは、OVMM のもの（adminなど）でログインする。
Linux のユーザアカウントではない。
2013年3月30日土曜日
Oracle VM CLI にアクセスしてみる。
Oracle VM Manager 3.2.1（OVMM） から、
Oracle VM Command Line Interface（OracleVM CLI）が
使用できるようになりました。
これは、OVMM に SSH で接続することで使用できます。
Oracle VM Command Line Interface（OracleVM CLI）が
使用できるようになりました。
これは、OVMM に SSH で接続することで使用できます。
2013年3月29日金曜日
Oracle VM 3 テンプレートからVMを複数作成してみる。
今回は、単純に
テンプレートから複数のVMをクローン作成してみます。
Oracle VM では、VMをクローニングするときに「いくつ複製するか」 を指定することができます。
その場合、複製されるVMの名前の末尾には、自動的に数字が付与されます。
テンプレートからのクローン作成
リポジトリの「VM Templates」でテンプレートを選択して
「Clone or Move Template」 ボタンをクリックします。
「Create a clone of this Template」 を選択します。
「Clone Count」 で いくつVMをクローニングするか指定します。
今回は、一度に 3つのクローンを作成してみます。
「Clone Name」を指定します。
ここで指定したVM名（今回は 「ovmgst」）をもとに、「VM名.数値」というVMが作成されます。
VMの作成先には、Oracle VM Server ではなく、サーバプールを指定します。
クローニングが開始されると、
ジョブサマリー（画面の下の方）に進捗が表示されます。
VMは指定通り3つ、「ovmgst.0」、「ovmgst.1」、「ovmgst.2」として作成されました。
数値は1ではなく、0から付与されます。
この名前は、ゲストOSのホスト名とは別に設定されている、
Oracle VM Managerの表示名です。
変更したい場合は、クローン後に「Servers and VMs」から編集できます。
複製されたVMの仮想ディスクには、
もとにしたVMテンプレートの仮想ディスク名に「(2)」などの数値が自動付加されます。
例では、テンプレートの持っていた仮想ディスクが「oel59-base02-disk1」という名前だったので
「oel59-base02-disk1(2)」～「oel59-base02-disk1(4)」という名前で複製されています。
仮想ディスク名前を変更したい場合は、「Virtual Disks」（下の画面）で
クローン後に一つずつ、変更します。
以上、VMの複数クローン作成でした。
テンプレートから複数のVMをクローン作成してみます。
Oracle VM では、VMをクローニングするときに「いくつ複製するか」 を指定することができます。
その場合、複製されるVMの名前の末尾には、自動的に数字が付与されます。
テンプレートからのクローン作成
リポジトリの「VM Templates」でテンプレートを選択して
「Clone or Move Template」 ボタンをクリックします。
「Create a clone of this Template」 を選択します。
「Clone Count」 で いくつVMをクローニングするか指定します。
今回は、一度に 3つのクローンを作成してみます。
「Clone Name」を指定します。
ここで指定したVM名（今回は 「ovmgst」）をもとに、「VM名.数値」というVMが作成されます。
VMの作成先には、Oracle VM Server ではなく、サーバプールを指定します。
クローニングが開始されると、
ジョブサマリー（画面の下の方）に進捗が表示されます。
VMは指定通り3つ、「ovmgst.0」、「ovmgst.1」、「ovmgst.2」として作成されました。
数値は1ではなく、0から付与されます。
この名前は、ゲストOSのホスト名とは別に設定されている、
Oracle VM Managerの表示名です。
変更したい場合は、クローン後に「Servers and VMs」から編集できます。
複製されたVMの仮想ディスクには、
もとにしたVMテンプレートの仮想ディスク名に「(2)」などの数値が自動付加されます。
例では、テンプレートの持っていた仮想ディスクが「oel59-base02-disk1」という名前だったので
「oel59-base02-disk1(2)」～「oel59-base02-disk1(4)」という名前で複製されています。
仮想ディスク名前を変更したい場合は、「Virtual Disks」（下の画面）で
クローン後に一つずつ、変更します。
以上、VMの複数クローン作成でした。
2013年3月27日水曜日
Oracle VM 3 のクローン・カスタマイザを使用したVMテンプレートクローン実行。
今回は、Oracle VM 3 のクローン・カスタマイザを使用して
VMテンプレートをクローニングしてみます。
VMテンプレートのクローンを実行
記憶域リポジトリで 「VM Templates」 を開き、
クローンしたいテンプレートを選択して、「Clone or Move Template」ボタンをクリックします。
「Create a clone of this Template」 を選択して、Next。
下記の画面では、まず 「Clone to a:」で 「Template」 を選択します。
新しく作成する VMテンプレート名（下記では 「oel59-64bit-base02」）と、
Target Server Pool （クローン先のサーバプール。下記では 「pool_cluster1」）を指定します。
クローン・カスタマイザを使用するには、ここで「Advanced Clone」にチェックを入れます。
「Clone Customizer:」 欄で、あらかじめ作成したクローン・カスタマイザを指定します。
一番下にある「Target Repository:」で指定するリポジトリ（下記では 「repo_nfs_237_L」）には
仮想マシン設定ファイル（vm.cfg）が作成されるだけで、
仮想ディスク（OSイメージを含む）のクローン先リポジトリは、
クローン・カスタマイザ（下記では 「clone-vlan00404-repo237L」）を選択することで指定します。
※「Create」をクリックして、この場でカスタマイザを作成することもできそうですが、
なぜかリポジトリ指定ができなかったので、
カスタマイザはあらかじめ作成しておいた方がよさそうです。
そしてクローン処理が始まるので、完了するをの待ちます。
処理が終了すると、指定した記憶域リポジトリに、
VMテンプレート と 仮想ディスク の両方が作成されます。
下の例では、記憶域リポジトリ「repo_nfs_237_L」に、
VMテンプレート「oel59-64bit-base02」 と仮想ディスク「oel59-base01-disk1 (2)」 両方が
作成されたことが確認できます。
ちなみに、仮想ディスクは、自動的に 「元の名前 (n)」 といった名前になりますが、
作成された後に変更することが可能です。
以上、クローン・カスタマイザを使用したVMテンプレートのクローニングでした。
VMテンプレートをクローニングしてみます。
（こちらもどうぞ）
VMテンプレートのクローンを実行
記憶域リポジトリで 「VM Templates」 を開き、
クローンしたいテンプレートを選択して、「Clone or Move Template」ボタンをクリックします。
「Create a clone of this Template」 を選択して、Next。
下記の画面では、まず 「Clone to a:」で 「Template」 を選択します。
新しく作成する VMテンプレート名（下記では 「oel59-64bit-base02」）と、
Target Server Pool （クローン先のサーバプール。下記では 「pool_cluster1」）を指定します。
クローン・カスタマイザを使用するには、ここで「Advanced Clone」にチェックを入れます。
「Clone Customizer:」 欄で、あらかじめ作成したクローン・カスタマイザを指定します。
一番下にある「Target Repository:」で指定するリポジトリ（下記では 「repo_nfs_237_L」）には
仮想マシン設定ファイル（vm.cfg）が作成されるだけで、
仮想ディスク（OSイメージを含む）のクローン先リポジトリは、
クローン・カスタマイザ（下記では 「clone-vlan00404-repo237L」）を選択することで指定します。
※「Create」をクリックして、この場でカスタマイザを作成することもできそうですが、
なぜかリポジトリ指定ができなかったので、
カスタマイザはあらかじめ作成しておいた方がよさそうです。
そしてクローン処理が始まるので、完了するをの待ちます。
処理が終了すると、指定した記憶域リポジトリに、
VMテンプレート と 仮想ディスク の両方が作成されます。
下の例では、記憶域リポジトリ「repo_nfs_237_L」に、
VMテンプレート「oel59-64bit-base02」 と仮想ディスク「oel59-base01-disk1 (2)」 両方が
作成されたことが確認できます。
ちなみに、仮想ディスクは、自動的に 「元の名前 (n)」 といった名前になりますが、
作成された後に変更することが可能です。
以上、クローン・カスタマイザを使用したVMテンプレートのクローニングでした。
2013年3月26日火曜日
Oracle VM 3 のクローン・カスタマイザ作成
今回は、Oracle VM 3 のクローン・カスタマイザを使ってみます。
Oracle VM 3では、VMやVMテンプレートを複製するとき、
VMのストレージとネットワーク接続を「クローン・カスタマイザ」で制御します。
1. クローンカスタマイザの作成
まず、記憶域リポジトリ の「VM Templates」で、クローン・カスタマイザを作成する
VMテンプレートを指定し、作成ボタンをクリックします。
「＋」ボタンをクリックします。
クローン・カスタマイザにつける名前を入力します。
カスタマイザは、ネットワークとリポジトリを指定できるので、
両方をとって今回は「 clone-vlan0004-repo237L 」と名前を付けました。
VMテンプレートの仮想ディスクを、どの記憶リポジトリに、
どのようなディスク形式でクローンするか指定します。
Clone Type は、「Sparse Copy」という、使用した分だけ
容量を確保する形式にしました。
最初に全容量を確保する「Non-Sparse Copy」（非スパースファイル）も指定できます。
★なぜか、この画面では 記憶域リポジトリを指定できません。
そのため、一度カスタマイザを作成した後でリポジトリを指定しなおします。
テンプレートの仮想NICごとに、
接続するネットワーク（仮想スイッチのようなもの）を指定します。
ここでは、あらかじめ作成してあるネットワークが表示されるので
今回は、「VLAN-0004」というネットワークを指定しました。
2. クローン・カスタマイザの設定変更（記憶域リポジトリの指定）
これでクローン・カスタマイザは作成されましたが、
記憶域リポジトリを指定しなおすために、もう一度カスタマイザを編集します。
カスタマイザ作成時の画面と違い、
記憶域リポジトリを指定するためのボタン（虫メガネ）が表示されています。
このクローン・カスタマイザを使用した時に
クローン先として指定する、記憶域リポジトリを指定します。
記憶域リポジトリが指定できました。
「OK」をクリックすると、設定変更が完了します。
クローン・カスタマイザの記憶域リポジトリ指定が変更できました。
ちなみに、Windows7 の IE9 では、なぜか記憶域リポジトリが指定でなかったので
Oracle VM Managerの操作には、Firefox (19.0.2)を使用しました。
以上、クローン・カスタマイザの作成でした。
Oracle VM 3では、VMやVMテンプレートを複製するとき、
VMのストレージとネットワーク接続を「クローン・カスタマイザ」で制御します。
（こちらもどうぞ）
Oracle VM 3 のVMとVMテンプレートのクローンについて
クローン・カスタマイザは
VMやVMテンプレートにひもづけて作成します。
クローン・カスタマイザ を作成してみます。
1. クローンカスタマイザの作成
まず、記憶域リポジトリ の「VM Templates」で、クローン・カスタマイザを作成する
VMテンプレートを指定し、作成ボタンをクリックします。
「＋」ボタンをクリックします。
クローン・カスタマイザにつける名前を入力します。
カスタマイザは、ネットワークとリポジトリを指定できるので、
両方をとって今回は「 clone-vlan0004-repo237L 」と名前を付けました。
VMテンプレートの仮想ディスクを、どの記憶リポジトリに、
どのようなディスク形式でクローンするか指定します。
Clone Type は、「Sparse Copy」という、使用した分だけ
容量を確保する形式にしました。
最初に全容量を確保する「Non-Sparse Copy」（非スパースファイル）も指定できます。
★なぜか、この画面では 記憶域リポジトリを指定できません。
そのため、一度カスタマイザを作成した後でリポジトリを指定しなおします。
テンプレートの仮想NICごとに、
接続するネットワーク（仮想スイッチのようなもの）を指定します。
ここでは、あらかじめ作成してあるネットワークが表示されるので
今回は、「VLAN-0004」というネットワークを指定しました。
2. クローン・カスタマイザの設定変更（記憶域リポジトリの指定）
これでクローン・カスタマイザは作成されましたが、
記憶域リポジトリを指定しなおすために、もう一度カスタマイザを編集します。
カスタマイザ作成時の画面と違い、
記憶域リポジトリを指定するためのボタン（虫メガネ）が表示されています。
このクローン・カスタマイザを使用した時に
クローン先として指定する、記憶域リポジトリを指定します。
記憶域リポジトリが指定できました。
「OK」をクリックすると、設定変更が完了します。
クローン・カスタマイザの記憶域リポジトリ指定が変更できました。
ちなみに、Windows7 の IE9 では、なぜか記憶域リポジトリが指定でなかったので
Oracle VM Managerの操作には、Firefox (19.0.2)を使用しました。
以上、クローン・カスタマイザの作成でした。
2013年3月25日月曜日
Oracle VM 3 のVMとVMテンプレートのクローンについて
今回は、Oracle VM 3（OVM3） でのVM/VMテンプレートクローンの話です。
Oracle VM Manager 3 （OVMM 3）で
記憶域リポジトリをまたいでVMやVMテンプレートをクローニングするときは、
「クローン・カスタマイザ（Clone Customizer）」 を使用する必要があります。
今回はVMテンプレートのクローンを例とします。
Oracle VM のテンプレートの実体は、VM設定ファイル と 仮想ディスク から構成されます。
たとえば、下記のような環境があるとします。
Oracle VM Server（OVS）に対して、2つの記憶域リポジトリが割り当ててあります。
この時、単純にクローンすると、
VMの設定ファイルは指定したリポジトリ（Repo2）に作成されますが、
仮想ディスクはクローン元とおなじリポジトリに作成されてしまいます。
このような、別の記憶域リポジトリにクローンしたい場合は、
仮想ディスクのクローン先を、クローン・カスタマイザ で指定します。
この クローン・カスタマイザ では、クローンするVM（テンプレート）の
これを使用することで、VM設定ファイル と、仮想ディスク の両方を
意図した記憶域リポジトリに移動することができます。
カスタマイザでは、仮想ディスクファイルごとに、
クローン先の記憶域リポジトリを指定することができます。
以上、VM（VMテンプレート）のクローンについてでした。（たぶん続く）
Oracle VM Manager 3 （OVMM 3）で
記憶域リポジトリをまたいでVMやVMテンプレートをクローニングするときは、
「クローン・カスタマイザ（Clone Customizer）」 を使用する必要があります。
今回はVMテンプレートのクローンを例とします。
Oracle VM のテンプレートの実体は、VM設定ファイル と 仮想ディスク から構成されます。
たとえば、下記のような環境があるとします。
Oracle VM Server（OVS）に対して、2つの記憶域リポジトリが割り当ててあります。
- NFS記憶域リポジトリ1 → Repo1
- NFS記憶域リポジトリ2 → Repo2
この時、単純にクローンすると、
VMの設定ファイルは指定したリポジトリ（Repo2）に作成されますが、
仮想ディスクはクローン元とおなじリポジトリに作成されてしまいます。
- VM設定ファイル（vm.cfg） → Repo2 にクローンされる。
- 仮想ディスク → もともと配置されている Repo1 にクローンされてしまう。
このような、別の記憶域リポジトリにクローンしたい場合は、
仮想ディスクのクローン先を、クローン・カスタマイザ で指定します。
この クローン・カスタマイザ では、クローンするVM（テンプレート）の
- 仮想ディスクの配置先（記憶域リポジトリ）
- 仮想NICを接続する仮想ネットワーク
これを使用することで、VM設定ファイル と、仮想ディスク の両方を
意図した記憶域リポジトリに移動することができます。
カスタマイザでは、仮想ディスクファイルごとに、
クローン先の記憶域リポジトリを指定することができます。
以上、VM（VMテンプレート）のクローンについてでした。（たぶん続く）
2013年3月24日日曜日
Oracle VM 3 のNFSストレージ管理について。
今回は、Oracle VM 3（OVM3）でのストレージ管理の話です。
Oracle VM Manager（OVMM）では、
Oracle VM Server（OVS）が使用するストレージを
記憶域リポジトリ等を作成する前に登録しておく必要があります。
そのときに、ストレージごとに「ストレージの管理サーバ（Admin Servers）」を登録する必要があります。
下のスクリーンショットでは、「nfs_oel_236」 というNFSサーバに対して
「ovs321-2」 というOVSを管理サーバとして指定しています。
OVSの担当する「ユーティリティ サーバ」と呼ばれる役割とは別のものです。
この「管理サーバ」とは、
OVMMでストレージに対して管理操作（記憶域リポジトリ作成など）をするときに
そのストレージにに対して実際に処理をするOVSです。
管理サーバは、サーバプールをまたいでも指定できるので、
たとえば「どれが管理サーバだっけ」といった混乱を避けるために
管理サーバ用サーバプールを作ったりもできそうです。
「OVMM → ストレージ管理OVS」と「ストレージ管理OVS → ストレージ」の
接続経路をちゃんと確保しておく必要があるので
NW構成変更をするときには注意が必要です。
以上、OVM3のストレージ管理サーバの話でした。
Oracle VM Manager（OVMM）では、
Oracle VM Server（OVS）が使用するストレージを
記憶域リポジトリ等を作成する前に登録しておく必要があります。
そのときに、ストレージごとに「ストレージの管理サーバ（Admin Servers）」を登録する必要があります。
下のスクリーンショットでは、「nfs_oel_236」 というNFSサーバに対して
「ovs321-2」 というOVSを管理サーバとして指定しています。
OVSの担当する「ユーティリティ サーバ」と呼ばれる役割とは別のものです。
この「管理サーバ」とは、
OVMMでストレージに対して管理操作（記憶域リポジトリ作成など）をするときに
そのストレージにに対して実際に処理をするOVSです。
管理サーバは、サーバプールをまたいでも指定できるので、
たとえば「どれが管理サーバだっけ」といった混乱を避けるために
管理サーバ用サーバプールを作ったりもできそうです。
「OVMM → ストレージ管理OVS」と「ストレージ管理OVS → ストレージ」の
接続経路をちゃんと確保しておく必要があるので
NW構成変更をするときには注意が必要です。
以上、OVM3のストレージ管理サーバの話でした。
2013年3月22日金曜日
Oracle VM 3 の プールファイルシステムについて。
今回は、Oracle VM 3 のプールファイルシステムについての話です。
Oracle VM では、
まず Oracle VM Manager（OVMM）でサーバプールを作成して、
そこに Oracle VM Server（OVS）を参加させます。
VMwareの vSphereと似た感じで、この「サーバプール」が
VMのHA機能やDRS/DPMの管理単位になっています。
このサーバプールを「クラスタ対応」のものとして作成する場合、
サーバプールのファイルシステム（Pool File System） が必要になります。
※シングルサーバプールには、プールファイルシステムは不要です。
1つのサーバプールには、1つのサーバプールが必要になります。
今回、例にしている環境では 「192.168.4.236:/nfs/vol1/share1」をプールファイルシステムにしています。
ためしに、プールファイルシステムがOVSからどのように見えるか見てみます。
今回はNFSをプールファイルシステムにしてます。
FCなどを使用している場合は、違った見え方になります。
まず、サーバプール内の1台目のOVSです。
下記の領域が、プールファイルシステムとして使用されています。
192.168.4.236:/nfs/vol1/share1
/dev/mapper/ovspoolfs
そして、サーバプール内の2台目のOVSです。
1台目のOVSと同様のNFS領域がマウントされています。
下記の2つは、VMや仮想ディスクを格納する「記憶域リポジトリ」で、
プールファイルシステムではありません。
192.168.4.237:/nfs/vol1/share1
192.168.4.236:/nfs/vol2/share1
プールファイルシステムとして使用されている
192.168.4.236:/nfs/vol1/share1 は、サーバプール内の全OVSから
/nfsmnt/～というディレクトリにマウントされていて、
中には ovspoolfs.img という
10GB のイメージファイル（実際はまだ133MBだけしか使用していない）が作成されています。
上の方で実行したOVSでの df コマンドの結果からわかるように、
この ovspoolfs.img も、すべてのOVSサーバから
/poolfsmnt/～ というディレクトリにマウントされています。
/dev/mapper/ovspoolfs
10G 263M 9.8G 3% /poolfsmnt/0004fb00000500003ef6341e33b0590e
この中には、サーバプールのクラスタの構成情報が含まれます。
データは、Berkeley DB で管理されているみたいです。
以上、OVM 3 のプールファイルシステムの話でした。
Oracle VM では、
まず Oracle VM Manager（OVMM）でサーバプールを作成して、
そこに Oracle VM Server（OVS）を参加させます。
VMwareの vSphereと似た感じで、この「サーバプール」が
VMのHA機能やDRS/DPMの管理単位になっています。
このサーバプールを「クラスタ対応」のものとして作成する場合、
サーバプールのファイルシステム（Pool File System） が必要になります。
※シングルサーバプールには、プールファイルシステムは不要です。
1つのサーバプールには、1つのサーバプールが必要になります。
今回、例にしている環境では 「192.168.4.236:/nfs/vol1/share1」をプールファイルシステムにしています。
ためしに、プールファイルシステムがOVSからどのように見えるか見てみます。
今回はNFSをプールファイルシステムにしてます。
FCなどを使用している場合は、違った見え方になります。
まず、サーバプール内の1台目のOVSです。
下記の領域が、プールファイルシステムとして使用されています。
192.168.4.236:/nfs/vol1/share1
/dev/mapper/ovspoolfs
[root@ovs321-1 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 6.7G 772M 5.6G 12% /
/dev/sda1 99M 28M 67M 29% /boot
tmpfs 232M 0 232M 0% /dev/shm
none 232M 104K 232M 1% /var/lib/xenstored
192.168.4.236:/nfs/vol1/share1
15G 827M 14G 6% /nfsmnt/818e5b06-82fc-4f92-a3cc-7ebb2f837adc
/dev/mapper/ovspoolfs
10G 263M 9.8G 3% /poolfsmnt/0004fb00000500003ef6341e33b0590e
192.168.4.237:/nfs/vol1/share1
13G 2.9G 9.3G 24% /OVS/Repositories/0004fb00000300005d636797dbfa991c
192.168.4.236:/nfs/vol2/share1
40G 21G 17G 55% /OVS/Repositories/0004fb0000030000ea10936ed4b4ff59
そして、サーバプール内の2台目のOVSです。
1台目のOVSと同様のNFS領域がマウントされています。
[root@ovs321-2 ~]# df -hどちらのサーバもおなじように 3つのNFSをマウントしていますが
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 6.7G 768M 5.6G 12% /
/dev/sda1 99M 28M 67M 29% /boot
tmpfs 232M 0 232M 0% /dev/shm
none 232M 104K 232M 1% /var/lib/xenstored
192.168.4.236:/nfs/vol1/share1
15G 827M 14G 6% /nfsmnt/818e5b06-82fc-4f92-a3cc-7ebb2f837adc
/dev/mapper/ovspoolfs
10G 263M 9.8G 3% /poolfsmnt/0004fb00000500003ef6341e33b0590e
192.168.4.237:/nfs/vol1/share1
13G 2.9G 9.3G 24% /OVS/Repositories/0004fb00000300005d636797dbfa991c
192.168.4.236:/nfs/vol2/share1
40G 21G 17G 55% /OVS/Repositories/0004fb0000030000ea10936ed4b4ff59
下記の2つは、VMや仮想ディスクを格納する「記憶域リポジトリ」で、
プールファイルシステムではありません。
192.168.4.237:/nfs/vol1/share1
192.168.4.236:/nfs/vol2/share1
プールファイルシステムとして使用されている
192.168.4.236:/nfs/vol1/share1 は、サーバプール内の全OVSから
/nfsmnt/～というディレクトリにマウントされていて、
中には ovspoolfs.img という
10GB のイメージファイル（実際はまだ133MBだけしか使用していない）が作成されています。
[root@ovs321-2 ~]# ls -lh /nfsmnt/818e5b06-82fc-4f92-a3cc-7ebb2f837adc
total 133M
-rw------- 1 root root 10G Mar 22 2013 ovspoolfs.img
上の方で実行したOVSでの df コマンドの結果からわかるように、
この ovspoolfs.img も、すべてのOVSサーバから
/poolfsmnt/～ というディレクトリにマウントされています。
/dev/mapper/ovspoolfs
10G 263M 9.8G 3% /poolfsmnt/0004fb00000500003ef6341e33b0590e
この中には、サーバプールのクラスタの構成情報が含まれます。
[root@ovs321-2 ~]# ls -lR /poolfsmnt/0004fb00000500003ef6341e33b0590e
/poolfsmnt/0004fb00000500003ef6341e33b0590e:
total 0
drwx------ 2 root root 3896 Mar 17 12:59 db
drwxr-xr-x 2 root root 3896 Mar 17 00:24 lost+found
/poolfsmnt/0004fb00000500003ef6341e33b0590e/db:
total 36
-rw------- 1 root root 12288 Mar 22 01:20 monitored_vms
-rw------- 1 root root 12288 Mar 22 01:17 server_pool
-rw------- 1 root root 12288 Mar 22 01:18 server_pool_servers
/poolfsmnt/0004fb00000500003ef6341e33b0590e/lost+found:
total 0
データは、Berkeley DB で管理されているみたいです。
[root@ovs321-1 ~]# cd /poolfsmnt/0004fb00000500003ef6341e33b0590e/db/
[root@ovs321-2 db]# ls -lh
total 36K
-rw------- 1 root root 12K Mar 22 01:20 monitored_vms
-rw------- 1 root root 12K Mar 22 01:17 server_pool
-rw------- 1 root root 12K Mar 22 01:18 server_pool_servers
[root@ovs321-2 db]# file *
monitored_vms: Berkeley DB (Hash, version 8, native byte-order)
server_pool: Berkeley DB (Hash, version 8, native byte-order)
server_pool_servers: Berkeley DB (Hash, version 8, native byte-order)
以上、OVM 3 のプールファイルシステムの話でした。
登録:
投稿 (Atom)