ラベル Windows7 の投稿を表示しています。 すべての投稿を表示
ラベル Windows7 の投稿を表示しています。 すべての投稿を表示

2015/04/10

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 周りについては、また別途説明する。


2012/02/15

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"

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

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 から入手可能


それぞれのページの上の方に「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 アドレスを設定する際のエラー メッセージ


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