[余談] MacOS X のVPN接続をコマンドラインから実行する

仮想化とは関係ないけど、余談で。

MacOS X では VPN接続機能が用意されており、システム環境設定の「ネットワーク」にて、左下の「+」ボタンを押すことで設定が可能になる。標準で用意されているのは、L2TP over IPsec, PPTP, Cisco IPSec の三つだ (Lion の場合)

それぞれを選択、アカウントなど適宜情報を記入することで L2で VPNを張ることができる。

ただ、その接続がシステム環境設定を開いて該当するネットワーク設定を選択、「接続」ボタンを押すか、メニューバーにVPN設定のアイコンをあらかじめ表示させておき、そこから選ぶか、になる。

そう頻繁にVPNを張らない人や、MacBookAir を利用しててメニューバーの横幅が足りないのであまりアイコンを表示させたくない人からすれば、一々システム環境を開くのは面倒だ。

そこで、ターミナルのコマンドラインから VPNを張れないかを調べてみた。
とりあえず、ざっと調べた限りではそれっぽいコマンドは見つけられなかった。のでスクリプトで対応させることとした。

#!/bin/sh
DoScript() {
/usr/bin/osascript << __EOF__
tell application "System Events"
   tell current location of network preferences
       set VPNservice to service "$2"
       if exists VPNservice then $1 VPNservice
   end tell
end tell
__EOF__
    return 0 ;
}
case $1 in
"connect")
    DoScript "connect" $2 ;;
"disconnect")
    DoScript "disconnect" $2 ;;
esac

DoScript 関数がこのシェルスクリプトの実体で、osascript にヒアドキュメントで AppleScript を流し込み、実行している。

tell application "System Events" により SystemEvents に対して指示を送り、さらにその中で「current location of network preferences」、つまり現在のネットワーク設定に指示を送っている。
OS X をあまり使われてない方には馴染みのないことだが、OS X では「場所」ないしは「ネットワーク環境」という名前で、使用するネットワークインターフェイスやインターフェイス冠の優先順位、IPアドレス、DNS、デフォルトルート、プロクシーなどの設定をまとめて切り替えることができる。ネットワーク管理をやってた頃はいく先々ごとにこのネットワーク環境を作り、ついたら切り替えることでたとえ固定IPアドレスや特別なプロクシの設定が必要でも一気に切り替えられたので便利なのだ。
ThinkPad など一部のベンダーのPCにも同様の機能はあるが、OS標準でないため細かいところで面倒だったのと、やはりUNIXコマンドが標準搭載なのもあり Macのノートは私の回りのネットワーク管理者にとっては必須のデバイスであった。

何を送ってるかというと $2 にはVPNサービス名が入り、$1 には connect か disconnect が入るため、set VPNservice to service "何らかのVPNサービス名" で、VPNService という変数にサービス名を突っ込む。

それから、if exist VPNservice でそのサービス名に該当する設定があるかを確認、あれば $2, つまり connect(接続)もしくは disconnect(切断)を行う。

case でくるんでるのは、コマンドラインからは connect でも start でもよくしようとして、途中で面倒になったからそうなっているだけだ。( "connect") を "connect"|"start") とかするだけなのだが)

さて、このスクリプトを vpnc という名前でパスの通るところに保存、実行フラグを立てる。システム環境設定のネットワークから「MyOffice」というVPN設定を作った後

$ vpnc connect MyOffice

とコマンドを叩けば、接続される訳だ。
なお、厳密には「接続を指示する」ところでこのスクリプトは終了してしまう。VPNの接続確立までに時間がかかる場合は、そのぶん待った方がいい。

私は接続先に既知のサーバがあるので、ちょっと待ってから ping を打って繋がってる確認した後に利用するようにしている。

もう少し頑張ればVPN明があるかをチェックしてなければエラーを返すとか、色々改善もできるだろうが私の用途ではこれで十分なのでそこから直していない。

USBメモリから起動するOSを仮想マシンで利用する(1)

先日、とある事情にてUSBメモリに書き込まれたOS (Linux) を仮想環境上で起動することになった。その時の手順のメモ。

残念ながら、VMware Fusion は、いや VMware Workstation もその他製品も、USBメモリからのブートを直接対応していない。起動可能なデバイスは仮想環境上で

