2012/04/29

Bhyve が Fusion 上で動いた




動いたので記念撮影。このあと起動し、ちゃんと root でログインできている。

細かいことはもう少し詰めてから書くが、ポイントは
  • 急がば回れ。多分今の -curent なら深く考えなくても Fusion 上で動くのでソースからビルドが結局は近道
  • http://bhyve.org にバイナリきっとあるけど、これそのままでは Fusion 上で動かない
  • 問題は現在の Bhyve のコードでは治っている
  • 要点? vhv ではVM_EXIT_SAVE_PAT と VM_EXIT_LOAD_PAT が非対応のため
というところだ。

適当に -current 引っ張ってきて手直しした vmm.ko をこちら においたので、もし試したい場合は以下の手順でいけるだろう。(要追試)

  1. (必要かはまだ絞り込めていないが)、とりあえず4GB はメモリを持った仮想マシンを作っておく
  2. FreeBSD 9.0R を普通インストールする
  3. http://bhyve.org にリンクされている bhyve-0.0.1r225757.tar をダウンロードする
  4. pkg_add <ダウンロードした bhyve-0.0.1r225757.tar> でインストールする
  5. /boot/kernel/vmm.ko を上記のパッチ済みのもので差し替える
  6. http://bhyve.org にリンクされているゲストイメージをダウンロードする。1GB/400MBどちらでもよい
  7. xz -cd <ゲストイメージ.tar.xz> | tar xf -  で展開する
  8. 出来たフォルダを # mv ./bhyve-guest-400mb /usr/bhyve-guest で /usr/ 以下に配置する(トップフォルダの名前をリネームするので要注意)
  9. /boot/loader.conf を作成、以下の情報を書き込む(2GBをホストに割り振る)
  10. hw.physmem="0x80000000"
    debug.witness.watch="0"
  11. 再起動して設定を生かす
  12. root で cd /usr/bhyve-guest から sh ./vmprep.sh でカーネルモジュールを読み込ませる
  13. sh ./vmrun.sh で仮想マシンを起動する

詳細なことはまた改めて書く。

2012/04/25

[余談] ファイルを探索後、そのファイルを検索する

ちと本日ネタになったので覚え書き代わりに書くとする。

本日みたある資料では、以下のような感じになっていた。
grep ERROR `find . -name "debug*.txt" -print`
これがいけないこと、というのを指摘したのだが分かってもらえなかったようなので何故いけないかをつらつら語りたいと思う。


ある程度 UNIXの経験がある人ならば「何だその話かよ」で終わる話だが、様々な面でこれは問題のある表現である。


一番簡単な問題は「溢れる」ということだ。コマンド行の固定長で上限ある。
このサイズは ARG_MAX という定数で定義されている。

例えば、Mac OS X 10.5.8 では以下の感じだ。
grep -R ARG_MAX /usr/include/
(中略)
/usr/include/limits.h:#define _POSIX_ARG_MAX 4096
/usr/include/sys/syslimits.h:#define ARG_MAX   (256 * 1024) /* max bytes for an exec function */
POSIX な定数だとわずか 4KB, そうでなくても 256KB 程度になる。これ以上は保証されない。

上記の find の書き方だと「カレントディレクトリ (.) とそこから下のサブディレクトリ」を再帰するので、debug.txt と書かれたファイルが下のディレクトリにあるなら容易に溢れる訳だ。溢れると、のたうち回った末にこんなエラーが表示される

/usr/bin/grep: Argument list too long.
計算機資源に優しくないのでやめろ感じる訳だ。

また、サブディレクトリを探す意図はなかったというかも知れないが、ならばシェルの補完でも十分だ。「 grep ERROR debug*.txt 」で間に合う。どうしてもバッククオートを使いたいなら「grep ERROR `ls debug*.txt`」とでもすればいい。


もちろん「溢れ」の可能性については前世紀から分かってる事実であり、このため find には頼もしい助っ人である「xargs」コマンドがついている。

上記の例を「悪い」見本で直すとこんな感じだ
find . -name "debug*.txt" -print | xargs grep ERROR
xargs は標準入力で渡されたリストを ARG_MAX を越えない程度に分割して、それを引数で渡されたコマンドの引数にして実行する。また、コマンドの実行が一々増えていいのなら

find . -name "debug*.txt" -exec grep ERROR {}\;
と書けばいい。-exec は find がマッチしたファイルパスの一つ一つに対して指定のコマンドを実行する。{} の部分がファイルパスに置換される。また、-exec の引数となるコマンド列の末尾は ; で終わるが、これがシェルに解釈されないように \ を入れる。-exec hogehoge {} \; まではイディオムであり、よく見かけると思われる。

個人的には、上記二つで普通のUNIX屋であると認識する。


