Windows7 でシステムパーティションを削除する

32bit のWindows7 を通常の手順でインストールすると、100MBのパーティションが起動ディスクの先頭に用意される。

このパーティションはシステムパーティションと呼ばれており、マイクロソフトのページにその概要が記載されている。

UNIX的な感覚からするとちょっと違和感を感じるかも知れないが、起動時にのみ参照されるこのパーティションが「システムパーティション」であり、いわゆる C:ドライブは「ブートパーティション」と呼ばれている。

このパーティションにはブートローダやその設定などが格納されており、システム保護の観点からドライブ名もつけられず、GUIからは削除できないようになっている。また、BitLocker を使う際にはそのためのモジュールもここに格納される。BitLocker を使う場合、このシステムパーティションの存在は必須と言える。

さて、仮想環境上ではTPMが使えない兼ね合いから BitLocker を使うのは現実的ではない。
(使えなくはない。たとえばこのページを参照。)
Fusion や Workstation で1台2台をセットアップするなら別にどうでもいいが、Horizon View などで何十台何百台と Windows が実行される場合、100MBとはいえ決して馬鹿にできない浪費になるだろう。

では、このシステムパーティションなしのインストールができるのか?というと、これは可能だ。これもまた、マイクロソフトのページに記載されている。
手順としては以下の通り

1. Windows7 のメディアで起動􏰀
2. 最初の画面で SHIFT-F10 を押し、コマンドプロンプトを表示􏰀
3. diskpart コマンドを起動、1パーティションでパーティションテーブルを作成
4. コマンドラインを終了􏰀
5. インストール時に作成したパーティションを指定􏰀

Windows7 のインストーラの画面で SHIFT-F10 を押すと、下図のようにコマンドプロンプトが表示される。

ここで、diskpart コマンドを実行し、先にパーティションを作ってしまうのだ。

その後、exit コマンドを実行し、インストーラに戻り、インストールを継続する。
通常の新規ディスクの場合、インストール先の選択が「ディスク0 未割り当て領域」となっているのだが、すでにパーティションが作成されているのでその代わりに「ディスク0 パーティション1」が選択しに現れる。

あとはインストールを続行する。
結果、下図のように全体で1ドライブとなる。

ここで作成されたシステムパーティションなしの 32bit Windows7 をHorizon View の ViewComposer でリンククローンで展開したが、全く問題なく利用できている。

シンディスクの場合、システムパーティションのほとんどは未使用のため実ディスク領域は割り当てられない、このため、別にあってもなくてもディスク消費に大差はない。しかしシックディスクでフルクローンの場合は、これで1仮想マシンごと100MBが回収できる。決して馬鹿にできない差異になるだろう。

● 64bit Windows7 ではどうなるか?

なお、64bit Windows7 の場合、以下のようになる。

NTFSのシステムパーティションではなく、FAT32の「UEFIシステムパーティション(ESP: EFI System Pertition)」になる。
これは UEFI で定義された領域で、(U)EFI を使用するコンピュータでは必ず作成される。
その代わりに Windowsによるシステムパーティションは作成されない。UEFI システムパーティションがその代わりとなり、BitLocker のモジュールなどが導入されるためだ。


UEFI 周りについては、また別途説明する。

pvSCSI で性能が上がるか?

どこぞの話で突っ込みを入れたときに調べた事を書いておく。

pvSCSI とは vSphere のディスクIOに対する準仮想化ドライバの事で、vSphere がサポートする一部のOSにて利用できる。どのOSで利用できるかは KB 1010398 を参照してほしい。

さて、そこの話、端的に言えば「pvSCSI も LSI Logic もIOPS変わんない」と、暗に pvSCSI を使えないと示唆するようなことだった。

そう、よく勘違いされるが pvSCSI は (vmxnet3 も) ただ「IO性能を上げるもの」ではない。これは pvSCSI の出始めに発表された、このホワイトペーパーを見ればわかる。

