【Windows 10開発動向】次期Windows 10ではコマンドラインで「WSL 2」のインストールが可能にWindows 10 The Latest(2/2 ページ)

» 2021年02月03日 05時00分 公開
[塩田紳二]
前のページへ 1|2       

仮想ハードディスクをマウントする場合の手順

 仮想ハードディスクファイルをマウントする場合には、先にWin32側でVHDXファイルをdiskpartコマンドなどでマウントしておく。後の操作は同じである。なお、WSL 2のディストリビューションの実行イメージは、ext4形式のVHDXファイルになっており、この機能を使うことで、起動しているWSL 2のディストリビューションから別のディストリビューションの起動ドライブを編集可能だ。

 wsl.exeの「--mount」オプションで使う「\\.\PHYSICALDRIVE1」といったDeviceIDは、Windows 10のオブジェクトシステムの中では仮の名称(\Device\Harddisk0\DR1へのショートカット)であり、通常のWindows 10のGUIではあまり表示されない形式だ。末尾の数字は、例えば[管理者ツール]の[コンピューターの管理]にある[記憶域]−[ディスクの管理]で下段に表示されるディスクの番号やdiskpartコマンドで表示されるDiskの番号と一致する。前述のように数字だけならPowerShellのget-diskコマンドでも表示可能だ。

 この機能が正式にリリースされるときには、もう少し分かりやすい表記になる、あるいはwsl.exeに対象ドライブを選択するための情報表示機能などが入るのではないかと想像する。

共有サーバ名によるWSL 2側のファイルシステムへのアクセス方法が変更

 また、プレビュー版では、Win32からWSL 2側のファイルシステムをアクセスする共有サーバ名として「\\wsl\」が利用できるようになっている。この機能は、既に導入されているが、共有サーバ名は「\\wsl$\」であり「$」を末尾につける必要があった。プレビュー版では、どちらのプレフィックスでもアクセスが可能だ。

Win32側からWSL2のファイルシステムには「\\wsl\」でアクセス Win32側からWSL2のファイルシステムには「\\wsl\」でアクセス
Win32側からWSL2のファイルシステムにアクセスするとき、現在は「\\wsl$\」を使うが、「\\wsl\」を使うように変更された。ただし、従来のUNCパスでもアクセスは可能だ。

WSLディストリビューション起動時のコマンド実行

 WSLでは、従来のLinuxが持っている「デーモン」起動のメカニズムが「オフ」にされている。通常のLinuxでは起動時に多数のデーモンを起動し、これらは、Linuxが終了するまで動作し続ける。

 しかし、WSLでは、ブートのプロセスからして通常のLinuxとは違うこと、WSLディストリビューションが動作するのは、ユーザーがログインしている間だけとなっているため、デーモン起動のメカニズムであるSystem V init(「inetd」などと呼ばれることもある)、systemdなどは全て外されている。もともと、WSLでは、HTTPサーバのようなサーバ(あるいはサービス)を動作させるのではなく、クライアントとしてLinuxを利用することに特化しているからだ。

 だが、WSLディストリビューションの起動時に何らかの処理を行わせたいという要望は根強くある。これには、ユーザーのログインスクリプトで対応するという考え方もあるが、wsl.exeからのLinuxコマンドの実行など、シェルが起動しない場合もあること、root権限が必要なコマンドもあることなどから、ログインスクリプトでの対応には限界がある。

 そこでプレビュー版に導入されたのが、この起動時のコマンド実行機能だ。起動コマンドは、WSLディストリビューション側(Linux側)の「/etc/wsl.conf」で設定する。このファイルの形式は、Windowsの初期に用いられたiniファイルに似ている。「[boot]」セクションに「command=実行コマンド」という行を記述する。例えば、以下のようなものになる。これは、実行中のユーザー名を取得するwhoamiコマンドを実行してファイルに書き出すものだ。

[boot]
command=echo whoami=$(whoami) >> /tmp/bootcommand.txt


起動時に実行されるコマンド
実行中のユーザー名を取得するwhoamiコマンドを実行してファイルに書き出すもの。

 WSLディストリビューションは、起動時に「command」で指定したコマンドを実行する。以下の例でも分かるように実行は、「root」で行われる。ただし、起動時には、ログインスクリプトなどの関係で、通常のユーザーの起動直後の環境とは違いがある点に注意してほしい。

起動時にコマンド実行が可能 起動時にコマンド実行が可能
WSL 2の起動時にコマンド実行が可能になった。コマンドは、「/etc/wsl.conf」に記述する。