で、より上位の人に「一々 -exec するな」か「マッチしたファイル名に空白がはいってたらどうする」かで突っ込まれるのもまた普通の話と思われる。

そう、xargs で引き渡された標準入力に、普通の英数字以外が混じっているとそこが「区切り」と見なされることがある。


で、だ。そんなことも、xargs を作ったような在りし日のUNIX屋にとっては想定内である。そのため、find には -print0, xargs には -0 オプションがある。正しいのは以下になるだろう。
find . -name "debug*.txt" -print0 | xargs -0 grep ERROR
find の -print0 オプションは -print とほぼ同じだが、区切り文字を '\0'、ヌル文字にしてくれる。空白や制御文字はファイル名に入れることは出来ても、ヌル文字は決してファイル名に現れない。このため、一つの検出されたファイルパスが間違って分割されることもない。

一方、ヌル文字が区切りであることを示すのに、xargs には -0 (ゼロ)オプションがある。find の -print0 での出力を xargs -0 は正しく解釈し、ARG_MAXに越えないだけにまとめてコマンド実行をしてくれる。

いつ頃から find -print0 と xargs -0 があったかは知らないが、私が駆け出しの頃にはすでにあったものだ。今日日の環境ならどこにでもあるだろう。

ファイル名に空白があるは、かつて Apple も iTunes のアップデートでミスった問題だ。
決して少ない訳じゃない。


決して新しい知識ではないのだから、ここまでは配慮して欲しいと思ったのが、本日ぐだぐだ言ってた理由だ。








2012/04/24

vExpert 2012

今年も辛うじて、vExpert 2012 を頂きました。ありがとうございます。


2012/04/14

VMware Tools のアップデート追記

昨日公開した VMware Tools のアップデート情報だが、間の悪いことにこれに関係するもう一つ新しいアドバイザリ VMSA-2012-0007 が出ていたので追記したい。

これは、Windows 向けの VMware Tools のフォルダの権限付けにミスがあり、これを突くことでゲストOS上の特権を奪えるというものだ。

上記のアドバイザリを参照して頂ければ分かるが、この脆弱性をもつ製品は非常に幅が広い。

  • VMware Workstation 8.0.1 とそれ以前
  • VMware Player 4.0.1 とそれ以前
  • VMware Fusion なら 4.1.1 とそれ以前
  • ESX/ESXi なら 3.5, 4.x, 5.0 

まぁ、要するにこの脆弱性への対応パッチやアップデートを含まれてない製品全て、ということになる。ホスト製品の場合はそれぞれ後継製品に、ESX/ESXi の場合は該当パッチを適用することで内蔵される VMware Tools に更新されるので、アップデートやパッチ適用後、Windows をゲストOSとする仮想マシン全ての VMware Tools をアップデートする必要がある。手間がかかるが必ず実施した方が良い。

なお、VMware Fusion 4.1.2 をダウンロード、その中の VMwareTools を確認したところ、バージョンは 8.8.3 (8.8.3.12575)、ビルド番号は 683185 のようだ。

2012/04/13

VMware Tools のアップデート

少々旧聞だが、VMware 製品のセキュリティアップデートを通知する Security Advisories & Certifications に掲載された VMSA-2012-0004, VMSA-2012-0005 にて 「Windows版VMwareTools に含まれるディスプレイドライバ(XPDM, WDDM双方)にてメモリ管理の脆弱性があり仮想マシン内の Windows で特権を奪われる可能性がある」旨が告知されている。

対策としてはパッチ適用(ESXi500-201112402-BG など)になるが、これは ESX/ESXi に含まれる VMwareTools のイメージをアップデートするだけだ。具体的にこのパッチでのアップデート事項は KB 2007672 を参照して欲しい。

すぐに気がつかれたかと思うが、ただパッチを当てるだけでは問題は解決しない。各仮想マシンの VMware Tools をアップデートする必要がある。
逆に言えば、パッチを当てなくても VMware Tools さえ最新版を入手、アップデートすればこの問題については回避できる。

最新版の VMware Tools (Windows版)は以下ページから入手できる。


x86(32bit)と x64(64bit)があるのでそれぞれ入手して欲しい。


また、VMSA-2012-0005 では VMware Workstation 等ホスト製品については問題がないとされているが、これはその環境で仮想マシンを動かしている場合に限られる。

VMware Workstation 7.1.5 より前、Player 3.1.5 より前、VMware Fusion 4 より前の各製品で作成、当時の VMware Tools をインストールしている仮想マシンを ESX/ESXi 環境に持って行った場合、VMware Tools のバージョンが古くてやはり問題が発生する。
もちろん、そもそも仮想マシンを ESX/ESXi 環境に転送しないなら問題はない。