HDD, 光学ドライブ, FD と認識されるものか、ネットワークブート(PXE)だけだ。

これは、VMware が実現している仮想ハードウェアが Intel 440BX という90年代中盤に存在したチップセットのエミュレーションをしていることが遠因だ。

当時は CD-ROM ブートですらできるとは限らなかった。( Windows NT4 や OS/2 Warp など当時のOSはフロッピーで起動、ドライバを読み込んでからインストール用のCDを認識したものだ。)
そもそも USBについては  Windows 98 の登場までほとんど利用できず、実質的な普及は98年末の iMac の爆発的な普及の後からだ。USB起動は考えられてなかったのは仕方のないことだ。

この時はあまり時間もなかったので手っ取り早い手段で解決した。

● Plop Boot Manager

Plop Boot Manager はその名の通りOSの起動を制御するブートマネージャで、HDD や CD-ROM, USB メモリからOSを読み込み、起動させることができる。

この記事を書いてる時点の最新は 5.0.14 。実は試したときは 5.0.13 だったがそう大きな差はない。上記のダウンロードページから zip ファイルをダウンロード、展開すると iso イメージが入っている。

この iso イメージを、仮想マシンの設定の CD/DVD にて選択、仮想マシンに割り当てる。

そして仮想マシンを起動する。

まだOSを入れていない、空の仮想マシンならそのまま PLoP Boot Manager が起動する

なお、VMware は HDD にOSが入ってるとそちらから優先して起動される。CD/DVD ドライブから起動したい場合は設定の「起動ディスク」から選択するか、仮想マシンの起動直後、VMware のロゴの BIOS初期化中にタイミング良くウィンドウをクリックしキーボードのフォーカスを入れて F2 を押すと表示される Phonix BIOS の Boot メニューから CD-ROM の優先順位を上げるといい。後者は VMware  製品共通だが、タイミングが難しいので Fusionなら前者を選ぶのが良いだろう。

ともあれ、PLoP Boot Manager が起動すると星の流れる校歌の右上に「FLOPPY」「CDROM」「USB」といったメニューが表示されている。おもむろにUSBメモリを挿し、仮想マシン側へ割り当てた後にこのメニューからUSBを選択すると、USBメモリ内のOSで起動される。

ただし、製品にもよるが USB メモリからの起動は決して速くない。

結局のところ、Ubuntu Linux のインストールメディアから仮想マシンを起動、dd コマンドで USBメモリの内容を頭から丸ごと仮想ハードディスクに丸々コピーし、そちらから起動するようにしてしまった。フロッピーや CD/DVD-ROM などと異なり、USB メモリのレイアウトはHDDと同様なので、MBRから丸ごと全部コピーしてやればだいたい動いてしまうのだ。

VMware Fusion で XP Mode は動くの?

VMware Fusion 上の Windows7 で XP Mode は動作するかどうか、というと動作する。
これは VMware の KB(ナレッジベース)で説明されている。

・Using Windows 7 Virtual PC XP Mode in Fusion
http://kb.vmware.com/kb/1017526

英文を読むと「ハードウェア仮想化機能が仮想マシン上にはないので XP Mode が動かない」とある。さらに読めば「MSからパッチが出てるので適用せよ」となっている。

以下は XP Mode のダウンロードページだが、持っている Windows7 のエディションと言語を選択すると 3つのコンポーネントがダウンロードできる。

「最初にインストール」とあるのは XP Mode の仮想マシン。VHD 形式のイメージと構成ファイルが用意されている。

「2番目にインストール」とあるのが Windows Virtual PC 。フリーで配布されている Virtual PC 2007 と違い、Windows7 専用のホスト型仮想化ソフトウェアで、エクスプローラとの統合されてて扱いやすい一方、同時に1つしか仮想マシンを実行できないという違いがある。細かい違いは MSのFAQを参照。

なお、この時点ではまだ Intel-VT や AMD-V といったハードウェア仮想化機能が CPU に搭載されている悲痛用がある。

元々はこの2つをダウンロード、実行すれば良かったのだが、Windows7 登場時は思いの外 ハードウェア仮想化に対応したCPUを持つデスクトップマシンが少なかった。