英文を読まずとも表だけ見れば LSI Logic と pvSCSI で性能差がほとんどない事に気がつく。
一方、差が出ているのは「CPIO」と呼ばれる項目だ。ドキュメント中に説明があるがこれは「a unit of cycles per I/O」、すなわちそのIOの間にどれだけ CPUが消費されたか、になる。

考えてみれば当たり前の話だ。pvSCSI でも LSI Logic でも、仮想環境上のメモリに存在するデータを、VMkernel に渡して実際のストレージIOにする部分に大きな差はない。異なるのはそのためにLSI Logic という実際のハードウェアの手順をエミュレートするのか、そういう細かいところを省くか、だけになる。LSI Logic のデバイスドライバをそのまま使えるようにするという手間が省ける分、CPUサイクルが削減され、CPU負荷が下がる、というのが pvSCSI の本質だ。

結果として IOしている間のCPU負荷が下がる。

これは IOPS をはかるベンチマークではあまり意味をなさないが、CPUがそれだけあいているという事はアプリケーションがさらに演算を行ったり、pvSCSI以外のデバイスに対するIOを行うだけの余地が増える。ワークロードのスループット全体を見れば、向上が行われる、という次第だ。

ベンチマークの結果値だけを見ているとこうした事はわからない。
数字の多寡を気にするのではなく、システム全体を俯瞰し、それがどういう位置づけになるかを忘れない事だ。

アップグレードしたOSはカスタマイズできない

所用があり WindowsServer 2012 R2 をいくつかテンプレートから展開していたのだが、カスタマイズ仕様で指定した設定がなされていないことに気がついた。

該当のマシンにログオンし、 sysprep のログを見たところ、以下のメッセージが表示されていた。なお、sysprep のログについてはこちらのKBに記載がある。

[0x0f0036] SYSPRP spopk.dll:: Sysprep will not run on an upgraded OS. You can only run Sysprep on a custom (clean) install version of Windows.

...ああ、なるほど。このテンプレート、そもそもは WindowsServer 2012 で、R2 を後から適用したため「アップグレード」となってしまったわけだ。2012 を展開する用がなかったのでそのことをすっかり失念していた。

対処としては二つある。一つは、素直にOSを新規インストールし直すことだ。

今回はこちらを採用した。理由は簡単で、Windows.old が残っており、削除がやっかいで、そのうえ肥大した VMDK の領域回収を考えると、時間はかかるがほったらかしておけば終わる入れ直しの方が楽だったからだ。

もう一つは、アップグレードであるというフラグをつぶしてしまうことだ。

詳細はこちらのページなどを参照してほしい。

レジストリを操作するだけなので時間は短くて済む。

しかし、そもそもなぜアップグレードしたOSだと sysprep を拒否するようになってるかがわからないので、後々で面倒を抱えたくないというのもあり、この手を取らなかった。

Horizon View Connection Server で「サービスが正常に機能していません」が表示される。

Horizon View の Connection Server を複数立てたとき、ダッシュボードの接続サーバに「サービスが正常に機能していません」というメッセージが表示されることがある。
なお、英文だと「The service is not working properly. 」の模様。

「サービスが正常に機能していません」のエラーメッセージ
そう言われましても...、って気分になる

KBを探してみても vCenterServer にこのメッセージが出る場合の記載ぐらいで、ログもそれらしいエラーがなく困っていたが、ようやく原因を特定できた。

二つの ConnectionServer で時刻同期がうまくいっておらず、時間が1分程度ないしそれ以上ずれていると、このメッセージが表示される。

一方が ServerCore で構成していたのだが、どっかのタイミングで Windows Time が起動されてなかったらしく、時々ずれがこの時間を超えて、なぜか赤くなる、を繰り返していたのだ。

わかってしまえば対処は簡単で、時刻同期がちゃんと実行されるようにするだけだ。

今回実施したのは、以下の通り

w32tm register

