図解で理解できる（はず）Microsoftの仮想化技術――Windows上で稼働するLinux、動かしているのはどのテクノロジー？（その2）：その知識、ホントに正しい？ Windowsにまつわる都市伝説（95）（1/2 ページ）

前回は、Windows 10で実現可能なLinux環境とそのベースとなっているテクノロジーを、実際の動作中のスクリーンショットを使って簡単に紹介しました。今回は、図版でLinux環境とその技術的な背景を解説します。一部はWindows 10 Insider Previewを使用しています。先日、リリースされたWindows 10 Fall Creators Updateとは異なる部分がある可能性があります。ご了承ください。

[山市良，テクニカルライター]

連載目次

Linux仮想マシン on Hyper-V

　前回、Windows 10上でLinux環境を実現する最もシンプルな方法として紹介した画面1は、Windows 10の「クライアントHyper-V」上の仮想マシンに「Ubuntu 16.04 LTS（Long Term Support）」をインストールして実行し、「仮想マシン接続」（vmconnect.exe）でコンソールに接続したものです。

画面1　Windows 10のクライアントHyper-Vの仮想マシンとして動作するUbuntu Linux（Ubuntu 16.04 LTS）

　この環境を技術的に図示すると、以下の図1のようになります。仮想マシンでは、ネイティブで完全なUbuntuのOSインスタンスが動作しています。

図1　Windows 10のクライアントHyper-Vの仮想マシンとして動作するUbuntuの仕組み

　「Hyper-V」は、単一のハードウェア上で複数のOSの同時実行を可能にするハイパーバイザー型の仮想化技術です。ちょっと想像するのが難しいかもしれませんが、ハイパーバイザーの視点から見れば、Hyper-Vの仮想マシンを管理する（そして実行しているように見える）Windows 10のOS（ホストOS、管理OS）もまた“一種の仮想マシン”といえます。ホストOSからは、Hyper-Vの管理インタフェース（「Hyper-Vマネージャー」やWMI（Windows Management Instrumentation）、仮想マシンバスなど）を通じて、仮想マシンとそのゲストOSにアクセスすることができます。

　Hyper-Vの仮想マシンがホストOS上（この場合はWindows 10上）で動作しているわけではないことを覚えておいてください。

Bash on Ubuntu on Windows（Windows Subsystem for Linux）

　Windows 10 Anniversary Update（バージョン1607）でβ提供され、Windows 10 Fall Creators Update（バージョン1709）で正式版となった「Windows Subsystem for Linux（WSL）」では、Windowsストアで提供される「Bash on Ubuntu on Windows」（今後、この複雑で長い呼称は使われなくなるようです）や、その他のLinuxディストリビューションをインストールすることで、ネイティブなbash環境とLinuxアプリケーションの実行環境が利用可能になります（画面2）。

画面2　Bash on Ubuntu on WindowsのLinux環境（画面はWindows 10 Insider Preview バージョン1709、ビルド16288）。正式版ではLinux環境からWindowsアプリケーションの実行を開始できるようにもなる予定

　この環境を技術的に図示すると、以下の図2のようになります。

図2　Windows Subsystem for Linuxにより、Windows上でUbuntuのネイティブイメージ（bash）が動く仕組み

　Bash on Ubuntu on Windowsは、Linuxカーネルが存在し、その上で動く「/bin/bash」プロセスではありません。プロセスの視点から見ると、Windows上で動く他のプロセスと全く同じように見えます。

　以下の画面3は、「Windows Sysinternals」の「Process Explorer」を使用して、bashプロセスをツリー表示で参照したところです。

画面3　Linuxネイティブなアプリケーションであるはずのbashプロセスが、Windowsのプロセスと同じように実行されているように見える

　画面3内には、「ubuntu.exe」やその子プロセスとして「conhost.exe」（コマンドプロンプトのホスト）、「wsl.exe」（Windows Subsystem for Linux Launcher）などが存在しますが、そのプロセスツリーとは別に“左寄せ”の状態でbashプロセスが存在します。

　「Ubuntu」アプリ（ubuntu.exe）から開始されるランチャー（%Systemroot%\System32\wsl.exe）、またはコマンドライン版ランチャー（%Systemroot%\System32\bash.exe）により、Windows Subsystem for Linuxの環境が初期化されて「/bin/bash」のプロセスが開始するのですが、「/bin/bash」を開始した初期化プロセスは既に終了しているため、“左寄せ”（親のプロセスが既に存在しないことを示す）になっているのです。

　前回も触れましたが、Windows Subsystem for Linuxは、Microsoft Researchの「Drawbridgeプロジェクト」をWindowsに実装したものです。

　Drawbridgeでは「picoプロセス」と呼ばれる、プロセスベースの分離されたコンテナ環境（後述する「Dockerコンテナ」とは関係のない、入れ物としてのコンテナ）に空のユーザーモードアドレス空間が用意され、その中でWindowsアプリケーション（Portable Executable：PEイメージとも呼ばれます）ではないイメージを実行できるようにし、「picoプロバイダー」（やライブラリOS）と呼ばれるカーネルモードドライバがカーネル機能へのアクセスを仲介します。

　Bash on Ubuntu on Windowsの場合、Linuxネイティブイメージであるbashプロセスがpicoプロセスとして動作し、Windows Subsystem for Linuxのpicoプロバイダーである「Lxss」（%Systemroot%\System32\drivers\lxss.sys）と「LXCore」（%Systemroot%\System32\drivers\LXCore.sys）がLinuxカーネルをエミュレーションし、Windowsカーネルへのアクセスをラップしています。

　ここまでがんばって説明しましたが、筆者も正確に理解できているかどうか少し不安はあります。詳しくは、Drawbridgeプロジェクトのサイトや公式ブログの記事を参照してください。

• Drawbridge［英語］（Microsoft Research）
• Pico Process Overview［英語］（Windows Subsystem for Linux）