対策としては、VMware Workstation なら 8へアップグレードする、7.x なら 7.1.5 にする、Player なら 3.1.5 をダウンロードしてアップデートする、VMware Fusion なら 4 を購入し、その上で VMware Tools をアップデートしておくといい。
とはいえ、仮想化製品をそうもアップデートできない、購入できない場合もあるだろう。その場合はやはり上記のページから VMware Tools をダウンロード、アップデートしておいた方が安全だ。


なお、VMSA-2012-0004 では同じ問題を記述しているが、こちらは VMware View に対するアドバイザリで、対策として「View 5.0 か 4.6.1 へアップグレード後、各仮想マシンごとの ViewAgent をアップデートする」という手順が記載されている。

脆弱性は VMware Tools 内のディスプレイドライバなので奇妙な話だが、View を使ってる場合は ViewAgent もあわせてアップデートしておいた方がいいだろう。


カスタム静止スクリプト

かつて VCB (VMware Consolidated Backup)のころ、アプリケーションレベルでの静止点を取得するためにスクリプトを走らせる機能が存在した。これがカスタム静止スクリプトだ。

これは VCB時代のドキュメントの仮想マシンバックアップガイド(PDF) の P.44 に記載がある。VCBによるバックアップ開始時に  %WINDIR%\pre-freeze-script.bat が実行され、終了時に %WINDIR%\post-thaw-script.bat が実行される。

ただ、当時試したところ動いている様子がなく気になっていたのだが、その時は急ぎ確認する理由もなかったのでそのままにしておいた。

そして、先日 カスタム静止スクリプトについて調べる機会ができたので少々確認をしてみた。

ご存じの通り、VCB のサポートは vSphere 4 までで終了し、現在では VADP (vStorage API for Data Protection) が利用されている。VCBはコマンドベースの技術でバックアップソフトからVCBのコマンド(vcbMounter.exe)を呼び出して連携をとっていたが、VADPはライブラリで提供され、バックアップソフトはこのライブラリのAPIをコールする事で連携をとっており、より密接な制御が可能となった。

さて、では VADPでカスタム静止スクリプトがあるかというと、まだ存在する。これについては、KB1006671が詳しい。

ESX/ESXi のバージョン カスタム静止スクリプトのパス
3.5U1 とそれ以前
%WINDIR%\pre-freeze-script.bat
%WINDIR%
\post-thaw-script.bat
3.5U2 とそれ以降
C:\Program Files\VMware\VMware Tools\backupScripts.d\
4.x %WINDIR$\backupScripts.d\
5.0
両方の場所を確認する
5.1, 5.5
%WINDIR%\pre-freeze-script.bat
%WINDIR%
\post-thaw-script.bat

なお、backupScripts.d フォルダはデフォルトでは作成されていないので、利用する場合は自分で作成する必要がある。backupScripts.d フォルダ以下にあるバッチファイルなどが全て実行されるが、その順序はバックアップ作成時はアルファベットの昇順(A-Z)で、終了時は降順(Z-A)となる。
Windows XP では 3.5U2 以降で実行していても旧来の pre-freez-script.bat 等が使われるようだ。

見ての通り、実は ESX/ESXi 3.5U2 以降でパスが変わっているのだ。これで当時うまく動かなかった理由が判明した。

私が VMware Infrastructure 3.5 を使い出したのは U2 の頃からで、それ以前は 3.0.3 を中心に 3.5 は様子見をしていたからだ。

なお、Linux など Windows 以外のOSの場合は、/usr/sbin/pre-freeze-script, /usr/sbin/post-thaw-script が実行されるようだ。これについては VMware DataRecovery 管理ガイドの P.8〜9 あたりに記載がある


追記: VCB サポートは vSphere 4.0 までではなく 4.1 までだったので訂正。そういえば 4.1 も VCB1.5u2 でサポートされていたのでした。
追記:20150106, 気がついたら対応表が変わってたのでこちらも更新

2012/04/08

Mac で ESXi は動くのか?

結論から言うと、「動作はする、サポート機種なら」となる。

サポート機種があるのか? といわれると1機種だけ実は存在する。Xserve だ。

VMware 社の HCL で確認すると「Xserve3,1」が記載されている。
しかし、多くの人は「Xserve3,1」というのが何かさっぱりだろう。

これは、Apple での「機種ID」を意味する。マックをお持ちの方なら、アップルメニューから「このMacについて」を選択、「詳しい情報」を押すと「Apple プロファイラ」というアプリケーションが立ち上がり、その Mac の詳細情報が表示される。

メインウィンドウで 「ハードウェア」の項目を選択、右側を見ると「機種ID」というのがあり、「MacBookPro6,1」とか記載があるはずだ。

また、フリーソフトの Mactracker を使うと機種IDを調べる事が出来る。

