システム奮闘記：その89

xenserverの運用・管理

はじめに

　ひょんな事から仮想化ソフトxenserver5.6を導入した。
　詳しくは「システム奮闘記:その88」(xenserverインストール入門)を
ご覧ください。

　だが、マイグレーションやバックアップの話などが書けなかったので
続きの話を書きたいと思います。

マイグレーション

　xenserver5.6の魅力はマイグレーション機能が無償で
使えるようになった事だ。

　早速、マイグレーションの実験を行なう事にした。

マイグレーションの実験
2台のサーバーを用意して、その上にxenserver5.6と ゲストOS(Domai-U)を載せて、実際にサーバー間を 移動するかどうかの実験を行なう。

　さて、ここで読者の方から

　どないして2台の実験サーバーを用意したんや?

　と思われるかもしれません。

　大手でも予算が降りるのが難しいご時世、非IT企業の中小企業で
2台の実験サーバーを申請しても、あっさり却下されるのは目に見えている。
　なので、以下のような実験環境を作ったのだ。

マイグレーション実験の種明かし
VMware vSphere4.1で稼働している既存の2台のサーバーがあるので VMwareのゲストOSとしてxenserver5.6をインストールし、その上に ゲストOS(Domain-U)を載せました。 なので、あたかも2台の実験サーバーがあるように 仮想化ソフトを使って実現させたのだ。

　VMware vSphere4.1の上に、xenserver5.6をゲストOSとして載せると
見事に稼働する。
　そして、ゲストOSのゲストOSとしてCentOSを載せるのだが
これも見事に動く。親亀の背中に、子亀、孫亀の発想だ。

　ちなみに設定方法は以下の通りです。

VMware vSphere上の設定
ゲストOSとして載せるOSの種類の選択だが 「その他(64-bit)」を選択する。 xenserver5.6は64ビットCPUでないと稼働しないからだ。

　そしてゲストOSのメモリの量を設定するため、事前に以下の事を選択する。

VMware vSphere上の設定(2)
仮想マシンの編集を行なうので、印をつける。

　そしてゲストOSの仮想メモリの設定を行なう。

VMware vSphere上の設定(3)
仮想メモリの量を2G以上にする。ここでは2Gにした。 仮想CPUの数は1個で十分。

　これで実験環境が整った。
　いざ、実験を行なう。

　xenserverの管理ソフトxencenterを立ち上げて
実験用の2つのxenserverを登録する。

xencenterの画面
2つのxenserverを登録している。

　だが・・・

　どうやってマイグレーションするねん!!

　調べてみると、同じPool(プール)に入れないとダメだという。
　ネットワーク管理者の憂鬱な日常

　ところで・・・

　Poolって何やねん?

Poolとは
Poolとは複数のxenserverを、ひとまとめにして 管理する単位の事だ。

　というわけで、Pool作成を行なう。

Pool作成

　そしてPoolの名前を決める。

Poolの名前を決める

xenserverをPoolに登録
xenserverをPoolに登録に印
主となるxenserverがあり、それ以外の物に印をつけて Poolに参加するxenserverを登録する仕組みだ。

　いざ登録と思ったのだが・・・