仮想マシン支援機能のサポート

 Windows 10は、仮想マシン支援機能(Intel VTやAMD-V/SVM)の「Nested VM」に対応している(AMD製CPUにはビルド19640から対応)。この機能は、仮想マシンの中で動作するゲストOSで仮想マシン支援機能を有効にするものだ。つまり、仮想マシンの中の仮想マシン環境というわけだ。仮想マシンの中で動作するWSL 2に関しても、Nested VM対応CPUでは仮想マシン支援機能が利用できるようになる。

 その設定のため、「%userprofile%\.wslconfg」に新たに「nestedVirtualization=true/false」というオプションが追加された(「[wsl2]」セクションで指定)。ただしプレビュービルド20175からデフォルト値は、「nestedVirtualization=true」になっている。

 この設定を「有効(true)」にすると、Linuxカーネルで、仮想マシン支援機能KVM(Kernel-based Virtual Machine)が利用できるようになる。KVMが動作しているかどうかは、「/dev/kvm」デバイスが存在するのを確認すればよい。また、「/proc/cpuinfo」に「vmx」や「svm」といったフラグの有無を確認してもよい。CPUエミュレーションソフトウェアであるQEMUをインストールしておくとkvm-onコマンドも利用できる。

 WSLのnested VMの評価には、QEMUのインストールや実行する仮想マシンイメージなどが必要になる。ここではQEMUの使い方などを解説するのは本筋ではないため、手順のみ示す。評価は、Windows 10プレビュー版OSヒルド21277、Linuxカーネルバージョン5.4.72で行った。ここでは、QEMUを使い、WSLディストリビューションの中で別のLinuxディストリビューション(Fedora)を動作させてみる。FedoraディストリビューションのLinux実行イメージは事前に以下のURLからダウンロードしている。

 上記ページの「Fedora <バージョン番号> Cloud Base Images」枠にある「Cloud Base image for Openstack」にあるリンクから「Fedora-Cloud-Base-33-1.2.x86_64.qcow2」をダウンロードする(qcow2はQEMUの実行イメージファイル形式)。下記のQEMUのコマンドは、ダウンロードしたファイル名に依存しているので注意してほしい。

qemu-system-x86_64 -m 1024 -enable-kvm -display none -name myfedora -cpu host -nographic -drive file=Fedora-Cloud-Base-33-1.2.x86_64.qcow2,if=virtio


QEMU内でFedora Linuxを実行するコマンド

 このようにすることで、QEMU内で、Fedora Linuxディストリビューションが起動する。QEMUでは、GUIが動作していれば、別ウィンドウに表示を行うのだが、コマンドオプションでグラフィックス表示を止めているため、起動したコンソールにそのまま表示が出る。

WSL 2上でQEMUを使ってFedoraを実行してみた WSL 2上でQEMUを使ってFedoraを実行してみた
Nested VMに対応したプロセッサなら、WSL 2内でも仮想マシン支援機能が利用できるようになった。これにより、プロセッサエミュレーション環境のQEMUなどが動作する。

 仮想マシン支援環境が動作することで、WSL 2の利用範囲はかなり広がる。QEMUだけでも多数のCPUエミュレーション機能があり、クロス開発などに利用されることもある。こうしたLinuxによる開発環境もWSL 2上に構築できるわけだ。

GPUコンピューティングサポート

 この機能は、WSL 2内からGPUへのアクセスを可能にし、GPUを使った高速計算などを可能にするものだ。利用するには、WDDM 2.9に対応したGPUのデバイスドライバをホスト側にインストールする必要がある。ただし現時点では、Windows 10 May 2020 Update/October 2020 UpdateはWDDM 2.9に対応しておらず、「Enable TensorFlow with DirectML in WSL 2」ページにリンクがあるプレビュー版のドライバを使う必要がある。NVIDIAの他、IntelとAMDのGPUが対応している。

 この機能を評価するため、NVIDIAのGPUボードを装着したマシンでWSL 2を動作させ,CUDA-Toolkitを動作させてみた。詳しくは、NVIDIAが提供しているドキュメント「CUDA Toolkit Documentation」を参考にしてほしい。本稿では、趣旨から外れるため、Deep Learning用のコンテナのインストールなどは解説しないが、こちらのドキュメントにはその手順なども解説されている。

 WSL 2からGPUコンピューティングを利用するには、まずWin32側にプレビュー版ドライバをインストールする。ドライバは「GPU in Windows Subsystem for Linux」にある。

 次にWSLディストリビューション側にCUDA Toolkitをインストールする(「CUDA Toolkit」を参照のこと)。また,WSLディストリビューションはUbuntuもしくはDebianのみが現時点では対応している。

 次にWSL 2側でCUDA Toolkitをインストールする。ダウンロードは、「CUDA Toolkit 11.2」から行う。

 原稿執筆時点のGPUドライバは「465.21_gameready_win10-dch_64bit_international.exe」だった。CUDA Toolkitは、上記の「CUDA Toolkit 11.2」ページに手順が書かれている。ここからファイルをダウンロードすることもできるが、このWebページで[Linux]−[X86_64]−[WSL-Ubuntu]を選択して、[runfile(local)]を選択すると、インストールコマンドが表示されるので、これをWSL 2内で実行するとwgetコマンドによって直接ファイルをダウンロードできる。

 このとき、自分のLinuxホームディレクトリで実行を行うこと。こうすることで、ファイルの書き込みを高速なLinuxネイティブドライブの上で行える。wgetコマンドが終了したら、ダウンロードしたrunファイルを実行し、CUDA Toolkitのインストールを行う。

