VMware Fusion はバージョン5になってから通常版の「VMware Fusion5」とプロフェッショナル版の「VMware Fusion 5 Professional」に分かれた。
それぞれの機能比較は VMware 社のページにあるので見て頂ければと思う。
個々で興味深いのは「VMware Fusion 5 Professional は、実績のある VMware Player が含まれている」という記述だろう。VMware Fusion 5 Professional のライセンスキーは VMware Player にも投入でき、どちらをアクティベーションすることもできる。
無償の VMware Player をアクティベーションして何の意味がある?と思われるかも知れないが、これは VMware Fusion Professional の正規の機能であり、保守によるサポート範疇に含まれる、というのがミソだ。
通常の VMware Player は個人利用のみ無償であり、雑誌掲載や商利用などについてはこれまでも申請が必要だった。が、この申請がややこしいのもあり、VMware Workstation を購入するというのが現実的には行われていた。単に仮想マシンを実行できれば良く、Workstation のもつ様々な機能を使う必要がなくても、だ。
そこで、VMware Fusion 5 Professional を購入し、そのライセンスを Mac ではなく WindowsPC に割り当て、VMware Player をインストール、利用する、という形態をとることで VMware Player をより簡単に、より安価に商利用で使えるようになった訳だ。
VMware Fusion 5 Professional はライセンスキーのみでの購入ができ、ボリュームディスカウントも存在する。通常のインシデントベースのサポートだけではなく、平日8-20時でのサポートとサブスクリプションも用意されている。これは Mac むけもさることながら、商用版 VMware Player としての使われ方も想定してのことだろう。
2013/9/14追記:
VMware Fusion6, Workstation10, の公開にともない、VMware Player もバージョンアップし VMware Player6 になった。 この Player6 では個人用途で無償でダウンロードできる通常版に加え、商利用がサポートされた PlayerPlus というライセンスが新たに用意された。
ただし、VMware PlayerPlus は現時点では VMware社のオンラインストアでしか購入することができない。中小企業でごく小規模に使う場合はオンラインストアで購入も悪くはないが、ある程度の規模で導入しようとするとボリュームライセンスでの購入が避けられなくなる。
この場合は、やはり VMware Fusion Professional を購入し、Windows/Linux PC に割り当て、VMware PlayerPlus として使うという形態になる。
2012/10/28
XP から Windows8 にアップグレードするとNICが認識されなくなるのとその対処
Windows8 の発売の翌朝だが、セミナーの講師をしていたところ、お客様より「今回のセミナーとは関係ないのですが...」と問い合わせを受けた。
どうもこのお客様のお客様、つまりはエンドユーザの方が VMware Fusion 上で、Windows XP を実行している仮想マシンに Windows8 をアップグレードインストールした、そうだ。すると、アップグレードは成功したもののNICを認識しないので何とかしてほしいと相談を受けたとのこと。
まあそんなチャレンジャーなアップグレード良くやるなぁと思ったが、とりあえずNICが AMD PCnet だからではないかと推測、いくつかの方法を話をした。
この土日、折角なので個人的に調べてみた。
● 再現試験
実際に Windows XP Professional から Windows 8 Pro にアップグレードインストールしたところ、それ自体は成功した。が、確かにNICを認識していないのが分かった。
手持ちの Windows XP はIDE接続の仮想ディスクにインストールされており、やはりNICは AMD PCnet (vlance というかフレキシブル) であった。
あとキャプチャを忘れたが、「ネットワーク接続」のデバイス一覧に何のネットワーク接続も表示されていなかった。
● 手っ取り早い対処法
手っ取り早く何とかしたい場合は、以下の手順を行えばいい。
なお、vmx ファイルを操作するという危険なことを行うので、バックアップは必ずとっておいてほしい
Fusion で作成したWindowsXP仮想マシンの場合、NICに対する virtualDev は指定されていない。指定されていない場合は AMD PCnet 扱いする。一方、Fusion で Windows8 仮想マシンを作成した場合は、上記の行が追加されており Etherexpress1000e 扱いされる。
VMware Workstation などでは NIC のタイプを指定することができるが、Fusion では簡単に指定する方法がない。なので、ここでは .vmx ファイルを直接編集、修正をしている。
なお、起動直後はまだNICは認識されない。しばらく待ってると下図の様なエラーが表示され、さらにしばらく待つとNICが追加される
● 余談
なお、私の WindowsXP 仮想マシンは、仮想ディスクがIDE接続だったためさして問題なくアップグレードできたが、SCSI接続の場合アップグレードに失敗する?らしい話も聞いている。
vSphere で WindowsXP 仮想マシンを作成すると、デフォルトでは BusLogic SCSI HBA を経由して仮想ディスクが接続される。おそらく、AMD PCnet のドライバーがなくなり上記のような問題が起こったように、BusLogic SCSI HBA のデバイスドライバーもなくなったのだろう。
だいたいにおいて、BusLogic SCSI HBA のエミュレーションは過去のOSとの後方互換に使われている。WindowsServer 2003 などでは LSI Logic のより新しいSCSI HBA が使われ、Windows7, 2008R2 などでは LSI Logic SAS HBA のエミュレーションが行われる。
おそらく、LSI Logic HBA のエミュレーションなら Windows8 でも利用可能なのだろうと思われる。
WindowsXP でも LSI Logic HBA エミュレーションを使うことは可能だが、インストールメディアに LSI Logic のSCSI HBA のドライバーが入ってないためそのままでは新規インストールに失敗する。LSI Logic のサイトなりからデバイスドライバをダウンロード、仮想フロッピーメディアに展開しておき、インストール時に追加するといい。
この WindowsXP で LSI Logic HBA のエミュレーションを使わせるのは VMware View などのVDI環境でデスクトップ仮想マシンのパフォーマンスを上げるために必要な基本テクニックだ。
どうもこのお客様のお客様、つまりはエンドユーザの方が VMware Fusion 上で、Windows XP を実行している仮想マシンに Windows8 をアップグレードインストールした、そうだ。すると、アップグレードは成功したもののNICを認識しないので何とかしてほしいと相談を受けたとのこと。
まあそんなチャレンジャーなアップグレード良くやるなぁと思ったが、とりあえずNICが AMD PCnet だからではないかと推測、いくつかの方法を話をした。
この土日、折角なので個人的に調べてみた。
● 再現試験
実際に Windows XP Professional から Windows 8 Pro にアップグレードインストールしたところ、それ自体は成功した。が、確かにNICを認識していないのが分かった。
手持ちの Windows XP はIDE接続の仮想ディスクにインストールされており、やはりNICは AMD PCnet (vlance というかフレキシブル) であった。
 |