　なんでエラーが発生するねん・・・ (--;;

エラーの内容
無償で使えるマイグレーションは、サーバー同士のCPUが 同じメーカーで、同じ種類でないと駄目だという。 異なるCPUを使っているxenserver同士のマイグレーションでは 有償版の購入が必要だという。

　マイグレーション無償は限定的だったのか!

　だからといって実験のためだけに有償版の購入をする事はできない。
　そこで、同じCPUのサーバーを2台用意する事にした。

同じCPUのサーバーで実験
xenserverを動かしているサーバーのCPUを同じにした。 これでマイグレーションの実験ができると思った。

　2台も同じCPUのサーバーを用意できるのかと言われると
そんな予算はあるわけがない。
　そこで・・・

　種明かしを紹介します!!

　というわけで、以下のような設定を行なった。

サーバーの設定
既存のVMware vSphereのマシンの上に、ゲストOSとして xenserver5.6を2個搭載してみた。 こうする事で、あたかも同じCPUを搭載したxenserver機を 2台あるようにしたのだ。

　これで実験再開!

xencenterの画面
xencenterの画面に、同じCPUのxenserverを2台 登録しておく。

　マイグレーションを行なうためPoolの作成をする。

Poolの作成開始

　そしてPoolの名前を決めた後、Poolへの登録を行なう。

Poolへの登録
主となるサーバーがxenserver3になっている。 そしてxenserver1を登録するという形になる。

　見事、Pool作成に成功!! (^^)

Pool作成に成功した様子

　早速、マイグレーションを行なうため、ゲストOSを稼働させる。

ゲストOSを稼働させた様子

　いよいよマイグレーションを行なってみる。

マイグレーションを行なってみる
拡大図
マイグレーションを選んでも、その先の選択肢が選べない状態になっている。 一体、どういう事?

　なんでマイグレーションができへんねん (TT)

　調べていくと以下の事がわかった。

　Adways Engineers' Blog
　PC便利手帳

　マイグレーションを行なうには共有ストレージの設定が必要なのだ。

マイグレーションと共有ストレージ
マイグレーションを行なう場合、ゲストOSの実体ファイルは 共有ストレージに保管しておく必要がある。 共有ストレージは、iSCSIだったり、NFSサーバーだったりする。

　手軽に共有ストレージを構築するため、NFSサーバーを構築して
それを共有ストレージにする事にし、以下の構成で実験する事にした。

共有ストレージを使ったマイグレーション実験
NFSサーバーを共有ストレージにして、そこにゲストOSを保管。 マイグレーションの実験を行なう事にした。

　3台のサーバーが必要なのだが、ここでも種明かし。
　以下の設定をしています。

共有ストレージを使った実験方法
既存の1台のVMware vSphereサーバーの上に2つのxenserverと NFSサーバー用のゲストOS、CentOSを載せました。 これで、あたかも3台のサーバーがあるようにしています。

　さて、実験準備だ。

共有ストレージとしてNFSサーバー構築

　まずはNFSサーバーの構築から行なう事にした。

　CentOS5.4でNFSサーバーを構築。
　初期状態でNFSに関するデーモンがインストールされている。

　実は、もう1つ必要なデーモンがあるのだが、そんな事、知るわけのない私。

　そんな時は以下の本を使う。
　「CentOS5で作るネットワーク構築ガイド」(サーバー構築研究会:秀和システム)

　お得意の本の丸写しを行なう。


　まずは、NFSサーバー側の設定。
　どのディレクトリーを共有させるのかの設定ファイルを障る。

/home/test 192.168.X.0/255.255.255.0(rw,no_root_squash,sync)

　これで良しと思った。
　そしてクライアント側でマウントを行なうのだが・・・

[root@client]# mount -t nfs -o nfsvers=3 nfsserver:/home/test /mnt/nfs
mount.nfs: Input/output error
[root@client]# 

　なんでエラーが出るねん (--;;

　調べてみると、クライアント、サーバー双方に立ち上げ必要な
デーモンが必要だというのがわかった。

　portmapデーモンなのだ!

　セキュリティー上、好ましくないデーモンなので
いつもCentOSをインストールしたら、停止させていたのだが
NFSサーバーとクライアントを構築するのは必要なデーモンなのだ。

portmapデーモンはRPCサービスプログラムに動的にTCP/UDPポート番号を
割り当てるためのプロトコルだという。
NFSで通信を行なう際、動的に割り当てられたポート番号を使うため
ポート番号を割り当てるportmapの役目が欠かせないという。

　そこでクライアント、サーバー双方でportmapデーモンを起動させて
再度、マウントを行なってみた。

[root@client]# mount -t nfs -o nfsvers=3 nfsserver:/home/test /mnt/nfs
[root@client]# 

　今度は成功なのだ! (^^)

　これでNFSサーバーの構築ができた。

　ここで整理すると、NFSサーバーに必要なデーモンを表にすると
以下のようになる。

　共有ストレージを使ったマイグレーションの実験の再開だ。

共有ストレージを使ったマイグレーション実験

　まずは、2つのxenserverを同じPoolにいれておく。

2つのxenserverを用意する
マイグレーションを行なうため同じPoolに入れておく。

　そしてゲストOSの実体をインストールする先の
共有ストレージを追加する作業を行なう。

共有ストレージの追加作業

　そして共有ストレージの種類を選択する。

共有ストレージの選択
今回の実験では、共有ストレージはNFSサーバーを使うので ここでは共有ストレージは「NFS VHD」を選択する。

　そしてNFSサーバーの指定を行なう。

NFSサーバーの指定を行なう
NFSサーバーのホスト名とマウントするディレクトリ指定を行なう。

　すると・・・

　無事、NFSサーバーが認識できた!!

共有ストレージの追加成功画面

　これで下準備が完成した。
　次にゲストOSを共有ストレージにインストールする作業を開始する。

ゲストOSインストール開始

　ゲストOSをインストールする場所(どのxenserver上なのか)の
選択を行なう。

インストール先の選択(1)
ゲストOSを、同じPool内の、どのxenserver上に インストールするのか選択する画面だ。

　インストール先のディスクとして、共有ストレージの
NFSサーバーを選択する。

インストール先の選択(2)
インストール先のディスクの選択。 ローカルのディスクか、共有ストレージの選択になるが ここでは迷わず、共有ストレージのNFSサーバーを選択する。

　そしてゲストOSのインストール開始。
　インストールの途中過程は省略します。

　インストール終了後の画面は以下のようになる。

ゲストOSのインストール終了後

　あとはゲストOSを起動させれば準備完了だ。

マイグレーションを行なう

　マイグレーション実験のための準備が整った。

マイグレーション実験前
xenserver1上にあるゲストOSを、マイグレーションを使って xenserver3へ移動させる実験だ。

　早速、マイグレーション開始だ。

マイグレーションの選択
マイグレーションでの移動先を選択すれば マイグレーションが開始される。

　マイグレーション中だ。
　この時、ゲストOSは停止する事なく、稼働するため

マイグレーション中の画面(1)
マイグレーション中であっても、コンソール画面で 普通に入力できるので、思わず「おー！」と声を出したくなる。 ゲストOSがWindowsXPで、しかも動画を動かしながら マイグレーションを行なえば、より一層わかりやすいのだが VMware vSphere上にxenserverを載せているため xenserverはCPUが仮想化支援(VT)のCPUという認識がないため ゲストOSとしてWindowsが搭載できないのが残念。 もし、ゲストOSがWindowsでマイグレーションを行なえば もっと驚きが得られるかもしれない。

　マイグレーションの進捗状況も見れる。

マイグレーションの進捗状況
xenserver1からxenserver3への移動状況が見れる。

　マイグレーションが完了するまで時間がかからない。
　あっという間なのだが、実際にやってみて

　感激なのだ!!

　になる。

異なるバージョンのハイパーバイザ同士の場合は

　この原稿を書いている時(2010/12/17)に、衝撃が起こった。

　xenserver5.6 fp1版が出たのらー!!

　なんて事だ。ここまで原稿を書きているのに、変更箇所があったら
台無しやん・・・。

　でも、あまり変更箇所がなかった上、1つネタができた。

　バージョンが異なるxenserver同士では・・・

　マイグレーションが可能なのか?

　それを確かめるための実験を行なう事にした。

実験のためのサーバー構成
マイグレーションを行なうには、ゲストOSの実体を共有ストレージに 保管しておく必要があるので、NFSサーバー上に置く事にした。 ゲストOSの移動元のサーバーには旧バージョンのxenserver5.6。 移動先のサーバーには新バージョンのxenserver5.6fp1にした。

　もちろん、3台のサーバーなんぞあるわけないので
以下のように仮想化技術を応用している。

サーバー構成の種あかし
1台のサーバーのvmware vSphere上にxenserver5.6、xensever5.6fp1 そしてNFSサーバーを載せて、実験を行なった。

　xencenterを動かしてみる。

xencenterの画面
ゲストOSの移動元のxenserver5.6と 移動先のxenserver5.6fp1がある。 まだ、Poolができていない状態だ。

 マイグレーションを可能にするため、2つのxenserverを
同じPoolに入れる作業を行なうのだが・・・

　Poolが作られへんやん!!

エラー表示
エラー内容を見ると、2つのxenserverが異なるバージョン同士なので 同じPoolに入れる事ができないというのだ。

　バージョンアップの場合、注意が必要なのがわかった。

マイグレーションのまとめ

　残念ながら、今のうちの会社では、サーバーの問題から
実用化は不可能で実験しかできなかったが、操作手順は簡単に
できる事がわかった。

　ここで、マイグレーションの、おさらいをしますと

ゲストOSのバックアップと復元

　ゲストOSのバックアップと復元は大事な話になってくる。
　単にバックアップだけでなく、マイグレーションが使えない場合
ゲストOSを他のxenserverに移動させる場合などに有効だ。

バックアップ

　バックアップだが、以下のような方法になる。

バックアップの方法
xenserverを管理するxencenterが入ったパソコンのハードディスクに バックアップデータを落とし込む形になる。

　まずはバックアップを取るゲストOSを停止させる。

ゲストOSの停止を行なう

　ゲストOSが停止した所で、バックアップの開始だ。

バックアップ開始
「Export as Backup」を選択する。

　バックアップの保管場所を指定する。

バックアップの保管場所の指定
xencenterを動かしているWindowsパソコンに バックアップデータが保管される。 どのフォルダーに落とし込むのかを指定するのだ。

　バックアップが始まった。

バックアップ中の様子
ゲストOSの色が黄色になっている。

　そしてバックアップの進行状況も見る事ができる。

バックアップの進行状況

　バックアップ完了後、xencenterを動かしているパソコンで
バックアップデータを保管したフォルダーを見てみる。

バックアップデータを保管したフォルダー
わかりやすいアイコンで保管されている。

　バックアップを取るのは簡単にできた。

データの復元

　バックアップするからには、復元ができなくては意味がない。
　そこでゲストOSのバックアップデータを復元してみる。

復元方法
xencenter上に保管したゲストOSのバックアップデータを xenserver上に復元する形になる。

　復元する様子を見るため、xenserver上にゲストOSがない状態にしておく。

xenserver上にゲストOSがない状態
xenserver上にゲストOSがない状態だ。

　そして復元するデータを取り込む作業にかかる。

復元開始の準備
「import」を選択する。

　そして復元するデータが格納された場所を指定する。

復元するデータが格納された場所を指定
赤く囲んだ「Browes」を押して、バックアップデータが 格納されたフォルダーを指定する。

　そして復元するバックアップデータを取り込む。

バックアップデータを選択する
CentOS5.4のゲストOSをバックアップデータとして保管しているので それを復元してみる。

　復元したいゲストOSのバックアップデータの選択すると
以下の画面になる。

復元開始前の画面

　次に、復元先のxenserverの選択を行なう。

復元先のxenserverの選択
ここではxenserverは1つしかないので、そのまま選ぶ。

　そして復元先のディスクを選択する。

復元先のディスクを選択
xenserver上のディスクしか選択肢がないので、それを選ぶ。 共有ストレージなどがある場合は、それらを選択する事も可能だ。

　次にゲストOSが使う仮想ネットワークカードの設定だ。

仮想ネットワークカードの設定
そのまま「Next>」を押す。

　いよいよバックアップデータの復元開始準備の最終段階だ。

バックアップデータの復元開始準備の最終段階
赤く囲んでいる部分は復元後、すぐにゲストOSを稼働させるかの 印なのだ。初期状態では印が付いた状態になっている。

　復元中の様子だ。

バックアップデータの復元中

　復元も簡単にできた。


xenserver tools

　「システム奮闘記:その88」(xenserverのインストール入門)でも
取り上げましたが、ゲストOSにxenserver toolsをインストールすれば、
以下の利点があるという。

ネットワークとディスクのデバイスドライバを
準仮想化デバイスドライバに置き換えて
ネットワークやディスクの入出力(I/O)を高速化する

これはシトリックス社の以下のサイトに書いていました。
XenServer Toolsのインストール

　準仮想化デバイスドライバって何やねん

　なので調べていく事にした。

　すると・・・

　完全仮想化の際に威力を発揮する!

　事がわかった。

　それを理解するには、準仮想化と完全仮想化の違いを知る必要があった。

準仮想化と完全仮想化

　xenserver tools をインストールする理由とは別に
仮想化の話を調べていくと、次の事にぶつかった。

　準仮想化の方がゲストOSの性能が良い!

　完全仮想化の場合、色々な負荷がかかって、ゲストOSの性能が
発揮できないというのだが・・・

　仮想化支援CPUがあるのに何でやねん?

　という疑問を持っていた。


　そんな疑問を持ちながら、xenの勉強のため、以下の本を読んでいた時だった。
　「Xen徹底入門」(宮本久仁男、大島孝子、平 初、長谷川 猛)

　完全仮想化の章で、ドライバの話の所で「QEMU」の文字を見た

　QEMUって何やねん!!

　本にはオ−プンソース版のデバイスエミュレーションエンジンだと
書かれている。

　デバイスエミュレーションエンジンって何やねん!

　Wikiペディアを見たら、次のような説明だった。

　イマイチ、わからへん (--;;

　わかったような、わからないようなモヤモヤ状態。
　つまり、全然、理解していないのだ。

　IBMのサイトにも説明があった。
　QEMU によるシステムのエミュレーション

　まだピンと来ない・・・ (--;;

　頭の中で、全然、話が整理できない状態。
　つまり、理解していないのだ。


　いくつかのサイトを見ていくと、以下のような事をするみたいだ。

命令を変換する役目
ゲストOSの命令をホストOSがハードウェアに命令できるよう ゲストOSの命令を変換するのがQEMUの役目のようだ。

　もっと調べていくと、CPUのエミューレートの話を発見する。
　CPUのエミュレートとは以下の意味だというのがわかった。

CPUのエミュレーションとは
例えば、非x86系CPUで動く組込み系Linuxがあったとする。 だけど、それを動かすためのハードウェアがなく 手軽使えるx86CPUのパソコン上の環境で動かしたい場合がある。

　そんな場合、QEMUのCPUエミュレーション機能が役に立つ

QEMUのCPUエミュレーション機能
x86系CPU上で動くLinuxに、非x86系CPUで動く組み込みLinuxを 載せて動かす時、非x86CPU命令を変換するのにQEMUが使われる。 土台になるOSを、非x86CPUでも動くハードウェアのふりをさせるための ソフトがQEMUなのだ。

　QEMUについて、少しづつ見えてきた。
　そんな中、@ITのサイトで以下のページを発見した。

　実践！ Xenで実現するサーバ統合 (1)インストールと環境構築

　xenで仮想化技術を実現する際に、QEMUの役目を図にしている。

　完全仮想化の場合、QEMUが使われているのだ!

　一体、どういう仕組みなのか、サイトにある図をの丸写ししてみた。

準仮想化のハードウェア操作の仕組み(I/O以外)
ゲストOSの命令がCPU特権命令だったり 割り込みコントローラーに関する場合 xen(ハイパーバイザー)がハードウェア操作を行なう。

　ハードディスクやネットワークなどの入出力(I/O)命令の場合は
以下の仕組みになる。

準仮想化のハードウェア操作の仕組み(I/Oの場合)
ハードディスクやネットワークなどへの入出力(I/O)命令は xen(ハイパーバイザー)が管理OSに対して、命令処理を依頼し 管理OSがそれを処理する形になる。

　完全仮想化の場合、準仮想化とは異なる仕組みで
処理を行なうというのだ。
　

完全仮想化のハードウェア操作の仕組み(I/O以外)
ゲストOSからの命令が直接、ハードウェアにいく。 CPUが命令を補足して、それをxen(ハイパーバイザー)に転送し ハイパーバイザーが命令を行なう。

完全仮想化のハードウェア操作の仕組み(I/Oの場合)
ゲストOSからの命令が直接、ハードウェアへいく。 CPUは命令を補足して、それをxen(ハイパーバイザ)に転送し ハイパーバイザーは管理OSに転送して、管理OS上で動いている QEMUで命令を変換して、それをハードウェアに送っている。 QEMUで変換処理が、大きな負荷になっている。

　イマイチ、QEMUの役目が見えてこないのだが、少なくとも

　QEMUが大きな負荷である!

　という事だけはわかった。


　xen徹底入門には、完全仮想化で動くドメイン(HVM Domain)で
提供可能なデバイスが書いている。

　最初、この表を見た時は、イマイチ、よくわからなかったが
完全仮想化の話などを見ていくうちに

　わかった!!

　になった。

　つまり上の表を図式化すると以下のようになる。

QEMUがPCエミュレーターと言われる理由
QEMUは類似デバイスを提供している。 ゲストOSは、類似デバイスを本物のデバイスと認識して 入出力(I/O)処理を行なう。ゲストOSにとって あたかも本物のパソコンがあるかのように見せているため QEMUがPCエミュレーターと呼ばれるのだ。 より多くのOSが認識できるように、多く出回っているハードウェアの 類似デバイスドライバを用意している。 QEMUがエミュレーションできるデバイスとは、QEMUが用意している 「ハードウェアメーカが提供している物に類似したデバイス」なのだ。

　ホストOSとゲストOSとの間でやりとりされる入出力(I/O)命令は
各種・類似デバイスを経由してQEMUが変換するため

　大きな負荷がかかる!!

　というのが納得できた。


　実際に、ゲストOSから見える類似デバイスは、どうなっているのか
見てみたいのだが・・・

　xenserverで完全仮想化できる環境がないのらー

　というわけで、物理的な問題のため、概略を把握するだけで
止まってしまった (--;;

準仮想化とデバイスについて

　ところで準仮想化の場合、デバイスはどうなっているのか。
　そんな疑問が出てくる。

　そこでゲストOS上でハードウェア情報を見るlspciコマンドを使ってみた。

[root@guestOS]# /sbin/lspci
[root@guestOS]# 

　何も表示されないので・・・

　なんでやねん・・・

　と思った。


　調べてみると、準仮想化の場合、ゲストOSは改造されているため
ゲストOSの入出力部分の構造が異なるためのようだ。

準仮想化の場合の入出力(I/O)の方法
ゲストOS(Domain-U)側にはフロントエンドドライバがあり 管理OS(Domain-0)側にはバックエンドドライバがある。 XenBusと呼ばれるデータバス(データ通信経路)を使って 管理OSとゲストOSとのやりとりがあるが、その両端を バックエンドドライバ(管理OS側)、フロントエンドドライバ (ゲストOS側)と呼んでいる。 準仮想化の場合、管理OSとゲストOSのデータ通信を 直接、やりとりするため、ゲストOS側の修正が必要になると いうわけなのだ。 完全仮想化のようにQEMUのようなエミュレータでデータ変換せず 直接、データのやりとりを行なうため、変換の際の負荷がかからないため 準仮想化の場合、ゲストOSの性能が発揮できるというのだ。

　実際に、準仮想化の場合のゲストOSから別のコマンドで
ハードウェア情報を見てみる事にした。

[root@guestOS]# dmesg
Linux version 2.6.18-164.el5xen (mockbuild@builder16.centos.org) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)) #1 SMP Thu Sep 3 04:47:32 EDT 2009
BIOS-provided physical RAM map:
 Xen: 0000000000000000 - 0000000020000000 (usable)
0MB HIGHMEM available.
512MB LOWMEM available.
NX (Execute Disable) protection: active

(途中、省略)

TCP bic registered
Initializing IPsec netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
Using IPI No-Shortcut mode
XENBUS: Device with no driver: device/vbd/51712
XENBUS: Device with no driver: device/vif/0
Initalizing network drop monitor service
Freeing unused kernel memory: 176k freed
Write protecting the kernel read-only data: 390k
ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
USB Universal Host Controller Interface driver v3.0

(途中、省略)

Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM TTY layer initialized
Bluetooth: RFCOMM ver 1.8
[root@guestOS]# 

青い部分のディスクの入出力と、赤い部分のネットワークの入出力だが
XenBusという通信経路を使っているのがわかる。
しかも、両方共ドライバを使っていないのだ。

まさに管理OS(Domain-0)とゲストOS(Domain-U)の通信が
データを変換しないで、直接、やりとりしているようだ。

　紆余曲折(?)しながらも・・・

　準仮想化と完全仮想化の違いが見えてきた!

　だった。
　そして、完全仮想化の場合、入出力の場合、QEMUで命令を変換して
やりとりを行なうため、負荷がかかる事がわかった。

　そこで完全仮想化の性能をあげるためにできたのが

　準仮想化デバイスドライバなのだ!!

　カタカナ用語の「パラバーチャルデバイスドライバ」(PV)という
言葉も出ている。ややこしい・・・ (--;;

完全仮想化のゲストOSに 準仮想化デバイスドライバをインストールすると
ゲストOSに準仮想化デバイスドライバをインストールする。 準仮想化デバイスドライバは、管理OSとゲストOSとの 入出力(I/O)命令といったデータ通信を直接、やりとりするための ドライバなのだ。 QEMUを介する事がないので、その分、負荷も軽くなり 結果、ゲストOSの性能が向上するというわけだ。

　そして準仮想化デバイスドライバをインストールする事で
完全仮想化の場合でも、入出力の仕組みが以下のような仕組みになる。

完全仮想化のゲストOSに準仮想化デバイスドライバを インストールするハードウェア操作の仕組み(I/Oの場合)が変わる
準仮想化デバイスドライバをインストールする事で 入出力(I/O)が伴ったハードウェア操作の仕組みが 準仮想化の場合と同じ仕組みになる。 ゲストOSからの入出力命令が直接ハードウェアへ行き それをCPUが捕捉して、ハイパーバイザーに転送するという 処理がなくなるのだ。

　つまり・・・

　CPUによる捕捉がなくなる!

　というわけで、その部分でも負荷が軽くなるというのだ。

仮想化支援CPUの復習

　ところで、完全仮想化の事で調べている間に、次の疑問がふと出てきた。

　ゲストOSからの命令をCPUが捕えるため

　CPU捕捉は負荷はならないのか?

　だった。

完全仮想化の場合、CPUがゲストOSの命令を捕捉する
完全仮想化のハードウェア操作の仕組み(I/O以外)
完全仮想化のハードウェア操作の仕組み(I/Oの場合)
どちらの場合でも、ゲストOSの命令をCPUが捕捉して xen(ハイパーバイザー)に転送したりしている。 そのため、ゲストOSが出す入出力命令を CPUが捕捉するのに負荷がかからないのだろうかと疑問に思った。

 実は仮想化支援対応CPU(VT)によって負担が軽減されているのだが
すっかり話を忘れてしまった私。

　そこで「システム奮闘記:その79」(VMwareESXiの仕組みと運用)を読み返した。

　xenserverでの完全仮想化の場合、仮想化支援CPUの力を借りている。
　そこで仮想化支援CPUの仕組みを復習してみた。

仮想化支援対応CPU(VT)が不要の場合 (VMwareESXiの場合の完全仮想化の場合)
レベル1のゲストOSは特権命令を発行してもレベル0の段階で 例外処理が発生する。 仮想化ソフトは、例外処理が発生するのを監視して 例外処理が発生した時に、ゲストOSが発行した特権命令を拾い上げ それの処理を行う事で、ゲストOSの命令を実行させている。

　例外処理を捕捉するため、負荷がかかると言われているのだ。
　VMware社は、この方法でも負荷がかからないという技術を
確立しているため、仮想化支援CPUを使わなくても良いというのだ。


　さて、xen(xenserver)の場合、仮想化支援CPU(VT)を使って
完全仮想化を実現している。仮想化支援CPU(VT)は以下の仕組みになっている。

仮想化支援対応CPU(VT)を使った場合の完全仮想化 xen(xenserver)の場合の完全仮想化
ゲストOSは、レベル0の状態で稼働させ、 仮想化ソフトをVMXrootの状態で稼働させる。 そして実際の特権命令をVMXrootの状態に移して 実行させるという仕組みだ。

　ゲストOSが使っているCPUモードで特権命令を出した場合
CPUが自動的に仮想化ソフトに転送する仕組みになっている。

　そのためソフト的に例外処理を発生して、それを捕捉して
仮想化ソフトに転送するよりかは負荷が軽くなっているが
それでも準仮想化と違い、CPUに余分な負荷がかかっているのだ。

　なので・・・

　準仮想化の方が性能が良いと言われる!

　そして完全仮想化の場合、ゲストOSの性能を発揮させるためにも

　準仮想化ドライバをインストールすべし!

　なのだ。


　準仮想化と完全仮想化の違いについて参考にした資料を紹介します。

　NTT技術ジャーナル2009.8号の【オ−プンソース仮想化技術】
　NTT1技術ジャーナルのバックナンバー

完全仮想化のゲストOSの入出力(I/O)を高速化するために
準仮想化デバイスドライバを使う事を書きましたが
全ての入出力について準仮想化デバイスドライバが使われるわけではありません。

キーボード、マウスなどは高速化の必要がないためか
準仮想化ドライバが用意されていないみたいです。

xenの仕組み:ハイパーバイザーと管理OSの役割分担

　IBMが提供しているxenの準仮想化についての資料を読んでいた時
xenと管理OSが上手に役割分担を知った。

　Xen ハイパーバイザー準仮想化モードの内部構造入門(PDFファイル)

　IBMが提供しているxenの資料には、役割分担の理由が
以下のように書いてあった

　役割分担について資料に基づいてに図にすると以下のようになる。

xen:ハイパーバイザーと管理OSの役割分担
入出力やデバイスドライバは管理OSが司る。 各種ゲストOSの構成情報も管理OSが持っている。 仮想CPUスケジューリング、割り込み処理、メモリ管理は ハイパーバイザーのxenが行なっている。

　これを他のハイパーバイザー型の仮想化ソフトの
VMwareESXi(VMware vSphere)を比較してみる。

VMwareESXi(VMware vSphere)の場合
そもそもxen(xenserver)のように管理OSが存在しない。 そのためハイパーバイザーが仮想OSの構成情報から デバイスドライバまで持つ形になる。

　比較して所で、xenの利点をあげてみます。
　一番わかりやすい(私がすぐに理解できた)例として
デバイスドライバの部分だ。

　xen(xenserver)の管理OSはLinuxだ。
　なので・・・

　多種多様のデバイスドライバが用意されている!

　そのため、わざわざxen(xenserver)側でデバイスドライバを
用意する必要もないし、Linuxのデバイスドライバの開発に任せておけば
独自でドライバの開発をする必要がないので、開発効率は向上する。

　だが、VMwareESXiの場合、独自でデバイスドライバの開発を
行なう必要がある上、Linuxのように世界中に多くの開発者が
いるわけでないので、限定された範囲でのドライバの提供になる。
　そのため・・・

　VMwareESXiが使えるハードウェアは限定的になる!

　他の機能については、踏み込んでいくだけの知識がないので
割愛しますが、以下の事は言えると思う。

　管理OSのLinuxが既に持っている機能は、上手に利用して
ハイパーバイザーでしか、できない事はハイパーバーザーで行なう。

　上手な役割分担なのだ。


最後に

　「システム奮闘記:その88」の続編として、xenserver5.6の
マイグレーション機能やバックアップの方法や
準仮想化ドライバの話をまとめてみました。

　xenやxenserverを掘り下げると、色々な事が出てきそうですが
奥が深いだけに、なかなか踏み込んだ部分まで勉強して
それを書くのは困難というのが実感です。


　マイグレーションの無償化ですが、同じCPUのサーバーでないと
無償版が使えない上、共有ストレージを使う事も条件のため
予算の制約が大きい中小企業には、向いているかといえば
かなり疑問の感じがしました。