機種IDはハードウェアとしての世代を表す。概ね「ハードウェア名」.「メジャーバージョン」,「マイナーバージョン」ともいえる形になっている。同時期に売られている機種でも、iMac10,1 と iMac11,1 という感じでマイナーバージョンは異なることがある。
(これは2009年度後半に発売された iMac の場合で、Core2Duo 搭載は iMac10.1, Core i5, i7 搭載は iMac11,1 であった)

Xserve の場合、この機種IDは少々数奇な運命を辿っている。2002 年に発売された初代 Xserve は、「RackMac1,1」であった。どうもぎりぎりまで Xserve という名前が決まらなかったようで RackMac というコード名のままになっている。翌年発売された第二世代は RackMac1,2 で、仕様にほとんど差はない。筐体の剛性が上がり共振が押さえられたのと、ファンの回転制御がOS側から行えるようになり、騒音で悪名高かった初代より静かになったぐらいだ。

機種IDが  Xserve1,1 となったのは 2006 年の Intel 版の Xserve のリリースからだ。これは Xeon5100 を搭載していた。2008年に Xeon5400 にアップデートされた Xserve (Early2008) がリリースされたが、これが Xserve2,1 の機種IDをもつ。

で、問題の Xserve3,1 を持つのは 2009年1月にリリースされた Xserve(Early2009)で、Xeon 5500 をCPUに搭載している。おそらく「Early2009」で調べるか、Xeon 5500 搭載で調べると見つけやすいだろう。

なお、この Xserve (Early2009)は Xserve の最終機種である。

そう、Apple は 2011年1月に Xserve という1Uサーバそのものをディスコンにしている。

そもそも Xserve はサーバ用途という Mac としては極めて特殊なため、出荷台数は極めて少ない。Early2009 に至っては「どれだけ国内にあるのか?」 と疑問を持つぐらい少ない。

Xeon5500 で今でも十分に利用可能なCPUで、さらに最終機種となったのもあってまだまだ現役で動作しているのだろう。中古市場でも見かけることはまずないぐらいレアだ。

私も残念ながら1台しか所有していない。出物があったらもう1台欲しいものだが...。


● Xserve への ESXi のインストール

インストール自体は通常の ESXi と変わらない。

ただ、ESXi のバージョンによっては最初の起動に失敗することがある。

VGA 640x480 などという標準解像度を持たない Mac では、解像度情報を本体側NVRAMに記憶しており、起動時にその解像度で起動しようとする。この解像度によっては vmkernel 側がうまく追従できずそこで止まることがあるようだ。

通常の Mac なら nvram のクリア(SMUリセット)を行えばいいが、これが Xserve では上手くいかない。
 私が試した限り、上手くいくのは  Xserve Intel ユーザーズガイド の P.12 にある方法だ。
  1. 一旦電源を落とした状態にする
  2. 全面にあるシステムIDボタンを押し続ける
  3. そのまま電源を投入すると、フロントのCPU負荷を示す青いランプが順番に点滅する
  4. これは起動時チェックを行っているのだが、その間システムIDボタンを押しっぱなしにする。
  5. 順番の点滅が終わったところで通常行われる起動が行われないので、そこでシステムIDボタンを離す。
  6. 上記マニュアルにあるようにシステムIDボタンを押すと一個ずつ青いランプが点灯するので、下の左から3つ目だけが点灯する状態にする。(NVRAMリセットして起動可能なドライブから起動する。)
  7. そして、システムIDボタンをまた押しっぱなしにして、上の列が全て点灯するまで待つ
この方法でやっと ESXi のリリースメディアから起動することができた。

● Xserve 以外では動かないのか?

とりあえず、Macbook や iMac, Mac mini といった通常の Mac ではベアメタルに ESXi をインストールすることは出来ないと考えた方がいい。ESXi側が適切なドライバを持っていないためだ。

私が試したのは Mac mini だが、USBデバイスの認識がおかしく、vmkernel 起動した瞬間にキーボードのキー入力を受け付けなくなった。スクリプトインストールで切り抜けようとしたが、オンボードNICを認識しない時点でハマってしまった。

意外に知られていないが、ESX/ESXi は「vmkernel が認識できるNICが一つもない場合、インストールできない」という仕様がある。これに引っかかった訳だ。

コンシューマ向けの Mac では上記から諦めた方がいい。

ベアメタルではなく、仮想環境の上なら容易に動作する。VMware Fusion 4 では ESXi を仮想環境上で動作させることができるようになっている。ご丁寧にも仮想マシンの作成時に選択可能だ。さらに Virtual  Hardware Virtualization (vhv) を有効にすれば Fusion 上の ESXi で 64bit の仮想マシンを動かすことも出来る...、メモリとCPUが耐え切れれば、だが。

● 6/3 追記
上記に Mac mini ではインストールできなかったと記載したが、ドライバーを整えることでインストールに成功した人がいる。
また、Mac mini を入手できたら試してみたい。