Oracle Linux とその周辺のもの: 3月 2013

2013年3月30日土曜日

Oracle VM CLI にアクセスしてみる。

Oracle VM Manager 3.2.1（OVMM）から、
Oracle VM Command Line Interface（OracleVM CLI）が
使用できるようになりました。
これは、OVMM に SSH で接続することで使用できます。

アクセスするときのアドレス（ホスト名/IPアドレス）は OVMM のもの。
デフォルトのポート番号は、TCP の10000番。
ユーザ/パスワードは、OVMM のもの（adminなど）でログインする。
Linux のユーザアカウントではない。

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の複数クローン作成でした。

2013年3月27日水曜日

Oracle VM 3 のクローン・カスタマイザを使用したVMテンプレートクローン実行。

今回は、Oracle VM 3 のクローン・カスタマイザを使用して
VMテンプレートをクローニングしてみます。

（こちらもどうぞ）

Oracle VM 3 のクローン・カスタマイザ作成

Oracle VM 3 の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のストレージとネットワーク接続を「クローン・カスタマイザ」で制御します。

（こちらもどうぞ）
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つの記憶域リポジトリが割り当ててあります。

NFS記憶域リポジトリ1 → Repo1
NFS記憶域リポジトリ2 → Repo2

この環境で、Repo1 に配置されているVMテンプレートを、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のストレージ管理サーバの話でした。

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