また、ハードウェア仮想化機能は BIOSでPC起動時に有効化する必要があるのだが、対応CPUを搭載していてもほとんどの場合BIOSでは無効化されており、BIOS設定を変更して有効化する必要がある。一部PCに至っては BIOSにこの設定がなく(削除されており)、ハードウェア仮想化機能を有効化することができない。

デフォルトで無効なのは、使わないのにハードウェア仮想化機能が有効化されていると、そこにウィルスが入り込みOSの下に潜みこむことができてしまうから、つまりはセキュリティ上の要請からなのだが、さすがにどうやっても有効化できない、ってのはやり過ぎた。

筆者は Windows7 の登場時、何度も「このパソコンは XP Mode が利用できるか」や「XP Mode が利用できるパソコンを見積もって欲しい」という依頼を受けたが、ハードウェア仮想化機能を有効化できるかはメーカに聞いても教えてくれない事があまりに多く閉口したことがある。

普段扱っているサーバ機器でメーカ窓口が Intel-VT を有効化できるかできないかを知らないなんてあり得ない話だが、当時のデスクトップ/ノートPC側のサポート窓口ではまだそのような情報は出回ってなかったようだ。

結局、オンラインでダウンロードできるマニュアルをさがし、BIOS設定項目を探したものなのだ。

閑話休題。

ともあれ、マイクロソフトが思った以上にハードウェア仮想化機能はデスクトップ環境に広まってなかった。そこで「ハードウェア仮想化機能がなくても Windows Virual PC を動かせるパッチ」( KB977206 )が提供された。

上記ページで、「三番目にインストール」とある Windows XP Mode update が、この KB977206 のパッチなのだ。

つまり、3つ目までインストールした時点で、ハードウェア仮想化機能がなくても Windows Virtual PC が使えるようになる。

VMware の KB に記載されているのはこの KB977206 を適用せよ、という事なのだ。

なお、Windows Virtual PC が起動する際に NICをプロミスキャスモードに設定する。

VMware Fusion で Windows7 を実行、その上で XP Mode を使おうと Windows Virtual PC を起動すると仮想NICをプロミスキャスモードに設定しようとして、Fusion が警告パネルを表示するだろう。

全くの余談だが vSphere (ESX/ESXi) 上の Windows7 で XP Mode を使おうとするとこの点が問題になる。ESX/ESXi の仮想スイッチ上にポートグループのデフォルト設定では、プロミスキャスモードの設定を許可していない。リモートデスクトップなどで Windows7 仮想マシンに接続しながら XP Mode を有効にするとプロミスキャスモードへの移行を拒否する余波でリモートデスクトップが切れてしまい、何が何だか分からなくなる。

対処法はプロミスキャスモードを許可したポートグループに仮想NICを接続すること、だ。

VMware Fusion の「言語固有のキー マッピングを有効にする」 について

某勉強会で話したことの転載。

VMware Fusion の環境設定にある 「言語固有のキー マッピングを有効にする」 について。

結論から言うと、日本人はまったく気にする必要がない。

VMware Fusion のマニュアルによると、以下の機能を持つ

入力メニューをサポートされるキーボード レイアウトに変更すると、追加のキー マッピングがキー マッピング リストに追加されます。現在、VMware Fusion はフランス語とドイツ語をサポートしています。この機能は、Mac OS X Server 仮想マシンでは使用できません。

「追加のキーマッピング」とはなんぞや?と思われるが、これはフランス語やドイツ語のキーボードにある追加キーが有効になる機能を意味する。

日本語のキーボードにある「かな」「英数」などについてはこのチェックの有無にかかわらず、日本語キーボードを繋いでいれば利用可能だ。

つまり、日本人が日本語環境や英語環境で VMware Fusion を利用、仮想マシンを実行する限りは何の意味も持たない。気にする必要はないのだ。

VMXNET3 を使用した Windows7/ Windows2008 仮想マシンをクローンするとNICの名前が変わってしまう

● 問題

vSphere 環境にて、VMXNET3 を利用した、ゲストOSとして Windows7 もしくは Windows Server 2008 R2 をインストールした仮想マシンのクローンを取ると、ゲストOS上のネットワークデバイスの前が「ローカルエリア接続」ではなく「ローカルエリア接続 2」など、後ろに数字が付加されてしまう。

