2009年11月19日木曜日

デグレード後使えなくなっていたZFSプールのインポートに成功

OpenSolaris 2009.06 で、Degrade ステータスとなった ZFS プールをインポートできなくなり
困っていたのですが、先ほど紹介した ZFS プールの rewind 機能を試したら無事マウントできるようになりました。

実はディスクを3台収容できるエンクロージャに物理的な障害が発生し 3本中1本のディスクが認識できなくなりました。冗長性を失ったままずっと動いていたのですが、障害原因の切り分けを行うべく OpenSolaris を停止したところ二度と import できなくなり、2ヶ月ほど放置してあったものです。

root@opensolaris:~# zpool import
  pool: array1
    id: 12644204788362156509
 state: DEGRADED
status: The pool was last accessed by another system.
action: The pool can be imported despite missing or damaged devices.  The
        fault tolerance of the pool may be compromised if imported.
   see: http://www.sun.com/msg/ZFS-8000-EY
config:

        array1        DEGRADED
          raidz1      DEGRADED
            c5t0d0p1  ONLINE
            c5t1d0p1  FAULTED  corrupted data
            c4t1d0p1  ONLINE

2009/11/6付の ONNV では同じ操作をするとこんな感じ。ステータス表記が DEGRADED から FAULTED に変更されるなど、メッセージにいくらかの変更があります。

root@opensolaris:~# zpool import
  pool: array1
    id: 12644204788362156509
 state: FAULTED
status: The pool was last accessed by another system.
action: The pool cannot be imported due to damaged devices or data.
        The pool may be active on another system, but can be imported using
        the '-f' flag.
   see: http://www.sun.com/msg/ZFS-8000-EY
config:

        array1        FAULTED  corrupted data
          raidz1-0    FAULTED  corrupted data
            c5t0d0p1  ONLINE
            c5t1d0p1  FAULTED  corrupted data
            c4t1d0p1  ONLINE


これまでインポートできなかった ZFS プール array1 ですが、無事インポートできるようになりました。 cannot share ... のメッセージが表示されていますが、これは iSCSI ターゲットのパッケージが入っておらずサービスが復旧できないために表示されており、 ZFS プールとしてはきちんとオンラインになっています。

root@opensolaris:~# zpool import -Ff array1
cannot share 'array1/timemachine': iscsitgtd failed request to share
cannot share 'array1/iscsi/elena4': iscsitgtd failed request to share

ちなみに -F オプションなしだと下記のようにエラーが表示されました。
プールを作り直せとメッセージが表示されるようになったのは最近のことです。
おそらくインポートできなくなったプールに関する問い合わせが相次いでいたのでしょうね。:-)

root@opensolaris:~# zpool import -f array1
cannot import 'array1': one or more devices is currently unavailable
        Destroy and re-create the pool from
        a backup source.



ZFSに、直近書き込み内容をロールバックする機能が搭載された?

マイコミジャーナルで先日掲載されていた「ZFSにはfsckが必要?」で ZFS にも fsck 的なツールが必要ではないかというお話が書かれていましたが、今日なんとなく ZFS のソースコードを見ていて目にとまったネタがあるので紹介します。