| アップデート前に確認、NICは AMD PCnet エミュレーションだった |
 |
| アップグレードしたところ、NICに×印がついている |
 |
| クリックしたところ、認識しているネットワーク接続がないことが記載される |
● 手っ取り早い対処法
手っ取り早く何とかしたい場合は、以下の手順を行えばいい。
なお、vmx ファイルを操作するという危険なことを行うので、バックアップは必ずとっておいてほしい
- 仮想マシンをシャットダウンし、VMware Fusion を終了させる
- 「仮想マシン名.vmwarevm」を右クリック、パッケージの内容を表示し、拡張子 .vmx ファイルを確認する
- 確認した vmx ファイルをテキストエディットなどで開き、一番下で良いので以下の行を追加する
ethernet0.virtualDev = "e1000e"
- ファイルを保存する
- VMware Fusion を起動し、仮想マシンを起動する
Fusion で作成したWindowsXP仮想マシンの場合、NICに対する virtualDev は指定されていない。指定されていない場合は AMD PCnet 扱いする。一方、Fusion で Windows8 仮想マシンを作成した場合は、上記の行が追加されており Etherexpress1000e 扱いされる。
VMware Workstation などでは NIC のタイプを指定することができるが、Fusion では簡単に指定する方法がない。なので、ここでは .vmx ファイルを直接編集、修正をしている。
なお、起動直後はまだNICは認識されない。しばらく待ってると下図の様なエラーが表示され、さらにしばらく待つとNICが追加される
 |
| しばらく待ってるとこの警告が出る |
 |
