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

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

» 2017年10月24日 05時00分 公開
[山市良テクニカルライター]
「Windowsにまつわる都市伝説」のインデックス

連載目次

Linux仮想マシン on Hyper-V

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

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

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

図1 図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 画面2 Bash on Ubuntu on WindowsのLinux環境(画面はWindows 10 Insider Preview バージョン1709、ビルド16288)。正式版ではLinux環境からWindowsアプリケーションの実行を開始できるようにもなる予定

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

図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 画面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プロジェクトのサイトや公式ブログの記事を参照してください。

       1|2 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

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

メールマガジン登録

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