[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
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

どちらのサーバもおなじように 3つの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だけしか使用していない）が作成されています。

[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 のプールファイルシステムの話でした。

2013年3月19日火曜日

Oracle VM 3 の NFS記憶域リポジトリ

ためしに、NFS記憶リポジトリを Oracle VM Server 3 （OVS）にマウントしてみました。

まずは、NFSストレージを Oracle VM Managerに登録します。
ためしに、2つのNFSサーバを登録してみました。

NFSサーバ2台から、それぞれ記憶域リポジトリを作成しました。
どちらも「ovs321-1」というOVSにマウントされるように設定してあります。

1つ目のリポジトリは、
0004fb0000030000ea10936ed4b4ff59
というIDがで識別されました。

2つ目のリポジトリは、
0004fb00000300005d636797dbfa991c
というIDがで識別されました。

OVSにログインして記憶域リポジトリを見ると、このように見えます。

[root@ovs321-1 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 6.7G 769M 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 286M 12G 3% /OVS/Repositories/0004fb00000300005d636797dbfa991c
192.168.4.236:/nfs/vol2/share1
40G 13G 25G 34% /OVS/Repositories/0004fb0000030000ea10936ed4b4ff59

上記のように、OVSの /OVS/Repositories ディレクトリ配下には
いくつも記憶域リポジトリをマウントすることができます。

ちなみに、上記で見えている
192.168.4.236:/nfs/vol1/share1
/dev/mapper/ovspoolfs
の2つの領域（実際は1領域）は、Pool File System と呼ばれる、
記憶域リポジトリとは別用途で使用されています。

それぞれの記憶域リポジトリの下には、同じディレクトリ構造が作成されてます。

[root@ovs321-1 ~]# ls /OVS/Repositories/0004fb00000300005d636797dbfa991c
Assemblies ISOs Templates VirtualDisks VirtualMachines

[root@ovs321-1 ~]# ls /OVS/Repositories/0004fb0000030000ea10936ed4b4ff59
Assemblies ISOs Templates VirtualDisks VirtualMachines

たとえば、
VMの構成ファイル（vm.cfg）は VirtualMachines ディレクトリの配下、
VMの仮想ディスクイメージファイルは VirtualDisks ディレクトリの配下に格納されます。

OVM 3 からは複数のリポジトリをマウントしやすくなり、
VMごとにストレージ領域（リポジトリ）を分けて配置しやすくなったとのではないかと思います。

以上、OVSのNFS記憶域リポジトリでした。

2013年3月18日月曜日

Oracle VM 3 の「記憶域リポジトリ」について。

今回は Oracle VM 3（OVM3）の記憶域リポジトリの話です。

Oracle VM Serverの「記憶域リポジトリ」とは
VMの構成ファイルやディスクイメージファイル、
ISOファイル、VMテンプレートなどを格納する領域です。

記憶域リポジトリのディレクトリ構造はOVM 2 とOVM 3 で大きく変化しました。

以前（OVM 2 のころ）は、こんな感じでした。

[root@ovs1 ~]# cat /etc/ovs-release
Oracle VM server release 2.2.1
[root@ovs1 ~]# tree -L 1 /OVS
/OVS
|-- iso_pool
|-- lost+found
|-- publish_pool
|-- running_pool
|-- seed_pool
`-- sharedDisk

OVM 3 からはこんな感じになっています。

[root@ovs2 ~]# cat /etc/ovs-release
Oracle VM server release 3.2.1
[root@ovs2 ~]# ls /OVS/
Repositories
[root@ovs2 ~]# ls /OVS/Repositories/
0004fb0000030000cb5f6d6c030152f1
[root@ovs2 ~]# ls /OVS/Repositories/0004fb0000030000cb5f6d6c030152f1
Assemblies ISOs lost+found Templates VirtualDisks VirtualMachines

※OVS3には treeコマンド入ってませんでした。

OVM 2のときに Xenコマンド(xm)などで直接操作していた場合、
リポジトリのパスが変更されているので
手書きで指定していた仮想ディスクイメージファイルのパスもかわり、
VMの構成ファイル（vm.cfg）を書き換える必要があったりします。

たとえば、下記のような感じです。

★OVM2のとき
disk = ['file:/OVS/running_pool/vm01/System.img,xvda,w']
↓
★OVM3仕様
disk = ['file:/OVS/Repositories/～UUID～/VirtualMachines/vm01/System.img,xvda,w']

/OVS/Repositories ディレクトリの直下に
UUIDで複数のリポジトリ領域がマウントされることになります。

ちょっと複雑な構造になりましたが、
そのかわりに、1台のOVSに対して複数のリポジトリ領域を割り当てて
扱いやすくなったと思います。

以上、記憶域リポジトリの話でした。

2013年3月17日日曜日

Oracle VM 3 で必要な共有ストレージ領域について。

Oracle VM 3 の環境の共有ストレージ領域の話です。

Oracle VM 3の環境では、
主に共有ストレージを2つの用途で使用します。

Pool File System
記憶域リポジトリ

共有ストレージ領域をPool File Systemか記憶域リポジトリとして使用する前に
OVMMにストレージサーバを登録しておく必要があります。

共有ストレージでは、FCやiSCSIのストレージも使用できますが
今回の例では、手軽なNFSストレージ（Oracle Linuxで構築）を使用しています。

1. Pool File System

OVMMでは、OVSを管理するために「サーバプール」を作成します。
サーバプールを「Clustered Server Pool」として作成する場合に
必ず1つの Pool File System が必要です。
この領域はクラスタ管理のために使用され、
VMのイメージファイルなどを配置することはできません。

下記は、サーバプールの作成中に、Pool File System を指定している画面です。

Pool File System として使用されいている領域は、
サーバプールの「Info」画面（下記の赤枠のあたり）を見るとわかりやすいと思います。
この領域は、記憶域リポジトリとは別に必要になります。

この領域は、初期では140MBくらいしか実領域を使用していませんが、
12GB以上の共有ストレージ領域を指定しないとエラーが出て
クラスタサーバプールが作成できません。

2. 記憶域リポジトリ

VMのイメージファイル、ISOファイル、VMのテンプレートなどを格納できる領域です。

VMに割り当てる仮想ディスクや
インストールで使用するDVDイメージ（ISOファイル）などを配置するため、
大きな容量（数十GB～数百GB）が必要になります。

記憶域リポジトリは、OVS に対して割り当てる
（OVSが使用できるように、明示的に領域を提示する）必要があります。

以上、OVM 3 で必要な共有ストレージ領域の話でした。

登録: 投稿 (Atom)