● 原因

この件に関する VMware 社の KB は以下の通り。

"Deploying Windows 2008 R2 and Windows 7 templates with vmxnet3 renames the NIC as #2"

http://kb.vmware.com/kb/1020078

上記に書いてあるとおりなのだが、かいつまんで説明すると...

Windows7/2008R2 では、PCIスロット上のデバイスは PCIのスロットIDをもって識別される。このため、あるPCI デバイスを別のスロットに挿すと「新しいデバイス」と見なされ別の認識をされる一方、同じスロットに同じ種類のカードで別のものを挿しても「同じデバイス」と見なされる。

例えばNICの場合、同じNICを別のスロットに移すと別NICと見なされる一方、異なるMACアドレスを持つ別の同メーカのNICを同じスロットに挿すと「同じNIC」扱いされて前と同じ設定が適用される。

一方、PCI Express に接続されたデバイスの場合はデバイスのシリアル番号などを引っ張って唯一性を確認するだけだ。例えばNICならば MACアドレスで違いを確認する。MACアドレスが同じならどのスロットにあっても同じデバイス、MACアドレスが異なれば同じスロットでも違うデバイス、扱いになる。

ここまで聞くと正しいと言えば正しいのだが、問題は仮想マシンでクローンを行った場合。

仮想NICでも Intel EtherExpress 互換(e1000) や AMD PCnet32 互換(フレキシブル) は PCIバス接続と見なされている。なのでクローンされて、MACアドレスが変わってしまっても「同じNIC」と見なされ、ゲストOSである Windows のレジストリにあるクローン前のNICの設定がそのまま利用される。

一方、VMXNET3は PCI Express 上に繋がっていると見なされるので、クローンされてMACアドレスが異なると「違うデバイス」扱いになる。レジストリにはクローン前の元のNICの設定とは別の設定が作られる。クローン前の設定が「ローカルエリア接続」ならば、新しく作られた方は「ローカルエリア接続 2」などになってしまうわけだ。

しかも、クローン前のMACアドレスを持つNICは繋がれないのにレジストリに設定が残ってしまって「ローカルエリア接続」の名前を占めてしまうので、できあがった「ローカルエリア接続 2」を「ローカルエリア接続」に名前変更を試みても失敗する。

● 対応

要するに Windows の挙動の問題のため、Windows 側にパッチを当てるしかない。

パッチは以下のマイクロソフトのKB から入手可能

• SP1以前の場合 : http://support.microsoft.com/kb/2344941
• SP1およびそれ以降のSPを適用後の場合 :  http://support.microsoft.com/kb/2550978

それぞれのページの上の方に「View and request hotfix downloads」というリンクがあるのでこれをクリック、ダウンロードするパッチを選択、メールアドレスを記入、CAPTCHA を記入後、「リクエストを送信する」ボタンを押すと、パッチの入手先がメールで届く。

なお、パッチは x86, x64, ia64 でそれぞれ別物なので注意。普通は x86 と x64 が必要になるだろう。通常は現在実行しているアーキテクチャだけが表示されているので、「Show hotfixes for all platforms and languages」あるいは「すべての環境、言語用の修正プログラムを表示する」のリンクをクリックすると全部のパッチが見えるので、適切なチェックを入れるといい。

メールのリンクをクリックすると、自己解凍形式の EXE ファイルがダウンロードされる。

これを実行すると、拡張子 .msu のパッチが出てくるので、"クローン元になる仮想マシンの Windows" にこのパッチを適用する。

適用後にクローンを行うと、この問題は発生しなくなる。

● ワークアラウンド

なお、問題は VMXNET3 で起こるものなので、e1000 やフレックスを使っていれば問題は発生しない。

発生した場合も以下のサイトを参照にゴースト化してしまったクローン前のNICの設定情報をレジストリから削除してしまえば名前をもどす事が可能になる。

・ネットワーク アダプターに IP アドレスを設定する際のエラー メッセージ

http://support.microsoft.com/kb/269155/ja