| さらに待つと「ネットワーク接続」にNICが現れる と同時に、右側に図にあるような選択画面が表示される |
● 余談
なお、私の WindowsXP 仮想マシンは、仮想ディスクがIDE接続だったためさして問題なくアップグレードできたが、SCSI接続の場合アップグレードに失敗する?らしい話も聞いている。
vSphere で WindowsXP 仮想マシンを作成すると、デフォルトでは BusLogic SCSI HBA を経由して仮想ディスクが接続される。おそらく、AMD PCnet のドライバーがなくなり上記のような問題が起こったように、BusLogic SCSI HBA のデバイスドライバーもなくなったのだろう。
だいたいにおいて、BusLogic SCSI HBA のエミュレーションは過去のOSとの後方互換に使われている。WindowsServer 2003 などでは LSI Logic のより新しいSCSI HBA が使われ、Windows7, 2008R2 などでは LSI Logic SAS HBA のエミュレーションが行われる。
おそらく、LSI Logic HBA のエミュレーションなら Windows8 でも利用可能なのだろうと思われる。
WindowsXP でも LSI Logic HBA エミュレーションを使うことは可能だが、インストールメディアに LSI Logic のSCSI HBA のドライバーが入ってないためそのままでは新規インストールに失敗する。LSI Logic のサイトなりからデバイスドライバをダウンロード、仮想フロッピーメディアに展開しておき、インストール時に追加するといい。
この WindowsXP で LSI Logic HBA のエミュレーションを使わせるのは VMware View などのVDI環境でデスクトップ仮想マシンのパフォーマンスを上げるために必要な基本テクニックだ。
2012/08/23
VMware Fusion 5 リリース、でも、買うのはちょっと待った方が
本業に追われてだいぶご無沙汰してしまった。
さて、米国時間で 8/23に、無事 VMware Fusion 5 と VMware Workstation 9 がリリースされた。
http://www.vmware.com/products/fusion/overview.html
Fusion 5 では Windows8 への最適化など新しい機能がある。また、私自身はまだ確認していないが、Fusion 4 に比べ複数の仮想マシンを実行した際のメモリ消費が抑えられているという体験談を聞いている。vSphere にある透過的メモリ共有に類する技術を使っているのか、はたまたこれまで無駄に消費してたのがダイエットしただけなのかは不明だが、確認を取ってみたいところだ。
また、Professional Edition ができたのも1つの特徴だ。
http://www.vmware.com/products/desktop_virtualization/fusion/professional.html
ネットワークエディタは Workstation ではおなじみだが、vmnet0-8 までのネットワークに任意の設定をする事が可能になるというものだ。
Fusion ではこれまで vmnet0 をブリッジ、vmnet1 をホストとの通信だけが可能なネットワーク、vmnet8 をNATを行うネットワークとして使用してきた。が、あいている vmnet2-7 に任意の設定のネットワークを作ってNATや仮想マシン間ネットワークを個別に用意できる。また、vmnet1 や vmnet8 のDHCPで配布されるIPレンジを変更なども可能になる。
制限された仮想マシンを作成できるらしいのもポイントだ。VMware Workstation ではかつて VMware ACE という拡張機能があり、暗号化され利用者が設定を変更のできない仮想マシンを作ることができた。暗号化自体は Fusion 4 よりサポートされていたが、より細かい制約が作れるようだ。
管理者が制約を作り、利用者に仮想マシンを配布する、といった用途が期待できる。
価格の方は、VMware Store で Fusion 5 が $49.99、Fusion 5 Professional が $99.99 だ。Fusion 5 へのアップグレードはなく買い直しになる模様。
一方、 Fusion 5 Professional については Fusion 3,4 からのアップグレードパスがある。こちらも $49.99 なので、すでに VMware Fusion を使ってる方は Professional 版にして細かい機能を楽しんでみるのもいいだろう。
また、Fusion 2012 TechPreview を使ってきたβテスターには、後ほどプロモーションコードが配布されるようだ。このパブリックベータでテストしてきたユーザは、購入を少し待った方がいいだろう。
なお、Fusion に限らず VMware 製品は、ダウンロードしてそのまま実行すると評価版として一定期間動作する。なので、すぐに買わなくてもしばらくは評価版として利用が可能だ。
業務で使うなど明確な商利用などの都合がない、パブリックベータを試してこれたような個人ユーザなら評価版で待ってても問題はないだろう。
さて、米国時間で 8/23に、無事 VMware Fusion 5 と VMware Workstation 9 がリリースされた。
http://www.vmware.com/products/fusion/overview.html
Fusion 5 では Windows8 への最適化など新しい機能がある。また、私自身はまだ確認していないが、Fusion 4 に比べ複数の仮想マシンを実行した際のメモリ消費が抑えられているという体験談を聞いている。vSphere にある透過的メモリ共有に類する技術を使っているのか、はたまたこれまで無駄に消費してたのがダイエットしただけなのかは不明だが、確認を取ってみたいところだ。
また、Professional Edition ができたのも1つの特徴だ。
http://www.vmware.com/products/desktop_virtualization/fusion/professional.html
ネットワークエディタは Workstation ではおなじみだが、vmnet0-8 までのネットワークに任意の設定をする事が可能になるというものだ。
Fusion ではこれまで vmnet0 をブリッジ、vmnet1 をホストとの通信だけが可能なネットワーク、vmnet8 をNATを行うネットワークとして使用してきた。が、あいている vmnet2-7 に任意の設定のネットワークを作ってNATや仮想マシン間ネットワークを個別に用意できる。また、vmnet1 や vmnet8 のDHCPで配布されるIPレンジを変更なども可能になる。
制限された仮想マシンを作成できるらしいのもポイントだ。VMware Workstation ではかつて VMware ACE という拡張機能があり、暗号化され利用者が設定を変更のできない仮想マシンを作ることができた。暗号化自体は Fusion 4 よりサポートされていたが、より細かい制約が作れるようだ。
管理者が制約を作り、利用者に仮想マシンを配布する、といった用途が期待できる。
価格の方は、VMware Store で Fusion 5 が $49.99、Fusion 5 Professional が $99.99 だ。Fusion 5 へのアップグレードはなく買い直しになる模様。
一方、 Fusion 5 Professional については Fusion 3,4 からのアップグレードパスがある。こちらも $49.99 なので、すでに VMware Fusion を使ってる方は Professional 版にして細かい機能を楽しんでみるのもいいだろう。
また、Fusion 2012 TechPreview を使ってきたβテスターには、後ほどプロモーションコードが配布されるようだ。このパブリックベータでテストしてきたユーザは、購入を少し待った方がいいだろう。
なお、Fusion に限らず VMware 製品は、ダウンロードしてそのまま実行すると評価版として一定期間動作する。なので、すぐに買わなくてもしばらくは評価版として利用が可能だ。
業務で使うなど明確な商利用などの都合がない、パブリックベータを試してこれたような個人ユーザなら評価版で待ってても問題はないだろう。
2012/06/27
Macbook Air で Windows XP を使う場合のライセンス
少々厄介な話になったので少しメモしておく。
Macbook Air や、今回発表になった Macbook Pro Retina ディスプレイモデルでは USB や Thunderbolt といったいくつかのインターフェイスを除いて拡張の余地がない。
たとえばメモリを増設したり、HDD/SSD を交換することが原則的にできなくなっている。
このため、 DSP版の Windows を購入することがほぼ不可能になっている。
本来ホワイトボックスPC向けに用意されている DSP版の Windows は安価な一方、サポートは販売店持ちとなり、かつ特定ハードウェアとの同時購入でそのハードウェアを使用しているコンピュータでの利用のみが許される。
特定のハードウェアは何でも良いという訳ではない。たとえば以下は DOS/V パラダイスのページだが、バンドル対象製品は、CPU、メモリ、HDD、SSD、光学ドライブ、マザーボード、ビデオカード、その帆は拡張カードと言う感じで「本体に組み込まれるもの」が前提となっている。
http://www.dospara.co.jp/5info/share.php?contents=info_win_dsp
USB接続のHDD など、本体を構成しない外付け機器やケースなどは対象外となっている。
これまで、巷で販売されている Windows ライセンス付きの VMware Fusion 製品は、その多くが「DSP版とのバンドル」で、よく見るとメモリなどがセットに含まれている。
ライセンス上は、そのメモリを使用した MacやPCでのみ、その Windows ライセンスは使用できる。
まあもちろん、一々そのメモリ(ないしは他の特定ハードウェア)を搭載しているかを確認する術はないし、確認して販売しているかは微妙、だろう。
しかし、Macbook Air、 Macbook Pro Retina ディスプレイモデルはそもそも拡張の余地がない。「できない」所に販売するのはさすがにできないだろう。
「Macbook Air や、今回発表になった Macbook Pro Retina でぃすぷれいもでるといった本体と同時に Windows ライセンスを購入」しない限り、後から仮想環境や BootCamp 用の OSライセンスをDSP版で購入することはできない訳だ。
なお、聞いた限り銀座などの AppleStore では DSP版の Windows は扱ってないようだ。
じゃあ、大人しくパッケージの Windows を買えばいいかというとこれも厄介な話がある。
なぜなら、パッケージの Windows にはダウングレード権がないからだ。
マイクロソフトの製品は、新バージョンが出ると旧バージョンの販売は終了してしまう。Windows7 が販売されている現在、Windows XP や Vista のパッケージはもう購入できない訳だ。(希に不良在庫がぽろっと出ることはあるが)
Windows7 を使いたい場合はそれでいいが、 仮想環境上で Windows XP を使いたい場合、ダウングレード権のないパッケージの Windows ではその役に立たないのだ。
(DSP版にはダウングレード権が存在する。)
あともう一つの方法はボリュームライセンスでの購入になる。ボリュームライセンスは法人利用を前提としたライセンスだけのまとめ買いシステムだが、別に個人が利用できない訳ではない。利用例は以下ページを参照してほしい
http://pc.watch.impress.co.jp/docs/topic/feature/20090911_314639.html
ボリュームライセンスで販売されるデスクトップ版の Windows は「アップグレード」のみで、フルライセンスは存在しない。つまりコンピュータにアップグレード対象となるOS が入っていないと利用できない。自作PCなどでOSなしで作られたPC にはインストールできない訳だ。
では Mac にも入れれないのでは?と思われるが、実は「アップグレード対象」には OS X も含まれるというのがポイント。これは以下ページに記載されている。
http://www.microsoft.com/ja-jp/licensing/about-licensing/windows7.aspx#tab=4
まとめると、後で拡張ができない、DSP版の Windows が買えない Macbook Air や Macbook Pro Retina ディスプレイモデルでは、以下の手段での購入となる
Macbook Air や、今回発表になった Macbook Pro Retina ディスプレイモデルでは USB や Thunderbolt といったいくつかのインターフェイスを除いて拡張の余地がない。
たとえばメモリを増設したり、HDD/SSD を交換することが原則的にできなくなっている。
このため、 DSP版の Windows を購入することがほぼ不可能になっている。
本来ホワイトボックスPC向けに用意されている DSP版の Windows は安価な一方、サポートは販売店持ちとなり、かつ特定ハードウェアとの同時購入でそのハードウェアを使用しているコンピュータでの利用のみが許される。
特定のハードウェアは何でも良いという訳ではない。たとえば以下は DOS/V パラダイスのページだが、バンドル対象製品は、CPU、メモリ、HDD、SSD、光学ドライブ、マザーボード、ビデオカード、その帆は拡張カードと言う感じで「本体に組み込まれるもの」が前提となっている。
http://www.dospara.co.jp/5info/share.php?contents=info_win_dsp
USB接続のHDD など、本体を構成しない外付け機器やケースなどは対象外となっている。
これまで、巷で販売されている Windows ライセンス付きの VMware Fusion 製品は、その多くが「DSP版とのバンドル」で、よく見るとメモリなどがセットに含まれている。
ライセンス上は、そのメモリを使用した MacやPCでのみ、その Windows ライセンスは使用できる。
まあもちろん、一々そのメモリ(ないしは他の特定ハードウェア)を搭載しているかを確認する術はないし、確認して販売しているかは微妙、だろう。
しかし、Macbook Air、 Macbook Pro Retina ディスプレイモデルはそもそも拡張の余地がない。「できない」所に販売するのはさすがにできないだろう。
「Macbook Air や、今回発表になった Macbook Pro Retina でぃすぷれいもでるといった本体と同時に Windows ライセンスを購入」しない限り、後から仮想環境や BootCamp 用の OSライセンスをDSP版で購入することはできない訳だ。
なお、聞いた限り銀座などの AppleStore では DSP版の Windows は扱ってないようだ。
じゃあ、大人しくパッケージの Windows を買えばいいかというとこれも厄介な話がある。
なぜなら、パッケージの Windows にはダウングレード権がないからだ。
マイクロソフトの製品は、新バージョンが出ると旧バージョンの販売は終了してしまう。Windows7 が販売されている現在、Windows XP や Vista のパッケージはもう購入できない訳だ。(希に不良在庫がぽろっと出ることはあるが)
Windows7 を使いたい場合はそれでいいが、 仮想環境上で Windows XP を使いたい場合、ダウングレード権のないパッケージの Windows ではその役に立たないのだ。
(DSP版にはダウングレード権が存在する。)
あともう一つの方法はボリュームライセンスでの購入になる。ボリュームライセンスは法人利用を前提としたライセンスだけのまとめ買いシステムだが、別に個人が利用できない訳ではない。利用例は以下ページを参照してほしい
http://pc.watch.impress.co.jp/docs/topic/feature/20090911_314639.html
ボリュームライセンスで販売されるデスクトップ版の Windows は「アップグレード」のみで、フルライセンスは存在しない。つまりコンピュータにアップグレード対象となるOS が入っていないと利用できない。自作PCなどでOSなしで作られたPC にはインストールできない訳だ。
では Mac にも入れれないのでは?と思われるが、実は「アップグレード対象」には OS X も含まれるというのがポイント。これは以下ページに記載されている。
http://www.microsoft.com/ja-jp/licensing/about-licensing/windows7.aspx#tab=4
ボリュームライセンスの利用には最低でも3アイテムの購入が必要なのが少々厄介だが、それは先の impress のページを見て対応してほしい。
まとめると、後で拡張ができない、DSP版の Windows が買えない Macbook Air や Macbook Pro Retina ディスプレイモデルでは、以下の手段での購入となる
- Macbook Air/Pro と同時にDSP版を購入する
- ボリュームライセンスの Windows 7 を購入する
- ダウングレード権を諦めて Windows 7 を使用する
- (開発/テスト/デモ限定)MSDN/Technet を利用する
2012/06/03
Mac で ESXi は動くのか?(2)
前回、Apple ハードウェアで ESXi が起動できるのは、公式には Xserve (Early2009)のみ、非公式でも Xserve とほぼ同じチップセットを採用した MacPro のみ、と記載した。
しかし世の中すごい人はいるもので、とうとう Mac mini で ESXi の起動に成功したようだ。
以下にあるが、要はNICドライバーを追加してこれまで認識しなかった Mac mini のオンボードNICを認識させたようだ。
http://paraguin.com/2012/01/10/the-mac-mini-vmware-esxi-5-server-part-2-installation/
これは、実機を入手したら確かめてみたいと思う。
しかし世の中すごい人はいるもので、とうとう Mac mini で ESXi の起動に成功したようだ。
以下にあるが、要はNICドライバーを追加してこれまで認識しなかった Mac mini のオンボードNICを認識させたようだ。
http://paraguin.com/2012/01/10/the-mac-mini-vmware-esxi-5-server-part-2-installation/
これは、実機を入手したら確かめてみたいと思う。
2012/05/13
Fusion で Mac OS X のカーネルデバッグ
● Kernel space is the last frontier
...とまでは言わないが、しかしカーネルコードをみたりいじったりするのは非常に楽しい。一方で、カーネル空間でのミスは簡単にOSクラッシュを引き起こす。なんだかんだいって OSがなんとかしてくれるユーザランドでのアプリケーション開発やブラウザの上のスクリプト書きとは違う厄介さがある。
通常、カーネル内に組み込まれるコードのデバッグには2マシンデバッグが行われる。開発中のコードを実行するテストマシンとは別にデバッグ用のマシンを用意し、何らかの方法で接続、デバッグ用のマシンでデバッガを動かし観察するというものだ。接続方法は、昔ならシリアルケーブル、最近だと(少々癖はあるが) TCP/IP が利用できる。
もっとも、私はこれまで2マシンデバッグできる贅沢な環境でコードを書いたことがない。昔作った W-ZERO3用のシリアルドライバは、気合い一発の printf デバッグだった...、ファイルに書き出す前に落ちるので、WindowServer 殺してコンソールモードにしてログをはき出させ、死んだ瞬間の画面をメモって開発するという。今にしてみれば呆れた方法だった。
Mac OS X はネットワーク越しの 2マシンデバッグをサポートしている。方法については Mac OS X のドキュメントに記載があるので読んでみると良い。
とはいえ、2台もMacを横に並べて開発を行うのは少々面倒だ。仮想環境を使えばこの2マシンデバッグも簡単にできるのではないか?という事で試してみた。
● 仮想環境でカーネルデバッグを行うには
まず Mac Developer Program には入っておいた方がいい。年 $99 の有償プログラムだが、その価値はあるだろう。
開発環境である Xcode は無償でダウンロードできる。なので有償プログラムに入らなくてもアプリケーションや KEXT の開発は出来なくもない。ただし Xcode 以外の開発リソース、例えばカーネルシンボルなどその他配布物が有償登録せずに手に入るかは確認していない。
Fusion を使った2マシンデバッグの大枠の手順は、以下のページに既に記載されている。先の Apple のドキュメントとあわせて読んでおくといいだろう。
上記記事を参考に、私のやった手順を以下に記す。
以降、Xcode4 で開発を行い、ビルドを実行するホスト環境を Develop Machine、実際にコードを実行しテストを行うゲスト環境を Target Machine と書く。
まず、仮想環境上に Mac OS X Lion をインストールする。
アップデートなどが終わったところで一度シャットダウン、停止状態でスナップショットをとっておく。今後何度も何度もクラッシュさせることになるので、安全な状態を確保しておくのは必要なことだ。
ゲスト環境のネットワーク接続は NAT のままで構わない。ただ、IPアドレスはDHCPではなく固定IPに書き換えておいた方が楽かも知れない。Fusion の DHCPサービスは概ね同じIPアドレスを割り当ててくれるが、変わると少々ややこしいことになるので気になる場合は固定IPに変更をしておくといい。
Develop Machine から Target Machine へファイルをコピーする手段を整えておく。ファイル共有を使ってもいいし、scp をつかっても良い。私は Target Machine のアカウントの .ssh/authorized_keys に Develop Machine での自分のアカウントのSSHの公開鍵を入れておき、パスワードなしで簡単コピーできるようにしておいた。
続けて、カーネルデバッグ特有の設定を行う。
Apple のドキュメントだと NVRAM に引数を設定するようになっているが、仮想環境では nvram ではなく /Library/Preferences/SystemConfiguration/com.apple.Boot.plist に記載する。このファイルは管理者権限ではないと編集できないので、sudo を使って vi なり nano なりで編集して欲しい。
デフォルトでは、
さらにカーネルクラッシュした場合に、画面の上にコンソールメッセージを出して止まってくれる。一般ユーザには忌み嫌われるクラッシュ画面だが、カーネル開発をしているときにはこの断末魔の悲鳴は重要なヒントになる。
debug=0x04 はデバッグオプションの設定で、Apple のドキュメントによると以下の通りだ
先の Reverse Engineering Mac OS X のドキュメントでは debug=0x01 を指定している。
Target Machine の起動時に一時停止されるので、その間に Develop Machine の GDB で接続するというものだ。その理由として「仮想環境でどうやって NMI を起こせばいいか分からなかった(because I couldn’t find a way to create NMI events inside the virtual machine.)」とある。
確かに通常は「Command-Option-Control-Shift-Escape」か「Command-Power」キー操作でNMIが発生すると Apple のドキュメントにはあるが、仮想マシン内ではこれはうまく動かないようだ。
そこで Reverse Engineering Mac OS X では起動時に一時停止する手段をとったが、これだと起動のたびに GDB の atacch が必要になり面倒だ。そこで、強制的にデバッガを起動する KEXT 「PseudoNMI」を用意した。
ソースコードは GitHub に置いたので好きにみてほしい。
https://github.com/shiro-t/PseudoNMI
使い方は以下の通りだ。
sysctl を実行すると、内部的にNMIが発行されたのと同じ処理が動く。debug=0x04 が設定定されていれば外部デバッガーの接続待ちになり、そうでなければクラッシュする。
接続は TCP/IP を通じて行われる。ただし、そのままでは上手くいかないので、あらかじめ ARPテーブルに設定が必要だ。
ARP テーブルとは IPアドレスと Ethernet でのハードウェアアドレス(MACアドレス)を紐付けする対応表で、通常はカーネルが自動的に保守をしている。
カーネルは知らないIPアドレスへの通信が行われる際に ARP というプロトコルを使ってそのIPアドレスに対応するMACアドレスを手に入れている。その都度手に入れていたのではネットワークに負荷がかかるので、カーネル内のメモリに一定期間保管している。このARPテーブルの内容は「arp -a」コマンドで確認できる。
ARPによる処理は自動的に行われるので通常は気にする必要がない。ただ、デバッガ起動時はどうも自動的に手に入れた値を全てクリアしてしまっているようで、そのままでは通信できなくなる。そこで、あらかじめ固定的な値を組み込んでおく必要があるのだ。
手順としては、まず、Develop Machine 側の IPアドレスとMACアドレスを手に入れる。これは仮想マシンがどの方式でネットワークに繋がっているかによる。NAT の場合は vmnet8 というホスト側の仮想NICを通じて仮想マシンと繋がっている。このNATネットワークは 「192.168.x.0/24」のネットワークで、x の部分はインストール時に決定される。
そして、192.168.x.1 はデフォルトルータとして使われ、Develop Machine そのものの通信は 192.168.x.2 で行われる。
192.168.x.2 に対応する MAC アドレスは、Develop Machine で ifconfig vmnet8 を実行するか、 Target Machine 側で arp -a で ARP テーブルを表示させて確認できる。
IPアドレスと MAC アドレスの対が分かったら、 Target Machine 側で以下コマンドを実行する
仮想マシンのネットワーク構成を変えない限りこの値は一定のため、以下設定を /Library/LaunchDaemons におくことで起動の都度 自動設定させることも可能だ。
このファイルを /Library/LaunchDaemons に配置したあとでリブートしてもよし、「sudo launchctl load /Library/LaunchDaemons/jp.nest.debug.static_arp.plist」を実行して読み込ませても良い。
これで、ゲスト側の準備は完了だ。
● ホスト環境(Develop Machine) でのデバッグ設定
さて、ホスト側の設定にうつる。
まず、Kernel Debug Kit を手に入れる。Kernel Debug Kit はシンボル情報(バイナリ中のどこがどの名前の関数に対応するかなどデバッグに必要な情報)が一式整ったものだ。OS のバージョンごとに存在するため、Lion の場合 kernel_debug_kit_10.7.3_11d50.dmg を手に入れる。入手先は http://developer.apple.com/sdk だ。
ダウンロード後、ダブルクリックしてイメージをマウントしておく。
必要に応じてカーネルのソースコードも手に入れておいた方がいいだろう。
http://opensource.apple.com から適切なバージョンを選んで、xnu-<xnuのバージョン> を選択、ダウンロードする。Lion (10.7.3) の場合は「xnu-1699.24.23」がそれだ。tar.gz アーカイブで手に入るので適当なところに展開しておく。カーネルソースがあれば、デバッガでソースコードを参照できる。
次に、ゲストで行ったのと同じ ARP テーブルの設定をホスト側でも行う。ゲスト側のNIC(en0)のIPアドレスと MAC アドレスを割り出した後
ここで準備は終了だ。
● ターゲットとなる KEXT を準備する
カーネルデバッグを行う最大の理由は、KEXT のデバッグであろう。
Xcode で開発を行い、KEXTをビルドする。ビルドすると KEXT と同じところに .sym のついたそのKEXTのシンボルファイルが生成されるのでこれも取得しておく。
開発した KEXT を Target Machine にコピーする。
コピー後には 「所有者とグループを root:wheel に」「グループとその他の書き込み権限を削除」を忘れないように。セキュリティ上の都合から権限が甘い KEXT は読み込まれないようになっている。
KEXT が正しくロードできるかについては、kextutil というコマンドで確認できる。
出来の悪い KEXT だとそういう可能性もあるので注意してほしい。
● カーネルデバッグを行う
Develop Machine 側で GDB を立ち上げる
以下コマンドを入力、準備を行う
Target Machine 側にうつって以下コマンドを実行、PseudoNMI が存在するのを確認する
存在していれば以下を実行する
すかさず Develop Machine 側で入力だけしておいた attach コマンドを実行する。
ARP テーブルが固定化されており、ちゃんと通信が出来るなら即座に「Connected.」と表示されプロンプトが表示される。もしそうならない場合は、ARPテーブルの設定忘れなので改めて設定をおこなってほしい。
接続できたら「gdb> c」 と c(ontinue) コマンドを実行する。すると、止まっていたゲストOSの実行が再開される。
これでGDBが接続された状態になっている。あとはブレークポイントを設定するなり、クラッシュしたらスタックトレースを引っ張るなりいつものデバッグができる。
...とまでは言わないが、しかしカーネルコードをみたりいじったりするのは非常に楽しい。一方で、カーネル空間でのミスは簡単にOSクラッシュを引き起こす。なんだかんだいって OSがなんとかしてくれるユーザランドでのアプリケーション開発やブラウザの上のスクリプト書きとは違う厄介さがある。
通常、カーネル内に組み込まれるコードのデバッグには2マシンデバッグが行われる。開発中のコードを実行するテストマシンとは別にデバッグ用のマシンを用意し、何らかの方法で接続、デバッグ用のマシンでデバッガを動かし観察するというものだ。接続方法は、昔ならシリアルケーブル、最近だと(少々癖はあるが) TCP/IP が利用できる。
もっとも、私はこれまで2マシンデバッグできる贅沢な環境でコードを書いたことがない。昔作った W-ZERO3用のシリアルドライバは、気合い一発の printf デバッグだった...、ファイルに書き出す前に落ちるので、WindowServer 殺してコンソールモードにしてログをはき出させ、死んだ瞬間の画面をメモって開発するという。今にしてみれば呆れた方法だった。
Mac OS X はネットワーク越しの 2マシンデバッグをサポートしている。方法については Mac OS X のドキュメントに記載があるので読んでみると良い。
とはいえ、2台もMacを横に並べて開発を行うのは少々面倒だ。仮想環境を使えばこの2マシンデバッグも簡単にできるのではないか?という事で試してみた。
● 仮想環境でカーネルデバッグを行うには
まず Mac Developer Program には入っておいた方がいい。年 $99 の有償プログラムだが、その価値はあるだろう。
開発環境である Xcode は無償でダウンロードできる。なので有償プログラムに入らなくてもアプリケーションや KEXT の開発は出来なくもない。ただし Xcode 以外の開発リソース、例えばカーネルシンボルなどその他配布物が有償登録せずに手に入るかは確認していない。
Fusion を使った2マシンデバッグの大枠の手順は、以下のページに既に記載されている。先の Apple のドキュメントとあわせて読んでおくといいだろう。
"Reverse Engineering Mac OS X : Mac OS X Kernel debugging with VMware"上記の記事は、まだ Lion のリリースされていない 2009 年のもののため、OS X のインストール方法が少々あやしいことを書いていたりするが、さくっと忘れてほしい。Lion の場合は インストールアプリケーションの下から InstallESD.iso さえ取り出せれば、細工せずとも普通にインストールが可能だ。
http://reverse.put.as/2009/03/05/mac-os-x-kernel-debugging-with-vmware/
上記記事を参考に、私のやった手順を以下に記す。
以降、Xcode4 で開発を行い、ビルドを実行するホスト環境を Develop Machine、実際にコードを実行しテストを行うゲスト環境を Target Machine と書く。
● ゲスト環境( Target Machine ) での準備
アップデートなどが終わったところで一度シャットダウン、停止状態でスナップショットをとっておく。今後何度も何度もクラッシュさせることになるので、安全な状態を確保しておくのは必要なことだ。
ゲスト環境のネットワーク接続は NAT のままで構わない。ただ、IPアドレスはDHCPではなく固定IPに書き換えておいた方が楽かも知れない。Fusion の DHCPサービスは概ね同じIPアドレスを割り当ててくれるが、変わると少々ややこしいことになるので気になる場合は固定IPに変更をしておくといい。
Develop Machine から Target Machine へファイルをコピーする手段を整えておく。ファイル共有を使ってもいいし、scp をつかっても良い。私は Target Machine のアカウントの .ssh/authorized_keys に Develop Machine での自分のアカウントのSSHの公開鍵を入れておき、パスワードなしで簡単コピーできるようにしておいた。
続けて、カーネルデバッグ特有の設定を行う。
Apple のドキュメントだと NVRAM に引数を設定するようになっているが、仮想環境では nvram ではなく /Library/Preferences/SystemConfiguration/com.apple.Boot.plist に記載する。このファイルは管理者権限ではないと編集できないので、sudo を使って vi なり nano なりで編集して欲しい。
デフォルトでは、
<?xml version="1.0" encoding="UTF-8"?>となっているのを
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Kernel Flags</key>
<string></string>
</dict>
</plist>
<?xml version="1.0" encoding="UTF-8"?>に修正する。「-v」は verbose オプションで、起動時に黒画面に起動メッセージが表示されるようになる。
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Kernel Flags</key>
<string>-v debug=0x04 pmuflag=1</string>
</dict>
</plist>
 |