http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/zpool/zpool_main.c


   1556 /*
   1557  * zpool import [-d dir] [-D]
   1558  *       import [-o mntopts] [-o prop=value] ... [-R root] [-D]
   1559  *              [-d dir | -c cachefile] [-f] -a
   1560  *       import [-o mntopts] [-o prop=value] ... [-R root] [-D]
   1561  *              [-d dir | -c cachefile] [-f] [-n] [-F] <pool | id> [newpool]
   (..snip..)
   1582  *       -f Force import, even if it appears that the pool is active.
   1583  *
   1584  *       -F     Attempt rewind if necessary.
   1585  *

zpool import コマンドのオプションとして、必要であれば rewind するというオプションができたようです。細かくは語られていませんが、おそらく ZFS の領域を正しくマウントできなかった場合に、いくらか直近の書き込みをロールバックしてマウントを試みる機能のように思われます。

現状 zpool import でインポートできない ZFS プールを復旧する手段は特に用意されていないようですが、この rewind オプションに対応した ZFS モジュールとコマンドが一般的に使えるようになれば、RAID やライトキャッシュのせいでインポートできなくなった ZFS プールに対する手段となるのかもしれません。


というわけで OpenSolaris に最新の ONNV を適用する方法について調査中な私でした。


2009年11月10日火曜日

VMware ESXに関連する通信をまとめた図

Firewall diagram – updated to version 3に、VMware ESXを中心に関連する通信が1枚のシートに整理されています。

これは、ファイアウォール ルールの設計に便利ですね。


2009年10月29日木曜日

仮想化友の会 in OSC2009 Tokyo/Fall

10/30(金), 31(土)と開催される OSC2009 Tokyo/Fall に仮想化友の会として出展予定です。
最初私もセミナーコマ貰おうと思ってたけど、殿がスゲェたくさんスライド作ってたから(wじっと見守ることにします、、、


■ セミナー枠


2009-10-31 (土) 仮想化友の会 「濃ぃ~い話」(通称濃いバナ)
担当者 risa 登録日時 2009-09-30 14:28 (457 ヒット)

講師:平 初、他(調整中)
担当:仮想化友の会
対象者:仮想化を愛するすべての仮想人(かそんちゅ)

『仮想化インフラをプログラミングする libvirt 入門』(平 初)
Xen、KVM、QEMUなど様々な仮想化ソフトウェアを制御できる仕組み。それがlibvirtです。
このセッションでは、libvirt の仕組みと、簡単なサンプルを交えてご紹介します。

『Vnet - その概要と実例』(wakatono)
Vnetは、Xen 2.0で追加された仮想ネットワーク機能です。
ここでは、Vnetを構成する技術とその使い方、そして注意点について解説を行います。

http://www.ospn.jp/osc2009-fall/modules/eguide/event.php?eid=74 より転載





■ 展示



  • KVM (Kernel-mode Virtual Machine) を利用したデモを準備予定。
    今、自宅でデモ機が暴れてます、、、ふがふがふが


■ 物販ほか


『Xen徹底入門 第2版 発刊記念セール』

仮想化書籍してはVMware徹底入門の次に売れている(らしい)Xen徹底入門。
翔泳社ブースも出てるのに、空気読まずに刷りたてホヤホヤの第2版を一冊3,000円(17%OFF)で特別販売します。特別販売は今回っきりです(楽しいけど大変なので……)。購入予定の方はこの機会をお見逃しなく。

※ちなみに翔泳社ブースは10% OFFだとか。


なお、土曜日にはXen徹底入門 第2版の著者陣が総集合。書籍の内容について問い詰めたり、仮想化技術最前線の平さん&宮本さんにサインをおねだりするならチャンスです。


2009年10月27日火曜日

nographic

 仮想フレームバッファ(VFB)を利用するかどうかを指定します。フレームバッファが不要な場合は0 を指定します。

 本パラメータが有効となっている場合、仮想マシンマネージャ(virt-manager)や仮想マシンコンソール(virt-viewer)からグラフィックコンソールを利用できません(シリアルコンソールのみとなります)。


■ ドメイン


  • 準仮想化ドメイン(PV)

  • 完全仮想化ドメイン(HVM)


■ 書式

nographic=<n>


■ <n>の値の例


  • 0 …… 無効

  • 1 …… 有効


■ 例

nographic=1


■ 注意点


  • nographic=1 の場合のみ有効です。

  • 本情報はXen 3.4.0時点の内容です


■ 参考





paused

 ドメイン作成時にドメインの実行を開始せず、一時停止状態とします。

 デフォルトでは、ドメイン生成時(xm createコマンドなど)、作成されたドメインはその時点で実行を開始します。本パラメータを有効にすると、ドメイン作成後に実行を開始せず、最初から一時停止状態となります。


■ ドメイン


  • 準仮想化ドメイン(PV)

  • 完全仮想化ドメイン(HVM)


■ 書式

paused=<n>


■ <n>の値の例


  • 0 …… ドメイン作成時、実行を開始する

  • 1 …… ドメイン作成時、ポーズ状態にする


■ 例

paused=1


■ 注意点


  • 本情報はXen 3.4.0時点の内容です


■ 参考





2009年10月24日土曜日

usbdevice

 USB マウスのエミュレーション方式を指定します。ペンタブレットのエミュレーション(tablet)は、マウスポインタの絶対位置をエミュレートします。


■ ドメイン


  • 完全仮想化ドメイン(HVM)


■ 書式

usbdevice='<type>'


■ <type>の値の例


  • mouse …… 一般的なマウスをエミュレート

  • tablet …… ペンタブレットをエミュレート


■ 例

usbdevice='tablet'


■ 注意点


  • 画面上でのゲストOS のポインタ操作性が向上するので、tablet の指定を推奨します。

  • 本情報はXen 3.4.0時点の内容です


■ 参考






usb

 USB デバイスのサポートを有効化します。


■ ドメイン


  • 完全仮想化ドメイン(HVM)


■ 書式

usb=<n>


■ <n>の値の例


  • 0 …… 無効

  • 1 …… 有効


■ 例

usb=1


■ 注意点


  • 本情報はXen 3.4.0時点の内容です


■ 参考






2009年10月23日金曜日

rtc_timeoffset

 ゲストに供給する時刻を、Domain-0 の時刻からのオフセット(単位:秒)で指定
します。


■ ドメイン


  • 準仮想化ドメイン(PV)

  • 完全仮想化ドメイン(HVM)


■ 書式

rtc_timeoffset=<n>


■ <n>の代表的な値


  • 0 …… 協定世界時(UTC)

  • 32400 …… 日本標準時(JST)



■ 例

localtime=0
rtc_timeoffset=32400



■ 注意点


  • localtime=1 が設定されている場合、この値は無視されます。

  • Xen 3.1.3(3.1.x)以降


■ 参考





localtime

 ゲストに供給する時刻情報のタイムゾーンを指定します。システムクロックを協定世界時で運用できるOSであれば0 もしくは1、Windows などのシステムクロックが現地時間である必要があるOSでは1を設定します。


■ ドメイン


  • 準仮想化ドメイン(PV)

  • 完全仮想化ドメイン(HVM)


■ 書式

localtime=<n>


■ <n>の値


  • 0 …… 協定世界時(UTC)

  • 1 …… ローカル時刻



2009年10月22日木曜日

そのマザーボードは本当にVT-d対応か?

(2011/1/16) 一部加筆修正


IA向けの新しい仮想化支援機能としてVT-dと呼ばれる機能があります。

VT-dとは、仮想化されたゲスト環境から物理的なハードウェアを直接認識・アクセスするための機能を提供するものです。VT-dを利用することで、たとえばゲストOSとして動作するOSがSATAやSAS、SCSIなどのコントローラを直接認識させると、ゲストOSは仮想化しない場合と同じ方法でコントローラを制御でき、一般的にパフォーマンスが向上します。

VT-dは、CPUの特権リングの拡張であるVT-xやAMD-Vとはまた別の、CPUとチップセットで実現される機能です。したがって、VT-dの実装はVT-d対応CPUを利用しているか、チップセットおよびBIOSがVT-d対応か否かに依存します。


■ VT-dに対応した製品の判断方法


現状、現在VT-dをサポートするマザーボードは非常に数が限られています。特定モデルの製品がVT-dに対応しているか否かを判断するには、現状Xen WikiVTdHowToページを参照し判断する方法が堅実です。


現状、 Core2 プロセッサに対応した VT-d 対応チップセットは Q35/Q45 に限られています。これらのチップセットはオフィス向けクライアントへの利用を想定したもので流通量が限られています。

Nehalem(Xeon 5500ライン)用チップセット、およびCore i7など向けのX38/X48チップセットはVT-dをサポートしています。ただし、一部マザーボードはBIOSがVT-dに対応していない場合があるようなので、やはり注意が必要です。


■ チップセットがVT-dに対応していない場合でもVT-dオプションがBIOSセットアップに表示されることがあるので注意

一部のマザーボードでは、VT-dに対応しないチップセットを搭載しているにもかかわらず、BIOSセットアップ上にVT-dの選択肢が表示されるモデルがあるので要注意です。

具体例として、 Intel DQ43AP は Q43 チップセットを搭載したモデルですが、 BIOS セットアップ上では VT-d の選択肢を Enabled に設定できてしまいます。

Intel のサイト
で参照できるデータシートによれば、このチップセットには VT-d に関連するレジスタが実装されていません。


インターネット上で「このマザーボードの BIOS は VT-d に対応しているよ!」という情報が記載されていても、実はこのようにチップセットが VT-d をサポートしていないケースがあります。VT-d の検証を目的として機器を選定する場合は、このような罠にかからぬよう、十分に注意してください。


プロセッサが仮想化支援機能を持つか確認するには

Xenの完全仮想化やKVMを利用するためには、プロセッサ(CPU)の仮想化支援機能が必要です。

プロセッサの仮想化支援機能は2006年頃の製品から実装されるようになり、2007年以降に提供されたプロセッサのほとんどに搭載されています。一部の廉価なプロセッサでは実装されていない場合もあります。

x86系プロセッサに搭載されている仮想化支援機能は、プロセッサの種類やベンダにより違いがあります。



  • Intel製プロセッサの場合: VMX, VT-x

  • Intel製IA-64プロセッサの場合: VT-i

  • AMD製プロセッサの場合: SVM, AMD-V (Pacifica)


プロセッサの仮想化支援状況を確認する一番簡単かつ確実な方法は、Linux(ディストリビューションのインストールCDや1CD Linuxなどでもかまいません)で起動し、シェル上で下記のコマンドを実行し、確認することです。


# cat /proc/cpuinfo


■ Intel 製プロセッサの場合

Intel プロセッサの場合、 /proc/cpuinfo の flags 行にフラグ vmx が出力されていれば
VT-x がサポートされています。

[root@quad ~]# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 23
model name      : Intel(R) Core(TM)2 Quad CPU    Q8400  @ 2.66GHz
(中略)
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
                  cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht 
                  tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est
                  tm2 cx16 xtpr lahf_lm
bogomips        : 5332.91
....


■ AMD 製プロセッサの場合

AMD 製プロセッサの場合、 /proc/cpuinfo の flags 行にフラグ svm が出力されていれば
AMD-V がサポートされています。


■ 対応プロセッサを利用しているのにフラグが立っていない場合は....


使用中のプロセッサが仮想化支援機能を持っているにも関わらず、これらのフラグが
表示されない場合、おもに以下の理由が考えられます。


  • BIOS設定上で仮想化機能の無効化されている(有効化されていない)

  • 下位仮想化技術やハイパーバイザによりマスクされている


  • Linuxカーネルがあまりにも古すぎて、仮想化支援機能を検出していない


■ 参考






2009年9月24日木曜日

viridian

 Viridianインターフェイス(Hyper-V)をエミュレートします。 (HVMドメイン)





 Viridianインターフェイス(Hyper-V)が提供するハイパーコールの一部をエミュレートします。Xen 3.4.0の時点では、本機能によりWindows Vista/7やWindows Server 2008において複数の仮想CPUを割り当てた場合にSTOPエラーが発生する現象を抑制できるようです。

■ 書式

viridian=<n>

■ <n>の値


  • 1 …… 有効

  • 0 …… 無効





■ 注意点


  • Viridianインターフェイスに対応したゲストOSが必要です

  • Xen 3.4以降

  • 本情報はXen 3.4.0時点の内容です

■ 参考


2009年9月16日水曜日

CentOS 5.3におけるXenマイグレーション利用時の注意点

Xen徹底入門 第2版で注意書きを入れようと思っていましたが最終的に入らなかったようなので、こちらに書いておきます。


Xen徹底入門 第2版では、マイグレーション機能についてCentOS 5.3 (64bit版)の検証結果に基づき解説しましたが、CentOS 5.3付属のXenパッケージには下記のとおり既知の問題があります。

64bitのハイパーバイザを使って32bitのドメインをマイグレーションを開始すると、ログに下記のメッセージが出力され、失敗する
 INFO (XendDomainInfo:1719) Dev 51712 still active, looping...


念のため、64bitのゲストの場合は問題なくマイグレーションできています。この問題はRed Hat Enterprise Linux 5.3にも存在するようです。根本的な解決策としては、CentOS 5.3標準のパッケージは利用せず、下記の方針でXenのバイナリを入れ替える必要があるようです。


  • 自分でXenをビルドしインストールする

  • CentOSプロジェクト以外からリリースされているパッケージに置き換える

バグの存在は残念ですが、CentOS 5.4以降のバージョンでは解決されることに期待したいと思います。


参考情報:

[Xen-users] live migration fails with device still active

http://lists.xensource.com/archives/html/xen-users/2009-04/msg00586.html


2009年8月30日日曜日

hpetオプション

 High Precision Event Timer (HPET)をエミュレートします。 (HVMドメイン)





 HPETは、これまでのPC/AT互換機で標準搭載されていたPITと比較し、高精度・高機能を実現したタイマーデバイスです。HPETを利用するにはHPETに対応したOS(Windows Vista、Windows Server 2008、Linux 2.6など)が必要です。


■ 書式

hpet=<n>

■ <n>の値


  • 1 …… 有効

  • 0 …… 無効





■ 実行例

hpet=0の場合

hvm-domain$ sudo cat /sys/devices/system/clocksource/clocksource0/available_clocksource
hpet acpi_pm jiffies tsc
hvm-domain$ sudo cat /sys/devices/system/clocksource/clocksource0/current_clocksource
hpet

hpet=0の場合

hvm-domain$ sudo cat /sys/devices/system/clocksource/clocksource0/available_clocksource
acpi_pm jiffies tsc
hvm-domain$ sudo cat /sys/devices/system/clocksource/clocksource0/current_clocksource
acpi_pm

■ 注意点


  • HPETエミュレーションを利用した場合でも、タイマのエミュレーション精度が向上するとは限りません。

  • Xen 3.3以降

softtsc(TSCのエミュレーション)

最近のXenでは、Xen起動時にsofttscオプションを指定することで、HVMドメインにおいてTSCをエミュレーションできるようになります。この機能を使うことにより、HVMドメインの時刻のずれをある程度抑制できます。




■設定例

/boot/grub/menu.lst抜粋

title Xen-unstable + 2.6.18.8-xen, iommu=0
        root (hd0,0)
        kernel /xen-3.5.gz iommu=0 com1=9600,8n1 console=com1,vga softtsc
        module /vmlinuz-2.6.18.8-xen ro root=LABEL=/
        module /initrd-2.6.18.8-xen.img

■実行例

softtscオプションが有効な場合、HVMドメインがRDTSCインストラクションを発行すると、Xenが管理するドメインの実行時間を基にTSCカウンタの値が決定されます。また、HVMドメインは(CPUの実働クロックに関わらず)仮想CPUのクロックを1000MHzと報告します。

softtscオプションありの場合

root@vm245:~# cat /proc/cpuinfo
 processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 23
model name      : Intel(R) Core(TM)2 Quad CPU    Q8400  @ 2.66GHz
stepping        : 10
cpu MHz         : 1000.005
……

デフォルト(softtscオプションなし)の場合は、HVMドメインがRDTSCインストラクションを発行すると、CPUが持つTSCカウンタの値をそのまま受け取ります。

softtscオプションなしの場合

hasegaw@vm245:~$ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 23
model name      : Intel(R) Core(TM)2 Quad CPU    Q8400  @ 2.66GHz
stepping        : 10
cpu MHz         : 2666.414
……

■注意点


  • softtscオプションを指定した場合、そのXenハイパーバイザ上で実行されるすべてのHVMドメインに機能します。

  • 将来的には仮想CPUのクロック速度、ドメイン単位での有効化/無効化が可能になると思われます。

  • マージ時期 2008年7月(xen-unstable)

2009年4月11日土曜日

CentOS 5.3をHVMドメイン+PVドライバで動かす

CentOS 5.1以降ではXen対応カーネルが供給されていますのでそれほど重要ではないのですが、LinuxカーネルにはXen用のPVドライバ(ParaVirtual Driver)が提供されています。

PVドライバを利用すると、IAアーキテクチャ向けのカーネルをXenの上で実行しつつ、最大のボトルネックであるディスクI/OやネットワークI/Oだけを仮想化しパフォーマンスを確保することができます。


・ /etc/modules.conf の修正


・ 初期RAMディスクの再生成


・ /etc/fstabの修正


・ /etc/modules.conf の修正


・ 仮想マシン定義ファイルの修正


・ 再起動、動作確認


・ 初期RAMディスクをもう一回再生成




● /etc/modules.confの修正

Xen PVドライバを適用するため、HVMドメインにインストールされたCentOSの /etc/modules.conf を書き換えます。

hvm-domain:/etc/modules.conf (変更前)

alias eth0 8139cp
alias scsi_hostadapter ata_piix

hvm-domain:/etc/modules.conf (変更後)

alias eth0 xen-vnif

● 初期RAMディスクの再生成

Xen PVドライバを含む初期RAMディスクを生成し、HVMドメインにインストールされたCentOSのGRUBの設定を変更します。

hvm-domain# mkinitrd --preload=xen_vbd /boot/initrd-`uname -r`.pv.img \
    `uname -r`;

hvm-domain:/boot/grub/menu.lst

title CentOS (2.6.18-128.el5)  ※オリジナルの起動設定を元に新規追加
        root (hd0,0)
        kernel /boot/vmlinuz-2.6.18-128.el5 ro root=LABEL=/ rhgb quiet
        initrd /boot/initrd-2.6.18-128.el5.pv.img

● /etc/fstabの修正

HVMドメインにインストールされたCentOSの/etc/fstabを修正します。LABEL=によるファイルシステムの指定をすると、ata_piixを通して見えるIDEエミュレートされた仮想ディスクをマウントしてしまうので、/dev/xvdを直指定します。

#LABEL=/                 /                       ext3    defaults        1 1
/dev/xvda1              /                       ext3    defaults        1 1
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
#LABEL=SWAP-hda2         swap                    swap    defaults        0 0
/dev/xvda2              swap                    swap    defaults        0 0

● 仮想マシン定義ファイルの修正

Domain-0上にあるHVMドメインのの仮想マシン定義ファイルを修正します。

変更前

disk = [ "file:/var/lib/xen/images/centos53_32hvm.img,hda,w" ]

変更後

disk = [ "tap:aio:/var/lib/xen/images/centos53_32hvm.img,hda,w!",
 "tap:aio:/var/lib/xen/images/centos53_32hvm.img,xvda,w!", ]

ひとつめのVBDはQEMU由来のIDEエミュレーションでプライマリ マスタのハードディスクを定義しています。HVMドメイン上のBIOSがOSをブートするために使います。

ふたつめのVBDは、準仮想でおなじみの仮想ブロックデバイスです。HVMドメインで動作するLinuxカーネルにxen_vbdが組み込まれた時点でアクセスできるようになります。

これら2つのVBDは実体として同じファイルを見ています。このままでは/etc/xen/scripts/blockスクリプトが二重マウントチェックでエラーにしてしまうので、オプションに「!」を付けてチェックを回避します。

※ openSUSE 11.1の場合

openSUSE 11.1+openSUSE 11.1純正Xenパッケージの組み合わせでは、xvdaを定義した時点で起動用の hda が自動的に作成されるようです。このため、ひとつめのVBDを明示的に定義する必要はありませんでした。

disk = [ "tap:aio:/var/lib/xen/images/centos53_32hvm.img,xvda,w!", ]

この動作が最近のXenのデフォルトの挙動なのか、それともopenSUSE 11.1の独自フィーチャーなのかはまだ整理できていません。たぶん後者だと思いますが。

● 再起動、動作確認

HVMドメインを再起動します。まずhaltでVMを停止させ、その後xm create等でVMを新たに作成してください。HVMドメイン内でrebootしてもdisk=[ ...]の設定変更が反映されません。

hvm-domain# halt

domain-0# xm create hvm-domain

うまく起動してきましたでしょうか?起動を確認したら以下のコマンドで、PVドライバ経由でI/Oできていることを確認します。

hvm-domain# mount | grep xvd
/dev/xvda1 on / type ext3 (rw)

hvm-domain# swapon -s | grep xvd
/dev/xvda2                              partition       265064  0       -1

hvm-domain# ls -ld /sys/class/net/eth*/* | grep xen
lrwxrwxrwx 1 root root    0  4月 10 11:30 /sys/class/net/eth0/device
     -> ../../../devices/xen/vif-0