・第22回 Installer Clean Upユーティリティはどこにある？ 仮想マシンIDって何？ ゴーストNICを削除するには？

・デバイスマネージャに表示されないネットワークアダプタを削除する方法

http://last-resort.seesaa.net/article/152702546.html

VMware Fusion でリンククローンを実現する

リンククローンとは、vCenter LabManager, VMware View (ViewComposer), vCloud Director などで実現されている機能で、親となる仮想マシンに対する差分だけの仮想マシンを作成、実行する機能だ。

同様の構成の仮想マシンが複数ある場合、共通部分を親で実装した後にリンククローンで展開することで共通部分の占めるディスク領域を削減でき、さらに差分だけ作ればいいので高速に展開ができる。

この機能は VMware Workstation にも搭載されており、ちょっとした検証時にディスク容量を気にせず仮想マシンを生み出せるので重宝してるのだが、残念ながら VMware Fusion には搭載されていない。

( そもそも、VMwareFusion には仮想マシンの複製機能が搭載されていない。)

これは不便だ、ということで試してみたのが以下手順。

● そもそものリンククローンの実装を見てみる

VMware View で搭載された ViewComposer はやや特殊だが、それ以外の実装は概ねスナップショットの仕組みを利用している。VMware におけるスナップショットは、「その時点でのディスクイメージを書き込み不可に設定」(+必要に応じてその瞬間のメモリ内容や仮想マシンの状態をファイルに出力)することである時点の状態を保持するものだ。

スナップショット採取後のディスクへの書き込みは、新たに作られた差分ディスクイメージに書き込まれる。読み込み時はまず差分ディスクイメージを読み、そこになければ親のディスクイメージを参照する。

なお、差分ディスクイメージはログではない。仮想マシン上のアプリケーションが、同じディスクブロックに2回書き込めば、最後の1回だけが差分ディスクに残り、先の1回は上書きされて消えてしまう。つまり、最悪のパターンを考えると親ディスクイメージと同じサイズの差分ディスク領域が作成される。これは頭から尻尾まで何らかのデータで上書きされた場合だ。

経験則では差分ディスクイメージは元ディスクイメージの2割〜3割程度だけが書き換えられる。40GBのディスク領域をもつ仮想マシンが1回スナップショットを取るたびに、8GBぐらいは消費されると考えた方がいい。

通常のスナップショットは同じ仮想マシンの仮想ディスクに対する差分になる。なので同じフォルダの中に親も差分もまとめて入れられている。

別のフォルダの親ディスクイメージ対する差分、がつくれれば、ある仮想マシンの差分だけのディスクイメージを持つ仮想マシンが作れる。これがリンククローンだ。

● VMDK

VMware における仮想ディスクイメージは VMDK と呼ばれる。

Virtual Machine Disk の略で、拡張子も .vmdk である。

しかし、vmdk の拡張子を持つファイルは単一の形態でもなければ、単一のファイルであるとも限らない。

VMDKの定義は公開されている、URLは以下の通り。

http://www.vmware.com/support/developer/vddk/vmdk_50_technote.pdf

歴史的な事情もあり、VMDKの内部形式は多様にある。が、とりあえずデータセンター製品(ESX, ESXi など)で使われている形式を忘れて VMware Fusion などホスト型製品で使われている形式だけを見ると、以下の違いで4種類+αに分けられる。

• 2GB 単位で分割するか (single or split)
• あらかじめ容量分の領域を確保するか (growable or preallocated)

例えば、1ディスクイメージで必要に応じて容量が増大する形式は single growable virtual disk であり、2GBごとに区切られたディスクイメージで最初から指定容量を確保したものは preallocated virtual disk split in 2GB files となる訳だ。

これは、VMware Fusion のディスクイメージのチェックボックスに表現されている。

この、「事前のディスク領域を割り当てる」「2GB ファイルに分割」の2つのチェックがそれぞれの選択を示す。なお、デフォルトでは「事前のディスク領域を割り当てる」のチェックはオフ、「2GB ファイルに分割」のチェックはオン、growable virtual disk split in 2GB となっている訳だ。

(+αの形式については、また別に機会に説明したい。)

では、このデフォルトの場合で VMDK の中身を簡単に説明したい。