net start "Windows Time"

w32tm /config /update /syncfromflags:DOMHIER

w32tm /resync /rediscover

最初の行でサービスとして登録、二行目で起動する。
起動しないとそれ以降のコマンドが打てないので、とりあえず動かしておくのだ。

3行目でドメインコントローラから時刻をとるように設定を強制、4行目で同期を強制している。( どうも /redisover をつけないと同期先を古い設定のまま見に行くことがあるので注意。)

1,2 分程度のずれなのでこれで済んだ。
大きくずれている場合の同期方法については適当に調べてほしい。

なお、同期状況の確認は

w32tm /monitor

を実行するのが手っ取り早く、時間は

echo %time%

としたほうが、time コマンドより楽だ。
time コマンドだと、そのまま実行すると時刻の設定をしようとし、/T をつけると秒以下を表示してくれないため。

いろいろ探しても該当事例を見つけられなかったので、念のために記録しておく。

ESXi に使うべき フラッシュメディアのサイズ

ESXi 5.5 のインストールには最低 1GB のストレージ容量が必要で、scratch を配置する場合は 5.2GB 以上、となる。

これは ESXi のマニュアルに記載されている。

さて、ではサイズが異なると ESXi のインストレーションはどう変わっていくのだろうか?
VMware Fusion 上に ESXi をインストールし、その時の VMDK のサイズを変えて試してみた。

● 1,2,4GB の場合

これら 5.2 GB 未満のメディアの場合は、まったく同じサイズで5つのパーティションが作成される。

ID	開始セクタ	終了セクタ	サイズ	形式(FS)	用途
1	64	8191	4MiB	systemPartition (FAT32)	EFI
5	8224	520191	250MiB	linuxNative (FAT32)	/boot
6	520224	1032191	250MiB	linuxNative (FAT32)	/altboot
7	1032224	1257471	110MiB	vmkDiagnostic	Coredump
8	1257504	1843199	286MiB	linuxNative (FAT32)	/store

IDはパーティション番号を意味する。
1は要するに EFI システムパーティションで、FAT である。
5 が実際の ESXi のシステムが入ってる bootbank で、6 は altbootbank である。
7 は診断パーティションとも呼ばれているもので、要するにコアダンプ用だ。
8 は visorfs の /store にマウントされるパーティションで、VMware Tools のインストール用 CDイメージなどが格納されている。

linuxNative とGUIDで記載されているパーティションが何故 FAT32かというと、GUIDパーティションテーブルでは、Windows のパーティションと Linux のパーティションに同じGUID が割り当てられており、区別できないからだ。

全体で1GiB も使ってないが、これは 1,2,4 GB どの場合も同じだった。
つまり、5.2GB 未満では、どの容量のメディアを使おうと、先頭 0.9 GiB程度しか使われない訳だ。

● 8GB の場合

さて、8GBのメディアにインストールすると、こうなる。

ID	開始セクタ	終了セクタ	サイズ	形式(FS)	用途
1	64	8191	4MiB	systemPartition (FAT32)	EFI
5	8224	520191	250MiB	linuxNative (FAT32)	/boot
6	520224	1032191	250MiB	linuxNative (FAT32)	/altboot
7	1032224	1257471	110MiB	vmkDiagnostic	Coredump
8	1257504	1843199	286MiB	linuxNative (FAT32)	/store
9	1843200	7086079	2.5GiB	vmkDiagnostic	拡張Coredump
2	7086080	15472639	4GiB	linuxNative (FAT32)	/scratch
3	15472640	16777182	約0.6GiB (残り全部)	vmfs	datastore01

前半のパーティションはそのままで、あらたに9, 2, 3 の三つのパーティションが追加された。

ID:9 はESXi 5.5 で新たに用意されたコアダンプパーティションだ。従来の110MiBのダンプでは全てを取りきれないため、2.5GBもの容量が確保されている。
ID:2 がいわゆる Scratch パーティションで、ログなど様々な情報が格納される。
このパーティションが存在しないと、ESXi が警告を発するのはご存じの通りだ。