mountおよびswapon -sの出力がhdaではなくxvdaであることから仮想ブロックデバイスドライバが、ethXのデバイスがxen/vif-Xであることから仮想ネットワークデバイスドライバが有効であると判断できます。

● 初期RAMディスクをもう一回再生成

これでata_piixドライバは不要になりました。必須ではありませんが、下記の手順でmkinitrdしなおすとata_piixドライバを初期RAMディスクから追放できます。

hvm-domain# rmmod ata_piix
hvm-domain# rm -f /boot/initrd-`uname -r`.pv.img `uname -r`.pv.img
hvm-domain# mkinitrd --preload=xen_vbd /boot/initrd-`uname -r`.pv.img \
    `uname -r`;

ata_piixドライバを追放したカーネルではLABEL=による指定でファイルシステムを探している場合でも、期待どおり/dev/xvda1など仮想ブロックデバイスを通してマウントしてくれます。

LABEL=/                 /                       ext3    defaults        1 1
#/dev/xvda1              /                       ext3    defaults        1 1
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
LABEL=SWAP-hda2         swap                    swap    defaults        0 0
#/dev/xvda2              swap                    swap    defaults        0 0

2009年3月12日木曜日

Xenのインターフェイスバージョン調査

Xen のインターフェイスバージョンがこれまでどのように上がってきたのか確認してみました。