growable virtual disk split in 2GB  のVMDKを作成すると、<ディスク名>.vmdk のファイルと複数の <ディスク名>-s<番号>.vmdk のファイルができあがる。

このうち、<ディスク名>.vmdk は実はテキストファイルで読み書きが可能だ。

少々大きいが引用してみる。

# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=13b99327
parentCID=ffffffff
isNativeSnapshot="no"
createType="twoGbMaxExtentSparse"
# Extent description
RW 4192256 SPARSE "osx-s001.vmdk"
RW 4192256 SPARSE "osx-s002.vmdk"
RW 4192256 SPARSE "osx-s003.vmdk"
RW 4192256 SPARSE "osx-s004.vmdk"
RW 4192256 SPARSE "osx-s005.vmdk"
RW 4192256 SPARSE "osx-s006.vmdk"
RW 4192256 SPARSE "osx-s007.vmdk"
RW 4192256 SPARSE "osx-s008.vmdk"
RW 4192256 SPARSE "osx-s009.vmdk"
RW 4192256 SPARSE "osx-s010.vmdk"
RW 4192256 SPARSE "osx-s011.vmdk"
RW 4192256 SPARSE "osx-s012.vmdk"
RW 4192256 SPARSE "osx-s013.vmdk"
RW 4192256 SPARSE "osx-s014.vmdk"
RW 4192256 SPARSE "osx-s015.vmdk"
RW 4192256 SPARSE "osx-s016.vmdk"
RW 4192256 SPARSE "osx-s017.vmdk"
RW 4192256 SPARSE "osx-s018.vmdk"
RW 4192256 SPARSE "osx-s019.vmdk"
RW 4192256 SPARSE "osx-s020.vmdk"
RW 40960 SPARSE "osx-s021.vmdk"
# The Disk Data Base
#DDB
ddb.adapterType = "lsilogic"
ddb.geometry.sectors = "63"
ddb.geometry.heads = "255"
ddb.geometry.cylinders = "5221"
ddb.uuid = "60 00 C2 98 9f a9 e6 26-65 9d 58 77 e0 5b 46 f6"
ddb.longContentID = "f2f9ab1f6c644c8cb517ee3113b99327"
ddb.toolsVersion = "8322"
ddb.virtualHWVersion = "7"
ddb.deletable = "true"

バージョンはこの設定ファイルの記述形式 encoding は文字コードを示している。CID は content ID の略で、このVMDKを示す 32bit の番号で、VMDKの作成時に乱数で決められる。parentCID は、このVMDKの親ディスクイメージとなる VMDKの CID になる。これは親を持たないVMDKのため ffffffff が記載されている。createType は先の 2GB で分けるか分けないか容量可変か固定サイズかをしめす識別子だ。

# から始まる行はコメントで、そこから下の RW で始まる一連の領域は2GBの差分ディスクの名前とどこからどこまでを担当しているかを示す。DDB は Disk DataBase の略でこのディスクイメージの諸元情報が記載されている。HDDとしてのセクタ、ヘッダ、シリンダの数や SCSIか IDEか、SCSIの場合は SCSIインターフェイスが BusLogic のSCSIカードのエミュレーションか LSI Logic のSCSIカードのエミュレーションかを示している。

面白いのは ddb.toolsVersion だ。これは、実は VMware Tools がそのディスク上のOSにインストールされているか、されているならその内部バージョンが記されている。VMware Tools が古いとか、入っていないとかは実はここで識別されているのだ。

閑話休題、parentCID で親ディスクイメージとの関連が取られていることが分かるが、では親ディスクイメージはどこにあるか。CIDに対応するファイルのパスを一々仮想化ソフトウェア側が覚えているかというとそうではない。

スナップショットを取ってみると分かる。

VMware Fusion でスナップショットをとると「<ディスク名>-<6桁の番号>.vmdk 」と「<ディスク名>-<6桁の番号>-s<番号>.vmdk 」という一連のファイルができあがってるはずだ。この <ディスク名>-<6桁の番号>.vmdk 側はやはりテキストファイルで VMDK の設定情報が書かれている。こちらをみると、こんな記述があるはずだ

