今回は、前回の
ファイルシステムの話 (その1)
に続き、クラスタファイルシステムの話です。
通常のファイルシステムについて
まず、クラスタ対応していない、通常のファイルシステム
(とりあえず、ローカルファイルシステムと呼んだりしています)についてです。
※ローカルファイルシステムという呼び方は微妙かもしれません…
一般的に、Linuxでは ext3、ext2 などのファイルシステムが使用されています。
OSがこれらの仕組み(ファイルシステム)でファイルを管理するとき、
複数のアプリケーション(プロセス)が同時にファイルを更新しないように働いています。
ただし、これは1つのOSが、1つのファイルシステムでファイルを管理している場合の話です。
クラスタ対応していないローカルファイルシステムの場合は、
それぞれのOSが、他のOSのファイル管理操作を意識できません。
そのOS自身の中での(それぞれのOSからの)ファイル操作の整合性はとれますが
それぞれのOSが勝手にファイル操作をしてしまうため、
結果的に共有ディスクのデータは、整合性がない状態になってしまいます。
そのため、基本的にローカルファイルシステムを使用しているときに、
複数OSで同時に同じファイルシステムに書き込むことはNGです。
このような場合、
共有したディスク上のファイルを書き込むためには
サーバ(OS)のクラスタ環境に対応したファイルシステムとして
クラスタファイルシステムや、NFSを使用します。
クラスタファイルシステムについて
OVSで利用するクラスタファイルシステムは
OCFS2(Oracle Cluster File System version 2)です。
これは汎用的なクラスタファイルシステムなので、
OVS以外(たとえば、RACの共有ディスクなど)でも使用できます。
「Oracle」という名前がついていますが、Oracleのデータベースファイルだけでなく
一般的なファイル(バイナリファイルや、ログファイルなど)も格納することが可能で、
OVSで使用する場合は、VMの設定ファイルや、仮想ディスクイメージファイル等を
OCFS2の領域に格納します。
OCFS2は、複数のOSからのデータ書き込みに対して整合性を確保するため、
独自のクラスタウェア(o2cb)を使用します。
共有ディスクを利用するOSそれぞれで o2cb のプロセスが起動して
お互いが確認し合ってデータの整合性を確保するわけです。
以上、クラスタファイルシステムの話でした。
2013年1月27日日曜日
2013年1月26日土曜日
ファイルシステムの話 (その1)
今回は、ファイルシステムについての話です。
OVSではクラスタファイルシステム(OCFS2)を利用することが多いと思いますが、
OCFS2の前にローカルファイルシステムについて考えてみます。
OSでディスクにファイルを保存するためには、
ファイルシステムという仕組みを使用します。
ファイルシステムを作成するためには、一般的に下記の手順を踏みます。
※LVMの話は、ひとまずおいておきます。
作成したファイルシステムは、マウントして使用しますが
通常のローカルファイルシステム(クラスタ対応していないファイルシステム)を使用している場合、
OSは自分だけがファイル管理をする前提で動作します。
ファイルを管理する仕組みも、そのOS自身のメモリ上で処理されます。
そのため、
複数のサーバが同一のファイルシステム(ディスク領域)をマウントして
それぞれでデータ書き込みをしたりすると、不整合が発生してしまいます。
たとえば下図のような状態だと、
OS1とOS2がそれぞれ別にファイル管理をしてしまうため
OS1の更新がOS2で認識できなかったり、
OS2の更新がOS2で認識できなかったりします。
複数のOSから同じディスク領域をマウントして
ファイル操作(書き込みなど)をしたい場合は、
不整合を発生させないために、クラスタ環境対応しているファイルシステム
(たとえばOCFS2やNFSなど)を使用する必要があります。
以上、OCFS2への導入として、ローカルファイルシステムの話でした。
OVSではクラスタファイルシステム(OCFS2)を利用することが多いと思いますが、
OCFS2の前にローカルファイルシステムについて考えてみます。
OSでディスクにファイルを保存するためには、
ファイルシステムという仕組みを使用します。
ファイルシステムを作成するためには、一般的に下記の手順を踏みます。
※LVMの話は、ひとまずおいておきます。
- まず、OSにディスクを認識させる。
- 認識させたディスクに、パーティションを作成する。
- パーティションにファイルシステムを作成する。
(ディスク上に、ファイルを管理する仕組みを作る。) - ファイルシステムをディレクトリ(マウントポイント)にマウントする。
作成したファイルシステムは、マウントして使用しますが
通常のローカルファイルシステム(クラスタ対応していないファイルシステム)を使用している場合、
OSは自分だけがファイル管理をする前提で動作します。
ファイルを管理する仕組みも、そのOS自身のメモリ上で処理されます。
そのため、
複数のサーバが同一のファイルシステム(ディスク領域)をマウントして
それぞれでデータ書き込みをしたりすると、不整合が発生してしまいます。
たとえば下図のような状態だと、
OS1とOS2がそれぞれ別にファイル管理をしてしまうため
OS1の更新がOS2で認識できなかったり、
OS2の更新がOS2で認識できなかったりします。
複数のOSから同じディスク領域をマウントして
ファイル操作(書き込みなど)をしたい場合は、
不整合を発生させないために、クラスタ環境対応しているファイルシステム
(たとえばOCFS2やNFSなど)を使用する必要があります。
以上、OCFS2への導入として、ローカルファイルシステムの話でした。
2013年1月24日木曜日
OCFS2:クラスタファイルシステム環境構築
以前のエントリの続きです。
前回のエントリ
OVS on VirtualBox 環境に共有ディスクを割り当てたので、
今回はその領域にクラスタファイルシステムを作成してみます。
1. ノード1側のOVSでのディスク認識を確認
共有ディスクが、/dev/sdb として認識されています。
2. ノード2側のOVSでのディスク認識を確認
こちらでも共有ディスクが /dev/sdb として認識されています。
3. パーティションを作成
ノード1側のOVSで、
共有ディスク(/dev/sdb)にパーティション(/dev/sdb1)を作成します。
fdiskコマンドでパーティション(/dev/sdb1)が表示されるようになりました。
共有領域に対してパーティションを作成したので、
2台目OVS側でも、作成したパーティション(/dev/sdb1)が見えるようになります。
4. クラスタファイルシステムの作成
ノード1側のOVSで、/dev/sdb1 パーティションに、ファイルシステムを作成します。
ノード1側で確認
ファイルシステムを作成すると、
blkid コマンドでファイルシステムのUUIDを見られるようになります。
ノード2側で確認
ノード2側では、まず partprobe コマンドを実行して
OSにディスクパーティションテーブルの情報を再読み込みさせておきます。
blkid コマンドを実行してみると、
/dev/sdb1(ラベルは"/OVS")のUUIDがノード1側と同じものになっていて
同一のデバイスを共有していることがわかります。
5. 既存の/OVSをアンマウント
現時点では、ノード1、ノード2 それぞれでことなるデバイスを/OVSにマウントしています。
そのため、両ノードで既存の /OVS をアンマウントしたうえで、
新規作成した /dev/sdb1 のクラスタファイルシステムをマウントします。
既存の/OVSをマウントしている状態
このあと、共有ディスクを/OVSにマウントします。
ただし、このままではマウントできません。
OCFS2で共有ディスクを制御するための専用のクラスタウェアを使用します。
6. OCFS2のクラスタ設定ファイル作成
OCFS2でディスクを共有するため、クラスタの設定ファイルを作成します。
ディスクを共有したいサーバを、OCFS2独自のクラスタに所属させる設定をします。
7. O2CBの設定と起動
OCFS2のクラスタウェアは、O2CBという名前です。
下記のように「/etc/init.d/o2cb configure」コマンドで、
O2CBの設定変更とその内容の読み込みができます。
設定した内容は、/etc/sysconfig/o2cb ファイルに反映されます。
ノード1で、共有ディスクをマウントします。
マウント後に「mounted.ocfs2 -f」コマンドで
/dev/sdb1 のocfs2ファイルシステムが ovs001サーバ からマウントされていることが確認できます。
9. ノード2側でも同様にOCFS2環境を設定して、共有ディスクをマウント
ノード2側でOCFS2の設定ファイルを作成します。
※ノード1側と同じ設定をします。
ノード2側のO2CBを設定して起動します。
ノード2でも、共有ディスクをマウントします。
マウント後に「mounted.ocfs2 -f」コマンドで
/dev/sdb1 のocfs2ファイルシステムが2台のサーバ(ovs001とovs002)から
マウントされていることが確認できます。
以上、OCFS2の環境構築でした。
前回のエントリ
OVS on VirtualBox 環境に共有ディスクを割り当てたので、
今回はその領域にクラスタファイルシステムを作成してみます。
1. ノード1側のOVSでのディスク認識を確認
共有ディスクが、/dev/sdb として認識されています。
[root@ovs001 ~]# fdisk -l
Disk /dev/sda: 12.8 GB, 12884901888 bytes
255 heads, 63 sectors/track, 1566 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 1 13 104391 83 Linux
/dev/sda2 14 405 3148740 83 Linux
/dev/sda3 406 1435 8273475 83 Linux
/dev/sda4 1436 1566 1052257+ 5 Extended
/dev/sda5 1436 1566 1052226 82 Linux swap / Solaris
Disk /dev/sdb: 4294 MB, 4294967296 bytes
255 heads, 63 sectors/track, 522 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk /dev/sdb doesn't contain a valid partition table
You have new mail in /var/spool/mail/root
2. ノード2側のOVSでのディスク認識を確認
こちらでも共有ディスクが /dev/sdb として認識されています。
[root@ovs002 ~]# fdisk -l
Disk /dev/sda: 12.8 GB, 12884901888 bytes
255 heads, 63 sectors/track, 1566 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 1 13 104391 83 Linux
/dev/sda2 14 405 3148740 83 Linux
/dev/sda3 406 1435 8273475 83 Linux
/dev/sda4 1436 1566 1052257+ 5 Extended
/dev/sda5 1436 1566 1052226 82 Linux swap / Solaris
Disk /dev/sdb: 4294 MB, 4294967296 bytes
255 heads, 63 sectors/track, 522 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk /dev/sdb doesn't contain a valid partition table
3. パーティションを作成
ノード1側のOVSで、
共有ディスク(/dev/sdb)にパーティション(/dev/sdb1)を作成します。
[root@ovs001 ~]# fdisk /dev/sdb
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-522, default 1): ★エンター
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-522, default 522):★エンター
Using default value 522
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
fdiskコマンドでパーティション(/dev/sdb1)が表示されるようになりました。
[root@ovs001 ~]# fdisk -l
Disk /dev/sda: 12.8 GB, 12884901888 bytes
255 heads, 63 sectors/track, 1566 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 1 13 104391 83 Linux
/dev/sda2 14 405 3148740 83 Linux
/dev/sda3 406 1435 8273475 83 Linux
/dev/sda4 1436 1566 1052257+ 5 Extended
/dev/sda5 1436 1566 1052226 82 Linux swap / Solaris
Disk /dev/sdb: 4294 MB, 4294967296 bytes
255 heads, 63 sectors/track, 522 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdb1 1 522 4192933+ 83 Linux
共有領域に対してパーティションを作成したので、
2台目OVS側でも、作成したパーティション(/dev/sdb1)が見えるようになります。
[root@ovs002 ~]# fdisk -l
Disk /dev/sda: 12.8 GB, 12884901888 bytes
255 heads, 63 sectors/track, 1566 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 1 13 104391 83 Linux
/dev/sda2 14 405 3148740 83 Linux
/dev/sda3 406 1435 8273475 83 Linux
/dev/sda4 1436 1566 1052257+ 5 Extended
/dev/sda5 1436 1566 1052226 82 Linux swap / Solaris
Disk /dev/sdb: 4294 MB, 4294967296 bytes
255 heads, 63 sectors/track, 522 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdb1 1 522 4192933+ 83 Linux
4. クラスタファイルシステムの作成
ノード1側のOVSで、/dev/sdb1 パーティションに、ファイルシステムを作成します。
- -t ocfs2 → ファイルシステムの種類は、OCFS2
- -N 4 →このファイルシステムに接続するノード数(少し多めの4台にした)
- -L /OVS → ファイルシステムのラベル。(マウントポイントと合わせておいた)
[root@ovs001 ~]# mkfs -t ocfs2 -N 4 -L /OVS /dev/sdb1
mkfs.ocfs2 1.4.3
Cluster stack: classic o2cb
Filesystem label=/OVS
Block size=4096 (bits=12)
Cluster size=4096 (bits=12)
Volume size=4293562368 (1048233 clusters) (1048233 blocks)
33 cluster groups (tail covers 16041 clusters, rest cover 32256 clusters)
Journal size=67108864
Initial number of node slots: 4
Creating bitmaps: done
Initializing superblock: done
Writing system files: done
Writing superblock: done
Writing backup superblock: 1 block(s)
Formatting Journals: done
Formatting slot map: done
Writing lost+found: done
mkfs.ocfs2 successful
ノード1側で確認
ファイルシステムを作成すると、
blkid コマンドでファイルシステムのUUIDを見られるようになります。
[root@ovs001 ~]# blkid
/dev/sda5: LABEL="92bd3ba0a8ea" TYPE="swap"
/dev/sda3: LABEL="" UUID="5ec25b24-cb6f-4681-a59e-ede39840b5af" TYPE="ocfs2"
/dev/sda2: LABEL="/" UUID="562b8305-61ec-4673-8433-0edccf75d609" TYPE="ext3"
/dev/sda1: LABEL="/boot" UUID="cddae22e-6f94-4e59-882c-1d0dfa3c099d" TYPE="ext3"
/dev/sdb1: LABEL="/OVS" UUID="b5c473c6-b650-473e-b196-f4a2af104868" TYPE="ocfs2"
ノード2側で確認
ノード2側では、まず partprobe コマンドを実行して
OSにディスクパーティションテーブルの情報を再読み込みさせておきます。
blkid コマンドを実行してみると、
/dev/sdb1(ラベルは"/OVS")のUUIDがノード1側と同じものになっていて
同一のデバイスを共有していることがわかります。
[root@ovs002 ~]# partprobe /dev/sdb
[root@ovs002 ~]# blkid
/dev/sda5: LABEL="f678b4e7110e" TYPE="swap"
/dev/sda3: LABEL="" UUID="bebfa05e-5ba3-4e02-bf5a-164edaf9b0a4" TYPE="ocfs2"
/dev/sda2: LABEL="/" UUID="60a03a37-f574-4376-9233-8716a014dca5" TYPE="ext3"
/dev/sda1: LABEL="/boot" UUID="dfabb15a-a290-43f4-b8d8-c8fb76433546" TYPE="ext3"
/dev/sdb1: LABEL="/OVS" UUID="af59f99b-9163-49a3-b474-5f9948b57b7d" TYPE="ocfs2"
5. 既存の/OVSをアンマウント
現時点では、ノード1、ノード2 それぞれでことなるデバイスを/OVSにマウントしています。
そのため、両ノードで既存の /OVS をアンマウントしたうえで、
新規作成した /dev/sdb1 のクラスタファイルシステムをマウントします。
既存の/OVSをマウントしている状態
★ノード1それぞれのサーバで/OVSをアンマウントします。
[root@ovs001 ~]# ls -ld /OVS
lrwxrwxrwx 1 root root 47 Jan 20 06:22 /OVS -> /var/ovs/mount/8FA1F11000F145DA8A8272436BCD02C2
[root@ovs001 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 3.0G 847M 2.0G 30% /
/dev/sda1 99M 46M 49M 49% /boot
tmpfs 257M 0 257M 0% /dev/shm
none 256M 40K 256M 1% /var/lib/xenstored
/dev/sda3 7.9G 264M 7.7G 4% /var/ovs/mount/8FA1F11000F145DA8A8272436BCD02C2
[root@ovs001 ~]# blkid /dev/sda3
/dev/sda3: LABEL="" UUID="b33cf2ad-5021-4321-8faf-52e5b19c5e27" TYPE="ocfs2"
★ノード2
[root@ovs002 ~]# ls -ld /OVS
lrwxrwxrwx 1 root root 47 Jan 20 06:35 /OVS -> /var/ovs/mount/4EA14718C32B4D7784F3161A75953439
[root@ovs002 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 3.0G 847M 2.0G 30% /
/dev/sda1 99M 46M 49M 49% /boot
tmpfs 257M 0 257M 0% /dev/shm
none 256M 40K 256M 1% /var/lib/xenstored
/dev/sda3 7.9G 264M 7.7G 4% /var/ovs/mount/4EA14718C32B4D7784F3161A75953439
[root@ovs002 ~]# blkid /dev/sda3
/dev/sda3: LABEL="" UUID="bebfa05e-5ba3-4e02-bf5a-164edaf9b0a4" TYPE="ocfs2"
ノード1側でアンマウント
[root@ovs001 ~]# umount /OVS
ノード2側でもアンマウント
[root@ovs002 ~]# umount /OVS
このあと、共有ディスクを/OVSにマウントします。
ただし、このままではマウントできません。
OCFS2で共有ディスクを制御するための専用のクラスタウェアを使用します。
[root@ovs001 ~]# mount -t ocfs2 /dev/sdb1 /OVS
mount.ocfs2: Unable to access cluster service while trying initialize cluster
6. OCFS2のクラスタ設定ファイル作成
OCFS2でディスクを共有するため、クラスタの設定ファイルを作成します。
ディスクを共有したいサーバを、OCFS2独自のクラスタに所属させる設定をします。
- クラスタの名前: ovscluster
- クラスタのノード数: 2
- クラスタに参加するノード: ovs001 と ovs02
- OCFS2用クラスタの通信で使用するIPアドレスは192.168.10.x を指定。(これは、共有ディスクをマウントするネットワークセグメントとは別でもよい)
[root@ovs001 ~]# mkdir /etc/ocfs2
[root@ovs001 ~]# vi /etc/ocfs2/cluster.conf
【ファイルの内容】
node:
ip_port = 7777
ip_address = 192.168.10.101
number = 0
name = ovs001
cluster = ovscluster
node:
ip_port = 7777
ip_address = 192.168.10.102
number = 1
name = ovs002
cluster = ovscluster
cluster:
node_count = 2
name = ovscluster
7. O2CBの設定と起動
OCFS2のクラスタウェアは、O2CBという名前です。
下記のように「/etc/init.d/o2cb configure」コマンドで、
O2CBの設定変更とその内容の読み込みができます。
設定した内容は、/etc/sysconfig/o2cb ファイルに反映されます。
[root@ovs001 ~]# /etc/init.d/o2cb configure8. 共有ディスクのマウント
Configuring the O2CB driver.
This will configure the on-boot properties of the O2CB driver.
The following questions will determine whether the driver is loaded on
boot. The current values will be shown in brackets ('[]'). Hitting
without typing an answer will keep that current value. Ctrl-C
will abort.
Load O2CB driver on boot (y/n) [n]: y
Cluster stack backing O2CB [o2cb]: ★Enterキー
Cluster to start on boot (Enter "none" to clear) [ocfs2]: ovscluster
Specify heartbeat dead threshold (>=7) [31]:★Enterキー
Specify network idle timeout in ms (>=5000) [30000]:★Enterキー
Specify network keepalive delay in ms (>=1000) [2000]:★Enterキー
Specify network reconnect delay in ms (>=2000) [2000]:★Enterキー
Writing O2CB configuration: OK
Mounting configfs filesystem at /sys/kernel/config: OK
Loading filesystem "ocfs2_dlmfs": OK
Creating directory '/dlm': OK
Mounting ocfs2_dlmfs filesystem at /dlm: OK
Starting O2CB cluster ovscluster: OK
ノード1で、共有ディスクをマウントします。
マウント後に「mounted.ocfs2 -f」コマンドで
/dev/sdb1 のocfs2ファイルシステムが ovs001サーバ からマウントされていることが確認できます。
[root@ovs001 ~]# mount -t ocfs2 /dev/sdb1 /OVS
[root@ovs001 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 3.0G 848M 2.0G 30% /
/dev/sda1 99M 46M 49M 49% /boot
tmpfs 257M 0 257M 0% /dev/shm
none 256M 40K 256M 1% /var/lib/xenstored
/dev/sdb1 4.0G 270M 3.8G 7% /var/ovs/mount/8FA1F11000F145DA8A8272436BCD02C2
[root@ovs001 ~]# mounted.ocfs2 -f /dev/sdb1
Device FS Nodes
/dev/sdb1 ocfs2 ovs001
9. ノード2側でも同様にOCFS2環境を設定して、共有ディスクをマウント
ノード2側でOCFS2の設定ファイルを作成します。
※ノード1側と同じ設定をします。
[root@ovs002 ~]# mkdir /etc/ocfs2
[root@ovs002 ~]# vi /etc/ocfs2/cluster.conf
[root@ovs002 ~]# cat /etc/ocfs2/cluster.conf
node:
ip_port = 7777
ip_address = 192.168.10.101
number = 0
name = ovs001
cluster = ovscluster
node:
ip_port = 7777
ip_address = 192.168.10.102
number = 1
name = ovs002
cluster = ovscluster
cluster:
node_count = 2
name = ovscluster
ノード2側のO2CBを設定して起動します。
[root@ovs002 ~]# /etc/init.d/o2cb configure
Configuring the O2CB driver.
This will configure the on-boot properties of the O2CB driver.
The following questions will determine whether the driver is loaded on
boot. The current values will be shown in brackets ('[]'). Hitting
without typing an answer will keep that current value. Ctrl-C
will abort.
Load O2CB driver on boot (y/n) [n]: y
Cluster stack backing O2CB [o2cb]:
Cluster to start on boot (Enter "none" to clear) [ocfs2]: ovscluster
Specify heartbeat dead threshold (>=7) [31]:
Specify network idle timeout in ms (>=5000) [30000]:
Specify network keepalive delay in ms (>=1000) [2000]:
Specify network reconnect delay in ms (>=2000) [2000]:
Writing O2CB configuration: OK
Mounting configfs filesystem at /sys/kernel/config: OK
Loading filesystem "ocfs2_dlmfs": OK
Creating directory '/dlm': OK
Mounting ocfs2_dlmfs filesystem at /dlm: OK
Starting O2CB cluster ovscluster: OK
ノード2でも、共有ディスクをマウントします。
マウント後に「mounted.ocfs2 -f」コマンドで
/dev/sdb1 のocfs2ファイルシステムが2台のサーバ(ovs001とovs002)から
マウントされていることが確認できます。
[root@ovs002 ~]# mount -t ocfs2 /dev/sdb1 /OVS
[root@ovs002 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 3.0G 847M 2.0G 30% /
/dev/sda1 99M 46M 49M 49% /boot
tmpfs 257M 0 257M 0% /dev/shm
none 256M 40K 256M 1% /var/lib/xenstored
/dev/sdb1 4.0G 270M 3.8G 7% /var/ovs/mount/4EA14718C32B4D7784F3161A75953439
[root@ovs002 ~]# mounted.ocfs2 -f /dev/sdb1
Device FS Nodes
/dev/sdb1 ocfs2 ovs001, ovs002
以上、OCFS2の環境構築でした。
2013年1月20日日曜日
VirtualBoxで共有ディスク(失敗例)
前回のエントリで、VirtualBoxの仮想ディスク(仮想ハードドライブ)の共有をしてみました。
今回は、
仮想ハードドライブの共有設定をしなかった場合にどうなるか試してみました。
メディアマネージャで仮想ハードドライブの共有を有効にしなかった場合
→そもそも、下記のエラーがでてVirtualBoxでVMが起動できませんでした。
メディアマネージャで「共有可能」の設定をする場合は、
仮想ハードドライブが1台以下のVMからしか接続されていない状態にします。
2台以上が接続した状態で設定を変更しようとすると、下記のようなエラーが出ます。
仮想ハードドライブを「固定サイズ」で作成しなかった場合
→そもそも、下記のエラーがでて
VirtualBoxのメディアマネージャで「共有可能」が設定できませんでした。
この場合は、
以上、VirtualBox でのディスク共有の失敗例でした。
今回は、
仮想ハードドライブの共有設定をしなかった場合にどうなるか試してみました。
メディアマネージャで仮想ハードドライブの共有を有効にしなかった場合
→そもそも、下記のエラーがでてVirtualBoxでVMが起動できませんでした。
仮想マシン"ovs002"のセッションを開けませんでした。
No error info.
終了コード : VBOX_E_INVALID_OBJECT_STATE (0x80BB0007)
コンポーネント: ProgressProxy
インターフェース: IProgress {c20238e4-3221-4d3f-8891-81ce92d9f913}
メディアマネージャで「共有可能」の設定をする場合は、
仮想ハードドライブが1台以下のVMからしか接続されていない状態にします。
2台以上が接続した状態で設定を変更しようとすると、下記のようなエラーが出ます。
メディアタイプを通常 から 共有可能 にする際にエラーが発生しました。
Cannot change the type of medium 'C:\Users\go\VirtualBox VMs\OVS-on-vBox\ovs001\disk2-newovs.vdi' because it is attached to 2 virtual machines.
終了コード : VBOX_E_INVALID_OBJECT_STATE (0x80BB0007)
コンポーネント: Medium
インターフェース: IMedium {29989373-b111-4654-8493-2e1176cba890}
仮想ハードドライブを「固定サイズ」で作成しなかった場合
→そもそも、下記のエラーがでて
VirtualBoxのメディアマネージャで「共有可能」が設定できませんでした。
メディアタイプを通常 から 共有可能 にする際にエラーが発生しました。
Cannot change type for medium 'C:\Users\go\VirtualBox VMs\OVS-on-vBox\ovs002\test-disk1.vdi' to 'Shareable' since it is a dynamic medium storage unit.
終了コード : VBOX_E_INVALID_OBJECT_STATE (0x80BB0007)
コンポーネント: Medium
インターフェース: IMedium {29989373-b111-4654-8493-2e1176cba890}
この場合は、
- 「可変サイズ」で作成してしまったディスクを「固定サイズ」でコピーする
- 対象の仮想ハードドライブを右クリック→コピーを選択して、
「固定サイズ」のものをもう一つ作成する。 - (コピーした仮想ハードドライブはメディアマネージャに登録されないので)
VMにコピーした仮想ハードドライブを割り当てて、メディアマネージャに登録する。 - 新規で、固定サイズの仮想ハードドライブを作成してVMに割り当てる。
以上、VirtualBox でのディスク共有の失敗例でした。
2013年1月16日水曜日
VirtualBoxで共有ディスク
ちょっとLive Migrationができる環境を作りたいと思い
VirtualBox上にインストールした Oracle VM Server 2台に、
共有ディスクを割り当ててみました。
一部、画面をはしょって、空気だけお伝えします。
ポイントは、
手順1. 1台目のVMへのディスク割り当て(新規作成)
まず、1台目のVMでは、仮想ディスクを新規作成します。
仮想ディスクは、VirutalBoxでは仮想ハードドライブと呼びます。
最初に、VMに仮想的なストレージコントローラを追加します。
そのうえで、コントローラに仮想ハードドライブを追加します。
仮想ディスクのファイル形式は、「VDI」を選択しました。
他にも、VMwareで一般的なVMDK形式や、MicrosoftのVHD形式、
KVMでよく使われるQCOWなど、いろいろ選べます。
新規の仮想ディスク(仮想ハードドライブ)を「固定サイズ」 で作成します。
ファイル名には、自動的に拡張子が付けられます。
VDI形式なら、「.vdi」がファイル名の末尾に追加されます。
ディスク容量は、VMのディスクイメージを載せられる程度必要です。
(今回は4GBだけです)
1台目のVMは、このような設定になります。
手順2. VirtualBoxメディアマネージャでのディスク共有設定
ここまでで作成した仮想ハードドライブを、共有可能に設定します。
これはVM毎の設定画面ではなく、メディアマネージャにて実施します。
[ファイル] → [仮想メディアマネージャー] を開きます。
作成した仮想ハードドライブを右クリックして「変更」します。
メディア属性を変更する画面で、「共有可能」にします。
手順3. 2台目のVMへのディスク割り当て(既存ディスクの割り当て)
新規作成はせずに、「既存のディスクを選択」します。
ここまでで作成した仮想ハードドライブのファイルを選択します。
仮想ハードドライブのファイル(.vdi ファイル)は、
1台目のVM が格納されるフォルダに作成されています。
この方法で割り当てることで、
複数のVMで、仮想ハードドライブを共有ディスクにすることができます。
以上、VirualBoxで共有ディスクを割り当ててみる話でした。
VirtualBox上にインストールした Oracle VM Server 2台に、
共有ディスクを割り当ててみました。
一部、画面をはしょって、空気だけお伝えします。
ポイントは、
- 仮想ディスク(仮想ハードドライブ)のファイルは容量固定で作成する。
- 仮想ハードドライブは、メディアマネージャで共有設定をする。
手順1. 1台目のVMへのディスク割り当て(新規作成)
まず、1台目のVMでは、仮想ディスクを新規作成します。
仮想ディスクは、VirutalBoxでは仮想ハードドライブと呼びます。
最初に、VMに仮想的なストレージコントローラを追加します。
そのうえで、コントローラに仮想ハードドライブを追加します。
仮想ディスクのファイル形式は、「VDI」を選択しました。
他にも、VMwareで一般的なVMDK形式や、MicrosoftのVHD形式、
KVMでよく使われるQCOWなど、いろいろ選べます。
新規の仮想ディスク(仮想ハードドライブ)を「固定サイズ」 で作成します。
ファイル名には、自動的に拡張子が付けられます。
VDI形式なら、「.vdi」がファイル名の末尾に追加されます。
ディスク容量は、VMのディスクイメージを載せられる程度必要です。
(今回は4GBだけです)
1台目のVMは、このような設定になります。
手順2. VirtualBoxメディアマネージャでのディスク共有設定
ここまでで作成した仮想ハードドライブを、共有可能に設定します。
これはVM毎の設定画面ではなく、メディアマネージャにて実施します。
[ファイル] → [仮想メディアマネージャー] を開きます。
作成した仮想ハードドライブを右クリックして「変更」します。
メディア属性を変更する画面で、「共有可能」にします。
手順3. 2台目のVMへのディスク割り当て(既存ディスクの割り当て)
1台目のVMと同様に、2台目のVMに
仮想ストレージアダプタと、共有設定した仮想ハードドライブを割り当てます。
新規作成はせずに、「既存のディスクを選択」します。
ここまでで作成した仮想ハードドライブのファイルを選択します。
仮想ハードドライブのファイル(.vdi ファイル)は、
1台目のVM が格納されるフォルダに作成されています。
この方法で割り当てることで、
複数のVMで、仮想ハードドライブを共有ディスクにすることができます。
以上、VirualBoxで共有ディスクを割り当ててみる話でした。
2013年1月15日火曜日
OVMS をKickstart (7回目)
今回は、Oracle VM Server (OVMS)の Kickstart ファイルに記載する
root ユーザのパスワードを暗号化(というかハッシュ化) します。
メジャーなパスワード文字列の生成方法は、下記の2つのようです。
前回はこちら。
root ユーザのパスワードを暗号化(というかハッシュ化) します。
メジャーなパスワード文字列の生成方法は、下記の2つのようです。
- openssl コマンドで生成。
- 既存環境の /etc/shadow にある文字列をそのまま使う。
前回はこちら。
2013年1月13日日曜日
OVSのMACアドレスについて
今回は、Orale VM Serverの使用する
MACアドレスについての話です。
MACアドレスについて
NICには、ネットワークポートごとにMACアドレスが割り当てられています。
物理サーバの場合は、サーバをネットワーク接続するために
IPアドレスは必ず変更するはずですが、
MACアドレスはNIC固有の(NICに焼き付けられている)ものであるため
変更することはあまりないと思います。
MACアドレスは、
XX:XX:XX:YY:YY:YY
といった形式となっています。
このうち、前半の6文字(XX:XX:XX)の部分は
NICの製造ベンダーを表す OUI(Organizationally Unique Identifier)を表します。
どのベンダーのものかは、
MACアドレスを管理しているIEEEのWebサイトで検索できます。
OVSのMACアドレスについて
Oracle VM ServerのVMの仮想NICにもMACアドレスが割り当てられますが、
物理サーバとは違い、VMの設定ファイル(vm.cfg)に指定しておかないと
VMを起動するたびに自動再生成されます。
このとき、OVSのVMで自走生成されるMACアドレスは
00:16:3E:YY:YY:YY
といったアドレスになります。
この 00:16:3E:~ のアドレスをIEEEのサイトで確認すると、
「Xensource, Inc.」として登録されていました。
Oracle VM Serverが、Xen ハイパーバイザを使用しているため、
MACアドレスもXen由来のものになるようです。
OVSで仮想NICのMACアドレスを手動で設定することがありますが、
MACアドレスを手動で設定(vm.cfgに書いたり)する場合は
00:16:3E:~のアドレスから適宜番号を選んで払い出します。
以上、OVSのMACアドレスの話でした。
MACアドレスについての話です。
MACアドレスについて
NICには、ネットワークポートごとにMACアドレスが割り当てられています。
物理サーバの場合は、サーバをネットワーク接続するために
IPアドレスは必ず変更するはずですが、
MACアドレスはNIC固有の(NICに焼き付けられている)ものであるため
変更することはあまりないと思います。
MACアドレスは、
XX:XX:XX:YY:YY:YY
といった形式となっています。
このうち、前半の6文字(XX:XX:XX)の部分は
NICの製造ベンダーを表す OUI(Organizationally Unique Identifier)を表します。
どのベンダーのものかは、
MACアドレスを管理しているIEEEのWebサイトで検索できます。
IEEEのサイトはこちら
http://standards.ieee.org/develop/regauth/oui/public.html
OVSのMACアドレスについて
Oracle VM ServerのVMの仮想NICにもMACアドレスが割り当てられますが、
物理サーバとは違い、VMの設定ファイル(vm.cfg)に指定しておかないと
VMを起動するたびに自動再生成されます。
このとき、OVSのVMで自走生成されるMACアドレスは
00:16:3E:YY:YY:YY
といったアドレスになります。
この 00:16:3E:~ のアドレスをIEEEのサイトで確認すると、
「Xensource, Inc.」として登録されていました。
Oracle VM Serverが、Xen ハイパーバイザを使用しているため、
MACアドレスもXen由来のものになるようです。
OVSで仮想NICのMACアドレスを手動で設定することがありますが、
MACアドレスを手動で設定(vm.cfgに書いたり)する場合は
00:16:3E:~のアドレスから適宜番号を選んで払い出します。
以上、OVSのMACアドレスの話でした。
2013年1月12日土曜日
OVMS をKickstart (6回目)
今回は、Kickstart での OVMS インストールを、もう少し自動化してみます。
サーバの MAC アドレスをもとに
個別の Kickstart 設定ファイルを読み込ませて自動インストールしてみます。
前回までに構築した環境を使っています。
サーバの MAC アドレスをもとに
個別の Kickstart 設定ファイルを読み込ませて自動インストールしてみます。
前回までに構築した環境を使っています。
2013年1月11日金曜日
OVMS を Kickstart (5回目)
今回は、インストールを自動化できる Kickstart ファイルを使用して、
Oracle VM Server (OVMS) をインストールしてみます。
1. Kickstart の環境を準備しておく
Kickstart の環境は、以前の投稿のものを使っています。
Oracle VM Server (OVMS) をインストールしてみます。
1. Kickstart の環境を準備しておく
Kickstart の環境は、以前の投稿のものを使っています。
- Kickstart サーバの構築。
- Kickstart サーバに OVMS のインストールメディアを配置。
- OVMS のインストール対象サーバを用意する。
2013年1月10日木曜日
OVMS をKickstart (4回目)
今回は、Kickstart インストールのために、
Oracle VM Server (OVMS) インストールメディア配布準備をします。
前回はこちら。
作業はすべて、Kickstart サーバで実施します。(下記の投稿参照)
Oracle VM Server (OVMS) インストールメディア配布準備をします。
前回はこちら。
作業はすべて、Kickstart サーバで実施します。(下記の投稿参照)
2013年1月9日水曜日
OVMS をKickstart (3回目)
2013年1月7日月曜日
OVMS をKickstart (2回目)
今回は、まず Kickstart サーバを構築します。
前回はこちら。
Oracle Linux 6.3 をインストールしたサーバを用意しておきます。
下記のIPアドレスを設定をしておくことにします。
前回はこちら。
1. 事前準備
Oracle Linux 6.3 をインストールしたサーバを用意しておきます。
※これは、VortualBox 上の VM でも OK です。
下記のIPアドレスを設定をしておくことにします。
- eth0: 192.168.56.110 → このサーバへの通常アクセス用。
- eth1: 192.168.10.110 → Kickstart 用の NW に接続しておく。
2013年1月6日日曜日
OVMS を Kickstart (1回目)
ためしに、Oracle VM Server 2.2.2 (OVMS) を
Kickstart でインストールしてみようと思います。
インストールサーバ(Kickstart サーバ)を使用した Kickstart で
Linux のインストールを自動化することができます。
OVMS も基本的には Linux なので、Kickstart でインストールできます。
Kickstart サーバは、PXE ブートの起動イメージ、設定ファイル、
インストールメディアを配布する機能などをもちます。
Kickstart サーバ自体も Linuxで構築できるので、今回は Oracle Linux を Kickstart サーバにします。
まずは、Kickstart と、今回のサーバ構成の概要についてです。
Kickstart でインストールしてみようと思います。
インストールサーバ(Kickstart サーバ)を使用した Kickstart で
Linux のインストールを自動化することができます。
OVMS も基本的には Linux なので、Kickstart でインストールできます。
Kickstart サーバは、PXE ブートの起動イメージ、設定ファイル、
インストールメディアを配布する機能などをもちます。
Kickstart サーバ自体も Linuxで構築できるので、今回は Oracle Linux を Kickstart サーバにします。
まずは、Kickstart と、今回のサーバ構成の概要についてです。
2013年1月5日土曜日
Dom0からゲストOSの設定変更してみる。
今回は、Dom0からゲストOS内の設定を変更してみます。
この記事は、下記の記事の続きです。
1. VMの設定ファイルを編集しておく。
VMの設定ファイル(vm.cfg)の仮想NICの設定を編集しておきます。
2. VMの仮想ディスクイメージをDom0にマウントします。
3. VMの仮想ディスクイメージ内の設定ファイルを編集します。
1つ目のNICを設定変更します。(MACアドレスとIPアドレス)
2つ目のNICもIP設定します。設定ファイルは、1つ目のNICのものをコピーして書き換えています。
表示される「id=3」は、Dom0でのVM起動のたびにカウントアップされます。
この記事は、下記の記事の続きです。
例として、ゲストOSのネットワーク設定(IP設定)を変更します。
1. VMの設定ファイルを編集しておく。
VMの設定ファイル(vm.cfg)の仮想NICの設定を編集しておきます。
- 仮想NICを追加します。
- 仮想NICのMACアドレスを設定します。
- これを設定しないと、VMを起動するたびにMACアドレスが変更されてしまいます。(アドレスは自動生成)
- MACアドレスは「00:16:3E」から始まるもの(Xen用に予約されたアドレス)を適当に使用しています。
- 仮想NICの接続先となる仮想スイッチを指定します。
- これを設定しないと、仮想NICが自動的に xenbr0 に接続されます。
[root@ovs11 ~]# vi /OVS/running_pool/EL52_vm1/vm.cfg
vif = ['type=netfront']
↓(編集)vif = ['mac=00:16:3E:00:00:01, bridge=xenbr0, type=netfront','mac=00:16:3E:10:00:01, bridge=xenbr1, type=netfront',]
[root@ovs11 ~]# lomount -t ext3 \
> -diskimage /OVS/running_pool/EL52_vm1/System.img -partition 2 /mnt/
[root@ovs11 ~]#
1つ目のNICを設定変更します。(MACアドレスとIPアドレス)
MACアドレスは、vm.cfgファイルに設定したものと合わせます。
[root@ovs11 ~]# cd /mnt/etc/sysconfig/network-scripts/
[root@ovs11 network-scripts]# vi ifcfg-eth0(ファイルの内容)
DEVICE=eth0ONBOOT=yesBOOTPROTO=staticHWADDR=00:16:3E:00:00:01TYPE=EthernetIPADDR=192.168.56.31NETMASK=255.255.255.0
[root@ovs11 network-scripts]# cp ifcfg-eth0 ifcfg-eth1
[root@ovs11 network-scripts]# vi ifcfg-eth0(ファイルの内容)
DEVICE=eth1 ★変更ONBOOT=yesBOOTPROTO=staticHWADDR=00:16:3E:10:00:01 ★変更TYPE=EthernetIPADDR=192.168.0.31 ★変更NETMASK=255.255.255.0
ついでにホスト名の設定も変更します。
[root@ovs11 network-scripts]# cd
[root@ovs11 ~]# vi /mnt/etc/sysconfig/networkHOSTNAME=localhost.localdomain
↓(編集)HOSTNAME=vm1
4. VMの仮想ディスクイメージをDom0からアンマウントします。
[root@ovs11 ~]# umount /mnt/
5. VMを起動 & 設定確認します。
[root@ovs11 ~]# xm create /OVS/running_pool/EL52_vm1/vm.cfgVMの仮想NICは、vm.cfgファイルに指定したブリッジに接続されました。
Using config file "/OVS/running_pool/EL52_vm1/vm.cfg".Started domain EL52_vm1 (id=3)
[root@ovs11 ~]# brctl show
bridge name bridge id STP enabled interfaces
xenbr0 8000.080027c59f4e no vif3.0
eth0
xenbr1 8000.08002743ab84 no vif3.1
eth1
少し待ってから(ゲストOSが起動するのを)VMにログインして確認すると、
設定が反映されていることが確認できます。
(ホスト名、MACアドレスとIPアドレス)
設定が反映されていることが確認できます。
(ホスト名、MACアドレスとIPアドレス)
[root@ovs11 ~]# ssh 192.168.56.31
The authenticity of host '192.168.56.31 (192.168.56.31)' can't be established.RSA key fingerprint is 1f:2d:bd:25:fb:56:d7:b7:58:de:44:cb:a3:56:f4:ea.Are you sure you want to continue connecting (yes/no)? yesWarning: Permanently added '192.168.56.31' (RSA) to the list of known hosts.root@192.168.56.31's password:Last login: Sat Jan 5 06:45:37 2013[root@vm1 ~]# uname -nvm1 ★ホスト名が変更されている[root@vm1 ~]# ifconfig | grep addr[root@vm1 ~]# ifconfig eth0| grep addr
eth0 Link encap:Ethernet HWaddr 00:16:3E:00:00:01
inet addr:192.168.56.31 Bcast:192.168.56.255 Mask:255.255.255.0
inet6 addr: fe80::216:3eff:fe00:1/64 Scope:Link
[root@vm1 ~]# ifconfig eth1| grep addr
eth1 Link encap:Ethernet HWaddr 00:16:3E:10:00:01
inet addr:192.168.0.31 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::216:3eff:fe10:1/64 Scope:Link
以上、Dom0からのゲストOS設定変更でした。
2013年1月4日金曜日
OVSのディスクについて(3回目)
今回は、Oracle VM Server(OVS)のDom0 から
VMの仮想ディスクをのぞいてみます。
VM上のゲストOSからのディスクパーティション認識
まず、VM(ゲストOS)のディスク認識を確認しておきます。
ゲストOS上では、ディスク(仮想ディスク)を /dev/xvda の1つだけ認識しています。
そのなかの2番目のパーティション(/dev/xvda2)を
/(rootマウントポイント)にマウントしています。
ディスクイメージファイルを Dom0 でマウント
VMの仮想ディスクとなる、ディスクイメージファイル(System.img)をマウントします。
イメージファイルの中に複数のパーティションが作成されているため、
lomount コマンドで、パーティション番号を指定してマウントします。
(-partition 2)
System.img ファイルをマウントする前に、
VM1は停止(shutdown)しておきます。
最後に、マウントしたディスクイメージをアンマウントしておきます。
以上、
Dom0にDomUディスクをマウントしてみる話でした。
VMの仮想ディスクをのぞいてみます。
VM上のゲストOSからのディスクパーティション認識
まず、VM(ゲストOS)のディスク認識を確認しておきます。
ゲストOS上では、ディスク(仮想ディスク)を /dev/xvda の1つだけ認識しています。
[root@vm1 ~]# fdisk -l
Disk /dev/xvda: 2155 MB, 2155023360 bytes
255 heads, 63 sectors/track, 262 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/xvda1 * 1 12 96358+ 83 Linux
/dev/xvda2 13 261 2000092+ 83 Linux
/dev/xvda3 262 262 8032+ 82 Linux swap / Solaris
そのなかの2番目のパーティション(/dev/xvda2)を
/(rootマウントポイント)にマウントしています。
[root@vm1 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 92M 11M 76M 13% /boot
/dev/xvda2 1.9G 493M 1.4G 27% /
tmpfs 129M 0 129M 0% /dev/shm
ディスクイメージファイルを Dom0 でマウント
VMの仮想ディスクとなる、ディスクイメージファイル(System.img)をマウントします。
イメージファイルの中に複数のパーティションが作成されているため、
lomount コマンドで、パーティション番号を指定してマウントします。
(-partition 2)
System.img ファイルをマウントする前に、
VM1は停止(shutdown)しておきます。
[root@ovs11 ~]# ls /mnt/
[root@ovs11 ~]# ★マウント前は何も見えない。
[root@ovs11 ~]# cd /OVS/running_pool/EL52_vm1/
[root@ovs11 EL52_vm1]# lomount -t ext3 -diskimage System.img -partition 2 /mnt
[root@ovs11 EL52_vm1]# ls /mnt/
bin dev home lost+found mnt proc sbin srv tmp usr
boot etc lib media opt root selinux sys u01 var
★System.imgの中身が/mnt配下で見られるようになった。
最後に、マウントしたディスクイメージをアンマウントしておきます。
[root@ovs11 EL52_vm1]# umount /mnt
[root@ovs11 EL52_vm1]# ls /mnt/
[root@ovs11 EL52_vm1]# ★アンマウントしたので何も見えなくなった。
以上、
Dom0にDomUディスクをマウントしてみる話でした。
2013年1月3日木曜日
OVSのディスクについて(2回目)
Oracle VM Server(OVS)でのディスク(ディスク記憶域)認識について、
前回の続きです。
今回、OVS(Dom0)としては、下記の領域があります。
VMのイメージファイルは約2GBにしています。
Dom0 のディスク認識
まず、Dom0が認識しているディスクを見てみます。
/dev/sdb1 の約12GBの領域が、
VMのイメージファイルを格納しているリポジトリ (/OVS) です。
2GBのファイルとして見えています。
DomUからのディスク認識
VMからは、2GBのSystem.imgファイルの内部だけが見えています。
VMが認識しているディスク領域を合計すると、約2GBになります。
以上、今回もOVSのディスク認識の話でした。
前回の続きです。
今回、OVS(Dom0)としては、下記の領域があります。
- 約8GBのOS用の領域
- 約12GBのOVSリポジトリ(VMを配置する)
VMのイメージファイルは約2GBにしています。
Dom0 のディスク認識
まず、Dom0が認識しているディスクを見てみます。
[root@ovs11 ~]# fdisk -l
Disk /dev/sda: 8589 MB, 8589934592 bytes
255 heads, 63 sectors/track, 1044 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 14 1044 8281507+ 83 Linux
/dev/sda2 * 1 13 104391 83 Linux
Partition table entries are not in disk order
Disk /dev/sdb: 12.8 GB, 12884901888 bytes
255 heads, 63 sectors/track, 1566 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdb1 * 1 1435 11526606 83 Linux
/dev/sdb2 1436 1566 1052257+ 82 Linux swap / Solaris
[root@ovs11 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 7.7G 1.5G 5.8G 21% /
/dev/sda2 99M 45M 49M 48% /boot
tmpfs 257M 0 257M 0% /dev/shm
none 256M 40K 256M 1% /var/lib/xenstored
/dev/sdb1 11G 4.2G 6.9G 38% /var/ovs/mount/84D81812DF944D3CBF42AB164A70CC06
/dev/sdb1 の約12GBの領域が、
VMのイメージファイルを格納しているリポジトリ (/OVS) です。
[root@ovs11 ~]# ls -ld /OVSDom0から見たVMの仮想ディスク(System.img)は、
lrwxrwxrwx 1 root root 47 Dec 29 16:33 /OVS -> /var/ovs/mount/84D81812DF944D3CBF42AB164A70CC06
2GBのファイルとして見えています。
[root@ovs11 ~]# ls -lh /OVS/running_pool/EL52_vm1/*
-rw-r--r-- 1 root root 2.1G Dec 31 17:35 /OVS/running_pool/EL52_vm1/System.img
-rw-r--r-- 1 root root 251 Dec 30 20:56 /OVS/running_pool/EL52_vm1/vm.cfg
DomUからのディスク認識
VMからは、2GBのSystem.imgファイルの内部だけが見えています。
VMが認識しているディスク領域を合計すると、約2GBになります。
[root@vm1 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvda2 1.9G 493M 1.4G 27% /
/dev/xvda1 92M 11M 76M 13% /boot
tmpfs 129M 0 129M 0% /dev/shm
[root@vm1 ~]# fdisk -l
Disk /dev/xvda: 2155 MB, 2155023360 bytes
255 heads, 63 sectors/track, 262 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/xvda1 * 1 12 96358+ 83 Linux
/dev/xvda2 13 261 2000092+ 83 Linux
/dev/xvda3 262 262 8032+ 82 Linux swap / Solaris
以上、今回もOVSのディスク認識の話でした。
2013年1月2日水曜日
OVSのディスクについて(1回目)
今回は、Oracle VM Server(OVS)でのディスク(ディスク記憶域)認識についての話です。
Dom0のディスク認識
OVSをインストールした物理サーバに接続されているディスクは、まずDom0が認識します。
VMにディスク領域(ゲストOSが認識する仮想ディスク)を使用させるためには、
Dom0がディスクイメージファイル(System.imgなど)を作成して、VMに対して割り当てます。
DomUのディスク認識
VMは、DomUからディスクイメージを仮想ディスクとして割り当てられています。
VM用の仮想ディスクは、Dom0ではファイルとして認識していますが、
割り当てられたVM(とその上のゲストOS)は、自分自身のディスク領域として認識します。
Dom0とVM(DomU)のディスク認識のちがい
Dom0からは、OVSが管理しているVMの仮想ディスクすべてにアクセスすることができます。
たとえば、VM用のディスクイメージファイルをDom0にマウントして
中のデータを見る(編集する)こともできてしまいます。
一方、VMからは、自分の仮想ディスク以外の領域は認識できません。
Dom0のディスク領域は見えず、となりのVMのディスク領域も見えません。
以上、OVSのディスク認識の話でした。
OVS環境(=Xen環境)のディスクについて考えるには2つの視点が必要だと思います。
- Dom0が認識するディスク
- VM(DomU)が認識するディスク
Dom0のディスク認識
OVSをインストールした物理サーバに接続されているディスクは、まずDom0が認識します。
VMにディスク領域(ゲストOSが認識する仮想ディスク)を使用させるためには、
Dom0がディスクイメージファイル(System.imgなど)を作成して、VMに対して割り当てます。
DomUのディスク認識
VMは、DomUからディスクイメージを仮想ディスクとして割り当てられています。
VM用の仮想ディスクは、Dom0ではファイルとして認識していますが、
割り当てられたVM(とその上のゲストOS)は、自分自身のディスク領域として認識します。
Dom0とVM(DomU)のディスク認識のちがい
Dom0からは、OVSが管理しているVMの仮想ディスクすべてにアクセスすることができます。
たとえば、VM用のディスクイメージファイルをDom0にマウントして
中のデータを見る(編集する)こともできてしまいます。
一方、VMからは、自分の仮想ディスク以外の領域は認識できません。
Dom0のディスク領域は見えず、となりのVMのディスク領域も見えません。
以上、OVSのディスク認識の話でした。
2013年1月1日火曜日
OVS on VirtualBoxのネットワークは無差別モードにする
Oracle VM Server(OVS) on VirtualBoxのネットワーク構成についてです。
VirtualBox上のOVSで、さらにVM(ネストVM)を起動すると
そのままではOVS外部のネットワークとは接続ができません。
通常のVMであれば、VM自身に設定されたMACアドレスの通信だけを許可しています。
OVSでは、OVS自身だけでなくネストVMのもつMACアドレスの通信も
許可する必要があるので、プロミスキャス(MACを無差別)で通信するように設定を変更します。
たとえば、下図のような構成だった場合、
OVSをインストールしたVMでは、通常のVMの通信(Dom0のeth0の通信)だけでなく
ネストVMのNIC(VM1のeth0、VM2のeth0)の通信も発生します。
ネストVMを外部ネットワークと接続するためには、
OVSをインストールしたVMの仮想NICの設定で、プロミスキャスモードを有効化します。
VirutualBoxマネージャで、OVSをインストールしたVMのネットワーク設定を変更します。
下のスクリーンショットでは、プロミスキャスモードを「すべて許可」にして有効化しています。
プロミスキャスモードの設定はVMを起動したまま可能ですが、
設定後にOVSを再起動したほうがよいようです。
※VM起動したままの有効化ではうまく動作せず、ネストVMが外部と通信できませんでした。
この、プロミスキャスモードの設定は、
VM上で仮想化ソフトを動かす場合(ネステッドハイパーバイザ構成のときなど)は
OVSに限らず(KVMでも、ESXiでも)必要になり、外側の仮想化ソフトで設定をします。
以上、OVS on VirtualBoxのネットワークについてでした。
VirtualBox上のOVSで、さらにVM(ネストVM)を起動すると
そのままではOVS外部のネットワークとは接続ができません。
通常のVMであれば、VM自身に設定されたMACアドレスの通信だけを許可しています。
OVSでは、OVS自身だけでなくネストVMのもつMACアドレスの通信も
許可する必要があるので、プロミスキャス(MACを無差別)で通信するように設定を変更します。
たとえば、下図のような構成だった場合、
OVSをインストールしたVMでは、通常のVMの通信(Dom0のeth0の通信)だけでなく
ネストVMのNIC(VM1のeth0、VM2のeth0)の通信も発生します。
ネストVMを外部ネットワークと接続するためには、
OVSをインストールしたVMの仮想NICの設定で、プロミスキャスモードを有効化します。
VirutualBoxマネージャで、OVSをインストールしたVMのネットワーク設定を変更します。
下のスクリーンショットでは、プロミスキャスモードを「すべて許可」にして有効化しています。
プロミスキャスモードの設定はVMを起動したまま可能ですが、
設定後にOVSを再起動したほうがよいようです。
※VM起動したままの有効化ではうまく動作せず、ネストVMが外部と通信できませんでした。
この、プロミスキャスモードの設定は、
VM上で仮想化ソフトを動かす場合(ネステッドハイパーバイザ構成のときなど)は
OVSに限らず(KVMでも、ESXiでも)必要になり、外側の仮想化ソフトで設定をします。
以上、OVS on VirtualBoxのネットワークについてでした。
登録:
投稿 (Atom)