Xen 3.0.x の頃はリリースの度にハイパーコールの互換性がなくなるような変更が加えられていましたが、 Xen 3.1.x 以降はマイナーバージョンのレベルでハイパーコールの互換性が維持されていることがわかります。



リリースアーカイブから

xen-3.0.2-2/xen/include/public/xen-compat.h:#define ... 0x00030101
xen-3.0.3_0-src/xen/include/public/xen-compat.h:#define ... 0x00030204
xen-3.0.4_1-src/xen/include/public/xen-compat.h:#define ... 0x00030205
xen-3.1.3/xen/include/public/xen-compat.h:#define ... 0x00030205
xen-3.1.4/xen/include/public/xen-compat.h:#define ... 0x00030205
xen-3.2.0/xen/include/public/xen-compat.h:#define ... 0x00030207
xen-3.2.1/xen/include/public/xen-compat.h:#define ... 0x00030207
xen-3.2.2/xen/include/public/xen-compat.h:#define ... 0x00030207
xen-3.2.3/xen/include/public/xen-compat.h:#define ... 0x00030207
xen-3.3.0/xen/include/public/xen-compat.h:#define ... 0x00030209
xen-3.3.1/xen/include/public/xen-compat.h:#define ... 0x00030209

Mercurial レポジトリから