ID:3 は VMFS であり、datastore1 となる部分だ。ここは、ディスクの残り領域がすべて割り当てられる。8GBのメディアの場合、600MiB程度が VMFSとして確保される。

ここであれ?っと疑問に思われた方は正しい。そう、VMFS は 600MiB なんてサイズでは構成できない。vSphereClient から datastore1 を削除した後、再作成は失敗する。

この制限以下の小さな VMFS は、インストール時にのみ現れる特別なものらしい。

閑話休題、scratch が必要な場合は 5.2GB 以上のメディアを使うようドキュメントにはあるが、0.9GiB + 2.5GiB(拡張ダンプ) + 4GiB(scratch) では、7.4GB 程度が必要に見える。

そこで、6GB の場合を試してみた。

● 6GB の場合

6GB では、パーティションテーブルはこうなった

ID	開始セクタ	終了セクタ	サイズ	形式(FS)	用途
1	64	8191	4MiB	systemPartition (FAT32)	EFI
5	8224	520191	250MiB	linuxNative (FAT32)	/boot
6	520224	1032191	250MiB	linuxNative (FAT32)	/altboot
7	1032224	1257471	110MiB	vmkDiagnostic	Coredump
8	1257504	1843199	286MiB	linuxNative (FAT32)	/store
2	1843200	10229759	4GiB (FAT32)	linuxNative (FAT32)	/scratch
3	10229760	12582878	約1.1GiB (残り全部)	vmfs	datastore01

ID9 の拡張ダンプパーティションが消えている。その分、余りが増えるため VMFS 領域が拡大しているのが分かる。VMFS領域を抜くと、約 4.9 GiB になる。つまりは、SI単位系で言うところの約 5.2GB である。厳密に言うなら、scratch の最終セクタが 10229759 であり、1セクタが 512バイトのため、5237636608 バイトが必要である。これを1024 で割っていくと 4.87GB となり、1000 で割ると 5.2GB となる訳だ。

そして余った分が VMFS の領域になる。
もし、余りが 2.5GiB 以上あれば、拡張ダンプパーティションが作成され、そこからの残りで VMFS が作成される。


共有ディスクに、複数 ESXi のログまとめて管理したり、syslog で飛ばして LogInsight を使う、とかでも無い限り、scratch はあるに越したことない。

このため、おとなしく 5.2GB以上、実質的には 8GB のフラッシュメディアを用意しておくのが正解、となる。

なお、こちらのKBには面白いことが書いてある。

リテール購入品の 16 GB 以上の USB フラッシュ ドライブを使用すると、「予備の」フラッシュ セルで起動メディアを長持ちさせることができるのでお勧めしますが、コアダンプの拡張パーティションの保持には 4 GB 以上の高品質ドライブがあれば十分です。

16GB にしておくことで、ウェアレベリングが効いてより長持ちすると言うことだ。
後半の文章が謎だが、8GB の誤植ではないかと思われる。

vExpert 2015 受賞しました

今年も vExpert 2015 を受賞できました。ありがとうございます。

http://blogs.vmware.com/vmtn/2015/02/vexpert-2014-announcement-2.html

[ヨタ] Fusion はいつ買い時か?

Fusion のリリースノートを順に追いかけたり、Wikipedia のエントリなどを見ると確認できるが、VMware Fusion のメジャーリリースは以下となっている。

• 1.0  2007/8/6
• 2.0  2008/9/12
• 3.0  2009/10/27
• 4.0  2011/9/14
• 5.0  2012/8/23
• 6.0  2013/9/19

見事に秋口にまとまっているのが分かる。大まかに言って理由は二つある。

一つは、OS X のリリースだ。WWDCの影響もあり、こちらは大まかに初夏から秋にかけてのリリースとなる。

