Windows 11 インストールのハードルが高い
Windows 11 の利用ができるようになって、多くの人が Windows 11 へのアップグレードをし始めています。その中、ハードウエア要件に引っかかってアップグレードができなかったりする人も続出。企業が導入している低スペックの PC に至っては、Windows 11 にアップグレードできない低スペックが大量に社内にあるという状態に陥っています。この問題、セキュリティ対策が強化されたことによるのが一番大きな原因なのですが、これについては VMware の製品の仮想化環境でも同じような問題が出てきています。例えば、
- VMware Workstation 16 Pro では、TPM やディスクの暗号化を使わない Windows 10 までの仮想マシン構成では Windows 11 がインストールできない。
- VMware Workstation 16 Player では、そもそもディスクの暗号化や TPM の設定ができないので Windows 11 を扱うことができない。
- VMware vSphere Hypervisor だけでは vTPM が使えないので、Windows 11 の仮想マシンをインストールできない。
- vSphere 6.5 までの環境では vTPM 無いので Windows 11 は使えない。
などがあります。これらの制限ですが、最後の vSphere 6.5 以前は問題外として、それ以外の環境では本当に Windows 11 が動かせないのかというとそういうことではなくて、仮想マシン側に設定をすることでインストールと実行ができることは前回のブログの記事で説明しました。
ただ、この場合仮想マシンの暗号化が必須となっていてその場合の仮想マシンは OVF への出力ができなくなります。かわりに TAR へのエクスポートがメニューに出るようになるのですがOVF形式じゃないと移行できない環境も多く、どうにかする方法はないかと探していました。
Windows 11 のディスクを暗号化しないで使う
この部分、実は Software TPM を使うことでクリアすることができることがわかりました。といっても前提条件があり、VMware Workstation 16 Pro の 16.2.0 以降を使わないとできません。
これについてこんな記事を書いている人がいました。
できるのであればさっそく実行ということで試してみます。
Software TPMを有効にして仮想マシンを作成
まずいつもの通りに仮想マシンを作成していきます。ここで仮想マシンのハードウエア互換性の選択で「Workstation Beta」を選ぶ必要があります。「Workstation 16.x」にしてしまうと仮想ハードウエアバージョンが 18 になってしまうのでこの機能が使えません。「ESXi 7.0」を選択すると仮想ハードウエアバージョンがもっと古い 17 になってしまいますので注意が必要です。
ゲスト OS の選択は Windows 11 がありませんので、そのまま Windows 10 x64 を選びます。これを選択すると「guestOS = "windows9-64"」が仮想マシンに設定されます。
VMware の仮想マシンの場合、Microsoft のバージョンと違うので、「guestOS = "windows9-64"」になっていても気にしてはいけません。(笑)
ファームウエアは Windows 11 で必要な UEFI を選択します。ここで vTPM では必須だった「セキュアブート」はチェックを入れません。
仮想マシンの作成が完了後はすぐに起動しません。VMware Workstation 16.2.0 Pro を終了し、作成した仮想マシンの .vmx ファイルを編集し、以下の 1行を追記します。
managedvm.autoAddVTPM = "software"
追記が終わったら VMware Workstation 16.2.0 Pro を起動します。自動的に Trasted Platform Module が追加されています。
ここで仮想マシンを起動します。Windows 11 のインストーラーが起動して、Windows 11 のインストールが開始します。
問題なく Windows 11 のインストールが完了しました。仮想マシンのディスクも暗号化されていないので、すべてのファイルを見ることができます。
ただし、残念ながらこの記事の最初のほうに書いた、仮想マシンの OVF 出力はできません。そして以前のバージョンにはあった TAR へのエクスポートもメニューから消えています。つまり現状の Windows 11 仮想マシンを他の環境に仮想マシンを移すには、仮想マシンのフォルダごとそのままコピーしていくという方法しかないということのようです。これは OVF エクスポートができるようになったかと調べ始めた私にとっては、ある意味衝撃的な結果になりました。
Windows 10 からのアップグレードは?
もちろん、上に書いた新規インストールと同様に .vmx ファイルに「managedvm.autoAddVTPM = "software"」を追記するだけでできるようになります。これで TPM 関連で悩まされることもなくなりました。
Software TPM または vTPM で追加される .vmx の項目は?
この Software TPM または vTPM で追加される .vmx の項目は以下の通りになります。
- managedvm.autoAddVTPM
- managedVM.ID
- encryption.encryptedKey
- vtpm.ekCSR
- vtpm.ekCRT
- vtpm.present
- encryption.keySafe
- encryption.data
最初の managedvm.autoAddVTPM 以外は、適切な値が設定されて自動生成されます。
VMware Workstation 16.2.0 Player での動作は?
VMware Workstation 16.2.0 Pro で作成した仮想マシンを、そのまま VMware Workstation 16.2.0 Player で開いてみます。起動したときは仮想マシンに赤い鍵マークがついています。
でも、仮想マシンをクリックすることで鍵が解除されて起動ができるようになります。
そして、問題なく Windows 11 が起動します。
この機能って正式なの?
VMware Workstation 16.2.0 のリリースノートに記載はありません。
なので先ほどの仮想マシンを作成するところに出てきた「Workstation Beta」のように、公開前の機能として 16.2.0 に実装された試験的な機能のようです。そのため、今はテスト用に使う程度でとどめて、本格的に使うのは次以降のリリースでリリースノートに記載されてからにするのが良いでしょう。それでも、よくいろいろなところのブログに書かれているようなレジストリをいじったりすることはしないで、そのまま物理環境と同じように Windows 11 をインストールできるようになるのは便利です。
ちなみに、この Software TPM の機能追加で仮想マシンバージョンがどうなったかというと、
virtualHW.version = "19"
です。vSphere 7 Update 3 は仮想ハードウエアバージョンは 19 のままですので、vSphere 7 Update 2 の時点で実装されている機能のようです。それを VMware Workstation 16.2.0 Pro で使えるようにしたということかもしれません。
新しい OS が出ると追従しなければならないというハイパーバイザー層の宿命ではあると思うのですが、このあたりもっとシンプルになってくれないかなぁと思ったりしました。