CID=5daf4124
parentCID=c07bdeb7
isNativeSnapshot="no"
createType="twoGbMaxExtentSparse"
parentFileNameHint="OPENSTEP-000003.vmdk"

この parentFileNameHint が親ディスクイメージの名前と場所を記録している、という訳だ。

なお、1ディスクイメージにまとめた場合は、VMDK ファイルの先頭にこのテキストと同等の情報が記載された後、実際のディスクの内容となるバイナリデータが連結された形となる。読んで読めなくはないが、以下に述べるような編集操作が難しいのが難点。

分割ファイルが 2GB ずつなのは、そもそもこの形式 FATファイルシステムで作られたため。Windows 95 までで主に使われてきた FAT16 形式では、ファイルサイズの最大は 2GB であったため、2GB ずつ分解するのが適切だったのだ。
(FAT32 の導入は Windows98 より正確には Windows95 OSR2から )

VMware Fusion でこの2GBごと分割形式がデフォルトなのは、TimeMachine との相性からだと思われる。TimeMachine はファイル単位で更新されたファイルをバックアップするため、1ファイル形式だと VMDKの中の1バイトがかわっただけでも全てのディスクイメージがバックアップされてしまう。2GB ごとなら変更されたブロックを含むエクステントファイルだけがバックアップされるので、少しは効率が良くなる。

● リンククローンをでっち上げる

さて、説明は長いが、やることは実はそう難しくない(笑)

まず、仮想マシンを作成し OSをインストール、必要なところまでシステムを構成する。

なおこのとき 「2GB ファイルに分割」は入れておくことをお勧めする。理由は述べたとおり、後で VMDK に細工するときに single 形式は面倒だからだ。

十分できあがったところで仮想マシンをシャットダウンする。

仮想マシンが止まったところで、Finder で .vmwarevm フォルダの下をみて、どういう名前で VMDK が作られているか確認しておこう。

確認できたらスナップショットを取る。

スナップショットは恐らく、「<ディスク名>-<6桁の番号>.vmdk 」と「<ディスク名>-<6桁の番号>-s<番号>.vmdk 」という一連のファイルができあがってるはずだ。

安全のためにここで仮想マシンを VMware Fusion の仮想マシンのリストから削除しておいた方がいい。なお、削除する際は「ファイルの保持」を選択、仮想マシンの構成ファイルが削除されないように気をつける。

次にリンク先の仮想マシンを作成する。名前は適当でいい。

そして仮想マシンの設定からハートディスクを選択、詳細オプションを広げて「ハードディスクの削除」を行う。

これで稼働ハードディスクのない仮想マシンができあがる。ここでまだ「設定」パネルは閉じない。

さて、ターミナルを起動、ウィンドウを1つ開く。コピー元の仮想マシンのフォルダにあるスナップショットでできた一連の VMDK ファイルを、リンク先の仮想マシンの .vmwarevm  フォルダに全部コピーする。

そして、適当なエディタで 「<ディスク名>-<6桁の番号>-s<番号>.vmdk 」ファイルを開き、

parentFileNameHint="VMname.vmdk"

を

parentFileNameHint="../VMname/VMname.vmdk"

という感じでパスに書き換える。相対パスでも絶対パスでもいいのだが、Fusion の場合 ホームの下の書類(Documents)の下の「仮想マシン」(VirtualMachine.localized) フォルダにまとめて置いておくことが多いので、例のように相対パスの方が楽、だろう。

そして仮想マシンの設定の右上にある「デバイスを追加...」ボタンを押し、「既存のハードディスク」を選択、上記でコピーした VMDK を選択する。

これでリンククローン(もどき)は完了。あとは仮想マシンの電源を入れれば起動する、はずだ。

なお、この方式で Windows のリンククローンを作った場合、SIDは全て同一になる。

SIDが同じでも普通は困らない。ActiveDirectory 環境下でも困らないことはマイクロソフト自身が明言している。

しかし、一部のアプリケーションなどで SID が一意であることを前提に作られたものがある。そういった場合は SIDが重複していると問題が起こるかも知れない。
(実は、VMware View の ViewManager や vCenterServer などでこの問題が発生する。)

問題が起こった場合は、リンククローンされた仮想マシンで sysprep を実行、SIDを再生成させればいい。