• 10.6 Snow Leopard 2009/8/28
• 10.7 Lion,   2011/7/20
• 10.8 Mountain Lion,   2012/7/25
• 10.9 Mavericks,  2013/10/22
• 10.10 Yosemite,  2014/秋?

どちらの製品も 2010年が欠如していることから見えてくるように、OS X のリリースに合わせて、Fusion の新バージョンが出てきている、といっても過言ではない。

もう一つは VMworld SanFrancisco の存在だ。例年8月末に行われるこのイベントに合わせて新バージョンが用意され、程なくリリースされている。

開発者向けの OS X 10.10 Yosemite のプレビュー版は6月のWWDCにてアナウンスされ、以後 OSカーネルからの大幅な変更で阿鼻叫喚の修羅場が静かに巻き起こっているようだが、それに加えて、10.0 以来とも思われる一般ユーザ向けのパブリックベータ版も出てきている。

Mac開発者だった当時はドッグフードをかっ喰らう生活、そう不安定な開発者版でメールなどの日常の処理からアプリケーションの開発までやってたので、「アップルが開発者向けに出しているものは気軽に常用できるものでない、苦労を買うだけだからやめておけ」と思うのだが、しかも Yosemite は聞いた限りではかなり厄介な事態になってる、-- たとえばこの blog によるとデバイスドライバ(KEXT)にAppleの証明書が必要になり、署名のないドライバーはロードできなくなっている -- ので、どうせ後数ヶ月の話なのだから、リリースまで待った方が賢明である。

だが、OS X はアクティベーションのような強いライセンス認証を持たない。(それどころかインストールに際してライセンスキーすら確認されない)。このため、開発者向けプレビュー版の漏洩とアンダーグラウンドでの流通は毎度のことである。どうせ突っ込みたがる人間がいるなら、いっそ分かる形で出した方がマシ、っていうことなのだろう。

VMware Fusion についてもβ版が出てきている。

仮想ハードウェアバージョン11 のサポートや、Library ウィンドウからリモートの仮想マシンを操作できる、などの機能がアナウンスされている。特に ESXi の仮想マシンをリモートコントロール出来るのは気になる機能だ。これは VMware Workstation には既にあった機能だが、「クリエイティブ向け」とされた Mac では外されていたものだ。

いわゆる IT Pro 系のSEや、OSS系ではない普通の開発者にも Mac は浸透してきている。Fusion Professional ではそうしたインフラ系エンジニアにとって便利な機能が着実に整備されてきている。

さて、現在βの 次期 Fusion はいつリリースだろうか? 多分 VMworld SF にて詳細が語られ、その後、おそらく Yosemite のリリースの前後にリリースされるのだろう。

そういう意味では、特に個人ユーザはもう少し、秋口まで待ってみるのもいいかもしれない。新しいバージョンがでてから購入するも良し、リリースぎりぎりになって現行バージョンを買うも良い。

なお、現在の VMware Fusion 6.0.4 は Yosemite との互換性があるらしい。今の Fusion を買っても、Yosemite で即動かなくなることはないだろう。

確証は出来ないが、例年、新バージョンがでれば直近に旧バージョンを買ったユーザ向けに無償アップグレードがでたりする。現行バージョンを使い尽くしてから、パッチが落ち着いてから新しいバージョンにアップグレードしても遅くはないわけだ。

また、βテストユーザ向けにはディスカウントコードがでることもある。とりあえずβテストに申し込むのも手だ。

なお、10ライセンス以上をまとめて購入できる企業等の場合、vSphere などにもある Basic/Production の SnS (保守サービス)を購入することが出来る。SnS は「Support and Subscription」の略で、有効期間中に問い合わせなどサポートを受けれるのだが、そこにはフリーアップグレード/ダウングレード権が含まれている。Fusion 6 をまとめ買いして、SnS をつけておき、次のバージョンがでたらSnSの権利下で無償アップグレードをする、という感じだ。