changeset:   17983:4bdc3de246c3
+++ b/xen/include/public/xen-compat.h   Sat Jul 05 14:43:37 2008 +0100
+#define __XEN_LATEST_INTERFACE_VERSION__ 0x00030209
--
changeset:   17027:88818d55e95a
+++ b/xen/include/public/xen-compat.h   Tue Feb 12 11:37:45 2008 +0000
+#define __XEN_LATEST_INTERFACE_VERSION__ 0x00030208
--
changeset:   16207:aeebd173c3fa
+++ b/xen/include/public/xen-compat.h   Wed Oct 24 15:22:57 2007 +0100
+#define __XEN_LATEST_INTERFACE_VERSION__ 0x00030207
--
changeset:   16103:ef4119637f52
+++ b/xen/include/public/xen-compat.h   Fri Oct 12 11:55:41 2007 +0100
+#define __XEN_LATEST_INTERFACE_VERSION__ 0x00030206
--
changeset:   12453:bda05853cf21
+++ b/xen/include/public/xen-compat.h   Wed Nov 15 16:44:35 2006 +0000
+#define __XEN_LATEST_INTERFACE_VERSION__ 0x00030205
--
changeset:   11257:86d26e6ec89b
+++ b/xen/include/public/xen-compat.h   Fri Aug 25 18:39:10 2006 +0100
+#define __XEN_LATEST_INTERFACE_VERSION__ 0x00030204
--
changeset:   11119:aff2e2b7a23b
+++ b/xen/include/public/xen-compat.h   Tue Aug 15 15:50:36 2006 +0100
+#define __XEN_LATEST_INTERFACE_VERSION__ 0x00030203
--
changeset:   9889:42a8e3101c6c
+++ b/xen/include/public/xen-compat.h   Sun Apr 30 09:16:15 2006 +0100
+#define __XEN_LATEST_INTERFACE_VERSION__ 0x00030202
--
changeset:   9868:4e0f2272fbcd
+++ b/xen/include/public/xen-compat.h   Thu Apr 27 14:03:22 2006 +0100
+#define __XEN_LATEST_INTERFACE_VERSION__ 0x00030201
--
changeset:   9512:b524714dfb66
+++ b/xen/include/public/xen-compat.h   Sun Apr 02 09:48:04 2006 +0100
+#define __XEN_LATEST_INTERFACE_VERSION__ 0x00030101