| -v を指定すると、起動中のメッセージが表示される |
 |
| 通常のクラッシュ時の画面 |
 |
| debug= でカーネルデバッグを指定した場合 MACアドレスとIPアドレスが表示されているのが分かる |
 |
| -v オプションを指定した場合 |
debug=0x04 はデバッグオプションの設定で、Apple のドキュメントによると以下の通りだ
シンボル
| フラグ値 |
意味
|
| DB_HALT | 0x01 | OS起動時に一時停止を行い、デバッガーの接続を待つ |
| DB_PRT | 0x02 | コンソール画面に kernel 内の printf 出力を表示させる |
| DB_NMI | 0x04 | NMI (Non Maskable Interrupt) 信号でOSを一時停止しデバッガーに落とす |
| DB_KPRT | 0x08 | kprintf の出力をシリアルポートに出す |
| DB_SLOG | 0x10 | 外部のGDBではなく組み込みのddb(kdb)をデフォルトデバッガにする (ただし、通常のDarwinカーネルにddb は組み込まれていない) |
| DB_ARP | 0x20 | デバッガに ARP テーブルの操作やルータを介した通信を許す(セキュリティーホールになるので注意) -- なお、どのカーネルにも本機能は含まれていない |
| DB_KDP_BP_DIS | 0x08 | 古いGDBをサポートする |
| DB_LOG_PI_SCRN | 0x08 | グラフィカルなクラッシュ画面を表示させない |
先の Reverse Engineering Mac OS X のドキュメントでは debug=0x01 を指定している。
Target Machine の起動時に一時停止されるので、その間に Develop Machine の GDB で接続するというものだ。その理由として「仮想環境でどうやって NMI を起こせばいいか分からなかった(because I couldn’t find a way to create NMI events inside the virtual machine.)」とある。
確かに通常は「Command-Option-Control-Shift-Escape」か「Command-Power」キー操作でNMIが発生すると Apple のドキュメントにはあるが、仮想マシン内ではこれはうまく動かないようだ。
そこで Reverse Engineering Mac OS X では起動時に一時停止する手段をとったが、これだと起動のたびに GDB の atacch が必要になり面倒だ。そこで、強制的にデバッガを起動する KEXT 「PseudoNMI」を用意した。
ソースコードは GitHub に置いたので好きにみてほしい。
https://github.com/shiro-t/PseudoNMI
使い方は以下の通りだ。
- この PseudoNMI.kext をダウンロード
- パーミッションなどを調整する(所有権は root:wheel で、読み取りと実行のみに)
- 「sudo kextload ./PseudoNMI.kext」でカーネルに組み込む。
- 「sudo sysctl -w debug.pseudo_nmi=1」を実行する
sysctl を実行すると、内部的にNMIが発行されたのと同じ処理が動く。debug=0x04 が設定定されていれば外部デバッガーの接続待ちになり、そうでなければクラッシュする。
接続は TCP/IP を通じて行われる。ただし、そのままでは上手くいかないので、あらかじめ ARPテーブルに設定が必要だ。
ARP テーブルとは IPアドレスと Ethernet でのハードウェアアドレス(MACアドレス)を紐付けする対応表で、通常はカーネルが自動的に保守をしている。
カーネルは知らないIPアドレスへの通信が行われる際に ARP というプロトコルを使ってそのIPアドレスに対応するMACアドレスを手に入れている。その都度手に入れていたのではネットワークに負荷がかかるので、カーネル内のメモリに一定期間保管している。このARPテーブルの内容は「arp -a」コマンドで確認できる。
ARPによる処理は自動的に行われるので通常は気にする必要がない。ただ、デバッガ起動時はどうも自動的に手に入れた値を全てクリアしてしまっているようで、そのままでは通信できなくなる。そこで、あらかじめ固定的な値を組み込んでおく必要があるのだ。
手順としては、まず、Develop Machine 側の IPアドレスとMACアドレスを手に入れる。これは仮想マシンがどの方式でネットワークに繋がっているかによる。NAT の場合は vmnet8 というホスト側の仮想NICを通じて仮想マシンと繋がっている。このNATネットワークは 「192.168.x.0/24」のネットワークで、x の部分はインストール時に決定される。
そして、192.168.x.1 はデフォルトルータとして使われ、Develop Machine そのものの通信は 192.168.x.2 で行われる。
192.168.x.2 に対応する MAC アドレスは、Develop Machine で ifconfig vmnet8 を実行するか、 Target Machine 側で arp -a で ARP テーブルを表示させて確認できる。
IPアドレスと MAC アドレスの対が分かったら、 Target Machine 側で以下コマンドを実行する
sudo arp -s 192.168.x.2 aa:aa:aa:aa:aa:aaこれでOSが再起動されるまで削除されない ARPテーブルの設定がなされる。
仮想マシンのネットワーク構成を変えない限りこの値は一定のため、以下設定を /Library/LaunchDaemons におくことで起動の都度 自動設定させることも可能だ。
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>jp.nest.debug.static_arp</string>
<key>ProgramArguments</key>
<array>
<string>/usr/sbin/arp</string>
<string>-s</string>
<string>192.168.203.2</string>
<string>0:50:56:f6:cc:a8</string>
</array>
<key>RunAtLoad</key>
<true/>
</dict>
</plist>
このファイルを /Library/LaunchDaemons に配置したあとでリブートしてもよし、「sudo launchctl load /Library/LaunchDaemons/jp.nest.debug.static_arp.plist」を実行して読み込ませても良い。
これで、ゲスト側の準備は完了だ。
● ホスト環境(Develop Machine) でのデバッグ設定
さて、ホスト側の設定にうつる。
まず、Kernel Debug Kit を手に入れる。Kernel Debug Kit はシンボル情報(バイナリ中のどこがどの名前の関数に対応するかなどデバッグに必要な情報)が一式整ったものだ。OS のバージョンごとに存在するため、Lion の場合 kernel_debug_kit_10.7.3_11d50.dmg を手に入れる。入手先は http://developer.apple.com/sdk だ。
ダウンロード後、ダブルクリックしてイメージをマウントしておく。
必要に応じてカーネルのソースコードも手に入れておいた方がいいだろう。
http://opensource.apple.com から適切なバージョンを選んで、xnu-<xnuのバージョン> を選択、ダウンロードする。Lion (10.7.3) の場合は「xnu-1699.24.23」がそれだ。tar.gz アーカイブで手に入るので適当なところに展開しておく。カーネルソースがあれば、デバッガでソースコードを参照できる。
次に、ゲストで行ったのと同じ ARP テーブルの設定をホスト側でも行う。ゲスト側のNIC(en0)のIPアドレスと MAC アドレスを割り出した後
sudo arp -s <IPアドレス> <MACアドレス>を実行する。Develop Machine側 vmnet8 のIPアドレスは常に一定だが、ゲスト( Target Machine )側の en0 のIPアドレスは、デフォルトではDHCPのため変わることがありえるので注意だ。冒頭にも書いたように、変わるのが面倒な場合は固定IPアドレスにしてしまうといい。
ここで準備は終了だ。
● ターゲットとなる KEXT を準備する
カーネルデバッグを行う最大の理由は、KEXT のデバッグであろう。
Xcode で開発を行い、KEXTをビルドする。ビルドすると KEXT と同じところに .sym のついたそのKEXTのシンボルファイルが生成されるのでこれも取得しておく。
開発した KEXT を Target Machine にコピーする。
コピー後には 「所有者とグループを root:wheel に」「グループとその他の書き込み権限を削除」を忘れないように。セキュリティ上の都合から権限が甘い KEXT は読み込まれないようになっている。
KEXT が正しくロードできるかについては、kextutil というコマンドで確認できる。
sudo kextutil Foo.kextなお、私はこの kextutil でチェックしてる時にクラッシュしたことがある。
出来の悪い KEXT だとそういう可能性もあるので注意してほしい。
● カーネルデバッグを行う
Develop Machine 側で GDB を立ち上げる
gdb /Volumes/KernelDebugKit/mach_kernelKernel Debug Kit をマウントしていると、/Volumes 以下にマウントされているはずだ。
以下コマンドを入力、準備を行う
gdb$ target remote-kdp以下のコマンドを入力だけ行い、リターンを押さずに置いておく
gdb$ attach <Target Machine のIPアドレス>
Target Machine 側にうつって以下コマンドを実行、PseudoNMI が存在するのを確認する
sysctl debug.pseudo_nmi正常ならば「debug.pseudo_nmi: 0」と返ってくるはずだ。
存在していれば以下を実行する
sudo sysctl -w debug.pseudo_nmi=1すると、実行した瞬間にゲストOS上の Mac OS X の実行が停止される。
すかさず Develop Machine 側で入力だけしておいた attach コマンドを実行する。
ARP テーブルが固定化されており、ちゃんと通信が出来るなら即座に「Connected.」と表示されプロンプトが表示される。もしそうならない場合は、ARPテーブルの設定忘れなので改めて設定をおこなってほしい。
接続できたら「gdb> c」 と c(ontinue) コマンドを実行する。すると、止まっていたゲストOSの実行が再開される。
これでGDBが接続された状態になっている。あとはブレークポイントを設定するなり、クラッシュしたらスタックトレースを引っ張るなりいつものデバッグができる。
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 をこちら においたので、もし試したい場合は以下の手順でいけるだろう。(要追試)
- (必要かはまだ絞り込めていないが)、とりあえず4GB はメモリを持った仮想マシンを作っておく
- FreeBSD 9.0R を普通インストールする
- http://bhyve.org にリンクされている bhyve-0.0.1r225757.tar をダウンロードする
- pkg_add <ダウンロードした bhyve-0.0.1r225757.tar> でインストールする
- /boot/kernel/vmm.ko を上記のパッチ済みのもので差し替える
- http://bhyve.org にリンクされているゲストイメージをダウンロードする。1GB/400MBどちらでもよい
- xz -cd <ゲストイメージ.tar.xz> | tar xf - で展開する
- 出来たフォルダを # mv ./bhyve-guest-400mb /usr/bhyve-guest で /usr/ 以下に配置する(トップフォルダの名前をリネームするので要注意)
- /boot/loader.conf を作成、以下の情報を書き込む(2GBをホストに割り振る)
- 再起動して設定を生かす
- root で cd /usr/bhyve-guest から sh ./vmprep.sh でカーネルモジュールを読み込ませる
- sh ./vmrun.sh で仮想マシンを起動する
hw.physmem="0x80000000"
debug.witness.watch="0"
詳細なことはまた改めて書く。
登録:
投稿 (Atom)