CUDA Toolkitをインストールする CUDA Toolkitをインストールする
NVIDIAのWebサイトからCUDA Toolkitをダウンロードする場合、表示されるコマンドをWSLディストリビューション側で実行するとよい。ダウンロードと同時にCUDA Toolkitのインストールが可能になる。

 最低限のテストとしては、CUDA Toolkitに含まれているサンプルを実行させる方法がある。現在のCUDA Toolkitインストーラー(cuda_11.2.0_460.27.04_linux.run)は、デフォルトでインストール時にホームディレクトリに「NVIDIA_CUDA-11.2_Samples」というディレクトリを作り、サンプルコードをインストールするようになっている。また、「--samples」オプションを使えば、サンプルだけをインストールしてくれる。

 サンプルをコンパイルするには、以下のコマンドを実行する。

cd NVIDIA_CUDA-11.2_Samples
make


サンプルをコンパイルするコマンド

 多数のサンプルがあるため、かなり時間がかかる。コンパイルに関する説明は本稿の範囲を超えるので、ここでは割愛させていただく。なお、一部のサンプル(~/NVIDIA_CUDA-11.2_Samples/0_Simple/simpleMPI)は、MPIコンパイラのインストールが必要でエラーになるが、他のサンプルには影響はないので、このサンプルを動かさないのであれば、そのままでよい。

 動作の確認方法としては、サンプルの「deviceQuery」(~/NVIDIA_CUDA-11.2_Samples/1_Utilities/deviceQuery)を実行するとよい。これは、CUDA経由でGPU情報を得て表示するものだ。これが動作しているということは、仮想マシンの中で動作しているWSL 2からGPUが「見えている」ことになる。

CUDA ToolkitによるGPUへのアクセスを確認 CUDA ToolkitによるGPUへのアクセスを確認
CUDA Toolkitに付属のサンプルプログラムを実行してみた。仮想マシン内で動作しているWSL 2の中でホストの管理しているGPUへのアクセスが可能になりGPUの情報表示が行われている。

 なお、今回の評価は、ノートPC(Razer Blade Stealth 13)にThunderbolt 3経由で、外付けPCIeエンクロージャー(Razer CORE X)を接続、GPUボード(NVIDIA GeForce GTX 1070)を装着して評価を行った。WSL 2からのGPU利用は、ホスト側でGPUが認識されていれば、問題なく行える。

 OpenGL互換のオープンソース実装であるMesaを同様にDirectX12で動作させる計画もある。こちらが動作すると、3DグラフィックスをGPUで処理することが可能になる。ただし、現状、WSL 2内からのグラフィックス表示は、Win32側などで実行されるX Serverなどに頼る必要がある。

 WSL 2からGPUコンピューティングが可能になることで、別途Linuxマシンを別途用意する必要がなく、WindowsマシンでもLinux上のGPUコンピューティングアプリケーションが利用可能になる。高価なGPUボードを装着した1台のマシンで作業を完結できるメリットは小さくない。GPUコンピューティングは、Deep Learningの学習の高速化などにも利用でき、Linux上ではさまざまなDeep Learningアプリケーションが利用可能だ。WSL 2を使えばこうした環境をすぐに手に入れることができる。


 2021年に実装される予定のWSL 2の主な新機能について紹介したが、この他にも、まだプレビューが行われていないが、Linux GUIアプリケーションへの対応などが行われる予定だ。

 これは、Linux用のGUIアプリケーション(X Windowアプリケーション)のウィンドウをWindows 10デスクトップに表示する機能だ。原稿執筆時点では、まだプレビュー版に実装されていないため、プレビューが2021年からとなりそうだ。21H1には間に合わないかもしれないが、2021年中には実装されるものと思われる。プレビュー版が公開された時点で、WSL 2によるLinuxのGUIアプリケーションの実行機能については詳しく紹介する予定だ。

前のページへ 1|2       

Copyright© Digital Advantage Corp. All Rights Reserved.

スポンサーからのお知らせPR

注目のテーマ

Microsoft & Windows最前線2025
AI for エンジニアリング
ローコード/ノーコード セントラル by @IT - ITエンジニアがビジネスの中心で活躍する組織へ
Cloud Native Central by @IT - スケーラブルな能力を組織に
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。