2009年3月2日月曜日

blktap ramドライバで共有RAMディスクを試してみる

今回は Xen の blktap に含まれている ram ドライバ (tap:ram:) で遊んでみたいと思います。 ram ドライバとは、ドライバドメイン上に確保されたメモリ空間を仮想ブロックデバイスとして割り当てて利用できるようにするためのものです。複数のドメインから本ドライバを利用すると、最初に確保したメモリ空間を共有するようになります。つまり、仮想ブロックデバイス上のデータは複数ドメイン間で共有されることとなります。

本エントリをご覧になりながら動かしてみると判るかと思いますが、正直なところ、実用性については乏しい機能なのですが、共有ディスクを使った実験などを行う際には役にたつかもしれません。



  • block-ram.c へのパッチ作業

  • ひな形ディスクイメージの作成

  • ramドライバを試してみる

  • おさらい。



■ block-ram.c へのパッチ作業

まず残念なお知らせですが、CentOS 5.2 (i386)環境において、おそらく現在リリースされている Xen のリリースバージョンでは以下の部分をパッチしないとうまく動きません。(Mercurial上から落とした最新ソースでもおそらくパッチが必要でしょう)

tools/blktap/drivers/block-ram.c パッチ前

    161         /* Open the file */
    162         o_flags = O_DIRECT | O_LARGEFILE |
    163                 ((flags == TD_RDONLY) ? O_RDONLY : O_RDWR);
    164         fd = open(name, o_flags);
    165 

tools/blktap/drivers/block-ram.c パッチ後

    161         /* Open the file */
    162         o_flags = O_LARGEFILE |   // no O_DIRECT
    163                 ((flags == TD_RDONLY) ? O_RDONLY : O_RDWR);
    164         fd = open(name, o_flags);
    165 

どうしてこんな状態でリリースされているのかが大変不思議なのですが、 64 ビット環境であればmalloc() したメモリは常にアライメントされる保証でもあるのでしょうかね?そこまでは追いかけてませんが....

パッチした blktap ドライバをインストールするには、ソースツリーで以下の操作をすると楽です。

# make -C tools/blktap
# make -C tools/blktap install

■ ひな形ディスクイメージの作成

準備ができたら、ひな形のディスクイメージを作りましょう。ddコマンドで256MBのファイルを作成し、その中にとりあえずext3ファイルシステムでも作っておきます。

dom0# dd if=/dev/zero of=/home/vm/ram.img bs=1M count=256
256+0 records in
256+0 records out
268435456 bytes (268 MB) copied, 0.793614 seconds, 338 MB/s

dom0# mkfs.ext3 /home/vm/ram.img
mke2fs 1.39 (29-May-2006)
/home/vm/ram.img is not a block special device.
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
65536 inodes, 262144 blocks
13107 blocks (5.00%) reserved for the super user
〜省略〜
This filesystem will be automatically checked every 29 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

[root@localhost drivers]# dumpe2fs /home/vm/ram.img | grep UUID
dumpe2fs 1.39 (29-May-2006)
Filesystem UUID:          16c03fc3-c3c3-41a6-b6df-eac4c1407296

■ ramドライバを試してみる

これをまずDomain-0上にアタッチしてみましょう。

dom0# xm block-attach 0 tap:ram:/home/vm/ram.img xvdb  w
dom0# dumpe2fs /dev/xvdb | grep UUID
dumpe2fs 1.39 (29-May-2006)
Filesystem UUID:          16c03fc3-c3c3-41a6-b6df-eac4c1407296

先ほど作ったファイルシステムの UUID が /dev/xvdb に見えていることから、イメージがきちんと認識されていることがわかります。続いて、ほかの準仮想化ドメイン、ここでは testvm にもアタッチしてみます。先ほど /home/vm/ram.img を Domain-0 にアタッチしましたが、次の VM に attach するには他のファイル名を指定する必要があります(xm block-attachの仕様による)ので、ダミーで適当なファイルを作り、それを指定しておきます。

dom0# touch /home/vm/ram.img.2
dom0# xm block-attach testvm tap:ram:/home/vm/ram.img.2 xvdb  w


dom0# xm console testvm
CentOS release 5.2 (Final)
Kernel 2.6.18.8-xen on an i686

localhost login: root
Password: 
Last login: Sun Mar  1 08:33:35 on tty1
-bash-3.2# dumpe2fs /dev/xvdb | grep UUID
dumpe2fs 1.39 (29-May-2006)
Filesystem UUID:          16c03fc3-c3c3-41a6-b6df-eac4c1407296

ログインした環境でもやはり同じ UUID が見えています。これは、 testvm に xvdb として、先ほど作成したRAMディスクがアタッチされているからです。

testvm でファイルシステムを再作成してみます。

-bash-3.2# mkfs.ext3 /dev/xvdb
〜省略〜

-bash-3.2# dumpe2fs /dev/xvdb | grep UUID
dumpe2fs 1.39 (29-May-2006)
Filesystem UUID:          7b55589f-2164-4a99-9743-21ebb46562a4

ファイルシステムの UUID が変わりました。mkfs.ext3 により RAM ディスクの内容が変化したからです。このディスクは Domain-0 からも参照しているので、 Domain-0 から見てどうなったかを確認してみると

dom0# dumpe2fs /dev/xvdb | grep UUID
dumpe2fs 1.39 (29-May-2006)
Filesystem UUID:          7b55589f-2164-4a99-9743-21ebb46562a4

やはりファイルシステムの UUID が変わっています。つまり、 testvm 上で行った変更が Domain-0 側にも反映されています。しかし、もともとファイルとして作成したイメージファイルには変更はありません。

dom0# dumpe2fs /home/vm/ram.img | grep UUID
dumpe2fs 1.39 (29-May-2006)
Filesystem UUID:          16c03fc3-c3c3-41a6-b6df-eac4c1407296

■ おさらい。


  • tap:ram ドライバで、共有RAMディスクを作成できます。

  • 作成できる共有RAMディスクはひとつだけです(ふたつ目以降のブロックデバイスを作ろうとすると、作成済みRAMディスクを参照します)。

  • 共有RAMディスクを作成する際には初期イメージを格納したファイルが必要です。共有RAMディスクはこのファイルの内容が初期状態となります。

  • xm block-attach コマンドのファイル名チェック、ファイル重複使用チェックをくぐりぬけるため、ふたつ目以降の仮想ブロックデバイスを作成する際にはダミーファイルの指定が必要です。

  • 共有RAMディスクへの書き込み内容は、使用が終わるまで(仮想ブロックデバイスからの参照カウントがゼロになるまで)保持されますが、元ファイルなどには反映されません。

うまく使えばクラスタ構成のテスト用領域として使用したり、繰り返しバッチを行うような場合にバッチ用の元ネタを格納しておく領域(使い終わったら一度 detach 後再度 attach すると内容が初期状態に戻る)などの活用が考えられます。とはいえ、使ってみればわかるとおり、仮想RAMディスクがシステムあたりひとつしか作れず融通がきかないこと、レポジトリ上のコードそのままでは動かないことから、実用性はあまり高いとは言えませんね。

2009年2月22日日曜日

RedHatとMicrosoftがサーバ仮想化の相互運用に関して提携

Red HatとMicrosoftがサーバ仮想化ついての相互運用に関して提携を結んだようです。この提携により下記の内容が実現されることになりそうです。


  • Red Hat Virtualization の機能上で Windows Server ゲストの動作検証が行われ、正式にサポートされる

  • Windows ServerのHyper-Vゲストとして、Red Hat Enterprise Linuxゲストの動作検証が行われ、正式にサポートされる

特に Hyper-V は、これまでは Windows Server および SUSE Linux Enterprise Server と、対応するゲストが非常に限定されていました。 Hyper-V 上で事実上標準的な Red Hat Enterprise Linux がゲストとしてサポートされれば、 Hyper-V を利用した Windows & Linux サーバ統合がより現実的なものとなり、現状 VMware ESX が絶対的に優位なサーバ統合の現状に、何らかの変化がおきるのかもしれません。


Red Hat Moves to Expand Server Virtualization Interoperability


blktapベースの仮想ブロックデバイスをDomain-0にマウントするには

最近の Xen では、仮想ブロックデバイス(VBD)のバックエンドドライバとして blktap を利用することができます。 blktap は VBD のバックエンドのためのインターフェイスで、さらに実際の I/O 機能を持つドライバを組み合わせることで利用します。仮想マシンの定義ファイルに下記の指定をする場合、それは blktap の aio ドライバ(async I/O = 非同期I/O)を使用することになります。

disk = [ 'tap:aio:/var/lib/xen/images/linux.ext3,xvda,w' ]

blktap では、 aio 以外に qcow, qcow2, vmdk など、他の仮想マシン技術で使われるディスクフォーマットの利用が可能となっています。

さて、 aio ドライバのように Linux で普通にループバックマウントできる形式であれば、 Domain-0 からとりあえず触りたいような場合は何も考えずにマウントしてしまえばよいのですが、 QEMU の形式である qcow2 フォーマットのイメージを Domain-0 からマウントしたい時はどうしたらいいでしょうか。

このような場合には、 xm block-attach コマンドを使用して Domain-0 に仮想ブロックデバイス(VBD)を割り当てることができます。第二引数はDomain-0のドメインID(ゼロ)を指定しています。

# xm block-attach 0 tap:qcow2:/var/lib/xen/image/linux-image.qcow2 xvda w
# mkdir -p /mnt/linux-image
# mount /dev/xvda /mnt/linux-image

用が済んだら、アンマウント後に xm block-detach コマンドで仮想ブロックデバイス(VBD)を解放します。

# umount /dev/xvda
# xm block-detach 0 xvda

Domain-0 は特権ドメインであり、一般的には VBD をサービスする側なのですが、それと同時に Domain-0 の正体は「一部ハードウェアやハイパーバイザーへの特権アクセスが許されている」点を除けば、あくまでXen にとっては他のドメインと同じゲストに違いありません。



2009年2月16日月曜日

GPL PV Drivers のパフォーマンス

製品の仮想化技術には、 VMware でも Parallels でも、 Windows をゲストとして動作させる時に I/O パフォーマンスを向上させるためのドライバが用意されています。

このような仮想化デバイスのドライバを使用しない場合、仮想マシン上で動作する Windows などの OS は、仮想マシン技術がエミュレートする PCI バス上のディスクコントローラに対して I/O を行います。これに対して、先のドライバは VMware などの仮想化ソフトウェアと直接 I/O データをやりとりするため、パフォーマンスが向上する仕組みになっています。

さて、 Xen においてもこのようなドライバの仕組みは Paravirtual Driver (準仮想化ドライバ) という形で存在しています。 Xen のソースコードをダウンロードすると unmodified_driver/ などというディレクトリがあったりしますが、それがまさにそのドライバです。

アンオフィシャルですが、 Windows 用のオープンソースな PV ドライバも存在しています。


しかし、ただ単純にベンチマークをとってみると...



【検証環境】

・HP ProLiant ML115 G1
・Athlon64 X2 5600+ (2.8GHz x2)
・8GB PC5300 RAM
・Hitachi HTS72323 320GB 2.5inch HDD
・openSUSE 11.1 + Xen 3.3
・Windows xp SP3 (x86)


あれれ~? PV ドライバを入れた場合のほうがパフォーマンス伸び悩んでますね。というか QEMU のハードウェアエミュレーションと比較し完敗です。何かの間違いでしょう。しかし、再計測しても再計測してもこの結果がひっくり返ることはありませんでした。

そこで、このツールで計測をはじめてから計測が終わるまでの時間を、愛用の G-SHOCK で測ってみました。なお Crystal Disk Mark のソースコードを確認したところ決まった量の I/O 負荷をかけて、それの所要時間から性能を算出しているようです。つまり計測値はアテにならなくても、 I/O に要した"時間"は信用できると考えられます。結果は以下のとおりでした。

PV ドライバ使用時: 3分23秒
PV ドライバ未使用時: 3分31秒

なんだ、やっぱり PV ドライバのほうが早かったんですね。約 6 % の性能アップしていたようです。しかし、これでは本当のスループットがわかりませんね。敢えていえば QEMU エミュレーションから 6% しか性能向上がない PV ドライバというのも随分寂しいものです。( XenSource や Novell が作っているドライバはもっと高いパフォーマンスを示してくれることでしょう)

PV ドライバには I/O パフォーマンスを向上させる以外のメリットとして CPU に対する負荷の低減があります。無意味に低レベルなハードウェアの真似(ゲストによる I/O ポートへのアクセスをトラップしエミュレーション)をする必要がなくなるからです。

I/O パフォーマンスについてはまた計測方法を検討して検証をしてみたいと思います。というわけで、今日はおやすみなさい。