VMconnect と RDP の違い
- 2013/11/24
- 11:10
昨今の IT 業界では 「仮想化技術」 が盛んになってきています。
僕が勤めている病院でも Microsoft Hyper-V Server を使って色々なサーバを仮想化しています。物理マシンのサーバ機を仮想化にすることで、管理のし易さや省スペースに大変貢献してくれます。また、僕自身もテスト環境で Hyper-V を使っており、仮想化技術は無くてはならない存在になっています。
そんな今回の記事は、Hyper-V についてのメモ………ではありますが、その中でも Hyper-V の機能の一つである 「VMconnect （仮想マシン接続ツール）」 についてメモします。
僕が勤めている病院でも Microsoft Hyper-V Server を使って色々なサーバを仮想化しています。物理マシンのサーバ機を仮想化にすることで、管理のし易さや省スペースに大変貢献してくれます。また、僕自身もテスト環境で Hyper-V を使っており、仮想化技術は無くてはならない存在になっています。
そんな今回の記事は、Hyper-V についてのメモ………ではありますが、その中でも Hyper-V の機能の一つである 「VMconnect （仮想マシン接続ツール）」 についてメモします。
なぜ Hyper-V ではなく VMconnect をメモするのかといいますと、それは 「仮想マシンへのリモートデスクトップの速度」 がきっかけでした。VDI (Virtual Desktop Infrastructure) の遊びようなものを検証したときに 「シンクライアントからの RDP の操作が重い」 という現象が発生しました。ところが一方で VMconnect から仮想マシンを操作したところ、とてもサクサクと動いてくれました。
じゃぁ VMconnect と RDP の違いってなんだろう……という疑問から、今回は Hyper-V の機能の一部である VMconnect についてメモしていくことになったのです。Hyper-V の概念や仕組みに関しては、また別の機会でメモする予定です。
仮想化って？
まず VMconnect を理解するには、Hyper-V （仮想化技術） の大まかな仕組みを知る必要があります。ここでは簡単にですが Hyper-V に関してメモしていきます。
Hyper-V は Microsoft が開発した仮想化環境のことを指します。仮想化を分かりやすく言うと 「OS 上で別の OS を動かす」 仕組みです。たとえば Windows 7 のデスクトップ上で Windows XP を動作させる、また Windows 8 のデスクトップ上で CentOS を動作させる、などのことができます。
仮想化技術の基本は OS 上で別の OS を動作させることですが、仮想化環境によっては 「仮想化の構造」 が異なります。仮想化の構造には2種類あり、それぞれ 「ホスト型」 と 「ハイパーバイザー型」 に分けられます。
ホスト型 は OS にインストールした仮想化ソフトウェアの上で仮想マシンを動作させます。この基礎となる OS のことを ホストOS と呼び、仮想マシンのことを ゲストOS と呼びます。主に VMware Player や Windows Virtual PC などがホスト型に当てはまります。
↑図1：ホスト型の仮想化環境
一方の ハイパーバイザー型 は、ハードウェアの上で動作する仮想化ソフトウェアの上で OS が動作します。今回の Hyper-V はこのハイパーバイザー型です。ホスト型は ホスト OS と ゲスト OS といった表現方法を用いましたが、Hyper-V の場合は 「親パーティション」 と 「子パーティション」 と呼びます。ハイパーバイザー型はハードウェア上で動作するため、ホストとゲストといった位置関係がなくなってしまい、仮想化ソフトウェアからみれば全ての OS が仮想マシンとして認識されます。
ただ Hyper-V では、親パーティションのことを 「管理 OS」 とも呼ぶように、仮想マシンの管理や操作は管理 OS から行います。管理 OS は仮想化アーキテクチャ的には子パーティションと同等の位置にいますが、イメージ的には管理 OS がホスト OS と置き換えてもよさそうですね
↑図2：ハイパーバイザー型の仮想化環境
このように2種類の仮想化環境はそれぞれ構造が違いますので、使い勝手が大分変わってきますし、CPU の種類や OS のビット数によっては動作しない場合もあります。ただ前述もしましたが、共通して言えるのは 「OS 上で別の OS を動かす」 ことです。VMware Player でしたら無料ですので、もしご興味のある方は操作して体感していただければと思います。
↑図3：Windows 7 の上で CentOS を動作させる (VMware Player)
今回の概要
超ハイスペックなサーバで仮想化マシンを稼働させ、シンクライアントからアクセスさせれば、VDI っぽい仕組みができるのではないか…という提案が挙がりました。そこで手始めに Hyper-V Server に仮想マシンをいくつか稼働させ、その検証を開始しました。
↑図4：VDI 「っぽい」 もの
VM は独立した1台のマシンとして認識されますので、ネットワーク的にも IP アドレスを付与したネットワーク通信が可能になります。ネットワーク通信が可能であれば、リモートデスクトップ、VNC や SSH など仮想マシンを操作する方法は沢山ありますが、今回は VM が Windows OS ですのでシンクライアントは RDP を使って、Hyper-V Server へアクセスすることにしました。
↑図5：VM は IP を付与するためリモート操作が可能
ところがシンクライアントから RDP で VM へアクセスすると、通常の事務業務 （Office などのビジネスアプリケーション操作） は遅延なく行なえましたが、ネットワークトラフィックのかかる処理 （とくに WEB カメラの閲覧） となると、そりゃぁもう遅いったらなんのまぁもう…やぁねぇオクサン…な状態でした。。
ただ RDP ではなく Hyper-V マネージャ （VMconnect） から VM を操作したところ、RDP ではあんなにカクカクした WEB カメラの描画がとてもヌルヌルと映し出されるのです。繰り返しになりますが 「じゃぁこの VMconnect ってなにもの？」 という疑問にたどり着き、今回の記事を書くことになったのです。
↑図6：RDP の VM アクセスが遅い
VM のパケットを解析
ここからは一気に書いてしまいます。まずは RDP からです。
毎度おなじみの Wireshark を実行させ、シンクライアントから RDP 接続したときのパケットの流れを監視しました。その結果 「ポート 3389」 への TCP ハンドシェイクを確認した後、RDP 通信の大量のパケットが流れてきました。PPTP のメモでも書きましたが、TCP 通信ではハンドシェイクが必ず行われます。また、ポート 3389 は RDP 通信に用いられるポート番号ですから、シンクライアントと VM の RDP が確立していることが分かります。
↑図7：RDP 通信
次に同環境で VMconnect を使ったアクセスを試みました。しかし結果 「パケットを受信しませんでした」。VM は操作できるのに VM からのパケットを1つもキャプチャしなかったのです。
そこで次は Hyper-V Server のパケットを監視したところ、「ポート 2179」 のパケットが大量に流れてきました。また VMconnect を切断するとポート 2179 のデータが消えることから、どうやらこのパケットが VMconnect のパケットと見て間違いなさそうです。ということは VMconnect は VM を直接操作しているわけではなく、管理 OS へリモートアクセスした上で 「VM をローカル操作」 している動きになるようですね。
↑図8：VMconnect 通信
しかも VM をローカル操作するということは、仮想ネットワーク にネットワークトラフィックが発生しませんので、Hyper-V 内のネットワーク負荷が軽減されることになります。
ちなみに Windows に Hyper-V 機能をインストールすると NIC の構成が変わります。インストール前はホスト OS が 物理 NIC をバインドしていますが、インストール後は 「仮想スイッチ」 が物理 NIC をバインドし 、管理 OS や VM には 「仮想 NIC」 が割り当てられます。
↑図9：Hyper-V はネットワーク構造を変える
ということは、RDP パケットよりも VMconnect のローカルコンソール信号の方がデータ量が少ないということなのでしょうか…。もしそうだとしたら、VMconnect で VM をローカル操作した方がいいのかもしれませんね。
どちらにせよ、今回の目的であった 「RDP と VMconnect の違い」 については、RDP は VM にダイレクトに TCP リモート通信を行い、VMconnect は管理 OS へリモートコンソール接続し、ローカルで VM に接続するという間接的なものであることは分かりました。
個人的には VMbus の仕組みについてもう少し詳しく調べる必要がありそうですが、それよりも RDP についてもっと詳しい情報が必要そうですね。RDP についての技術的なことは分かっていないので、もしかしたら RDP の仕組みを知っていれば、案外答えは簡単に出たのかもしれません。
最後に
僕が初めて扱った仮想化技術は Hyper-V 、、、と言いたいところですが、実は VMware Player ……でもなく、知る人ぞ知るアノ Windows 7 の 「XP モード」 でした。
XP モードは Windows 7 に搭載された仮想化技術でして、Windows 7 の上に XP を動作させるものでした。「Windows 7 で動作しないアプリケーションは XP モードで動かせやｗ」 という Microsoft からのお言葉を受けたことが、僕の仮想化との出会いでした。
しかしこの XP モードが、超不安定だったのです。マシンのスペックを上げたり、構築の方法を変えたりと、様々な方法を模索・検証したのですがどれも失敗。
（仮想化ってこんなに使いにくいの！？ もう帰れよ！！！）
これが僕の仮想化に対する印象でした。
でもそれから VMware Player に出会い、そして Hyper-V を使うようになり、今となっては 仮想化大好き人間 になっています。けれども仮想化技術について勉強すれば勉強するほど……、
検証環境 → 仮想化最高！
本番環境 → 物理マシンで運用した方が安心する…
…と思ってしまうのは、また僕が勉強不足だからでしょうか。。
じゃぁ VMconnect と RDP の違いってなんだろう……という疑問から、今回は Hyper-V の機能の一部である VMconnect についてメモしていくことになったのです。Hyper-V の概念や仕組みに関しては、また別の機会でメモする予定です。
仮想化って？
まず VMconnect を理解するには、Hyper-V （仮想化技術） の大まかな仕組みを知る必要があります。ここでは簡単にですが Hyper-V に関してメモしていきます。
Hyper-V は Microsoft が開発した仮想化環境のことを指します。仮想化を分かりやすく言うと 「OS 上で別の OS を動かす」 仕組みです。たとえば Windows 7 のデスクトップ上で Windows XP を動作させる、また Windows 8 のデスクトップ上で CentOS を動作させる、などのことができます。
仮想化技術の基本は OS 上で別の OS を動作させることですが、仮想化環境によっては 「仮想化の構造」 が異なります。仮想化の構造には2種類あり、それぞれ 「ホスト型」 と 「ハイパーバイザー型」 に分けられます。
ホスト型 は OS にインストールした仮想化ソフトウェアの上で仮想マシンを動作させます。この基礎となる OS のことを ホストOS と呼び、仮想マシンのことを ゲストOS と呼びます。主に VMware Player や Windows Virtual PC などがホスト型に当てはまります。
↑図1：ホスト型の仮想化環境
一方の ハイパーバイザー型 は、ハードウェアの上で動作する仮想化ソフトウェアの上で OS が動作します。今回の Hyper-V はこのハイパーバイザー型です。ホスト型は ホスト OS と ゲスト OS といった表現方法を用いましたが、Hyper-V の場合は 「親パーティション」 と 「子パーティション」 と呼びます。ハイパーバイザー型はハードウェア上で動作するため、ホストとゲストといった位置関係がなくなってしまい、仮想化ソフトウェアからみれば全ての OS が仮想マシンとして認識されます。
ただ Hyper-V では、親パーティションのことを 「管理 OS」 とも呼ぶように、仮想マシンの管理や操作は管理 OS から行います。管理 OS は仮想化アーキテクチャ的には子パーティションと同等の位置にいますが、イメージ的には管理 OS がホスト OS と置き換えてもよさそうですね
↑図2：ハイパーバイザー型の仮想化環境
このように2種類の仮想化環境はそれぞれ構造が違いますので、使い勝手が大分変わってきますし、CPU の種類や OS のビット数によっては動作しない場合もあります。ただ前述もしましたが、共通して言えるのは 「OS 上で別の OS を動かす」 ことです。VMware Player でしたら無料ですので、もしご興味のある方は操作して体感していただければと思います。
↑図3：Windows 7 の上で CentOS を動作させる (VMware Player)
今回の概要
超ハイスペックなサーバで仮想化マシンを稼働させ、シンクライアントからアクセスさせれば、VDI っぽい仕組みができるのではないか…という提案が挙がりました。そこで手始めに Hyper-V Server に仮想マシンをいくつか稼働させ、その検証を開始しました。
↑図4：VDI 「っぽい」 もの
VM は独立した1台のマシンとして認識されますので、ネットワーク的にも IP アドレスを付与したネットワーク通信が可能になります。ネットワーク通信が可能であれば、リモートデスクトップ、VNC や SSH など仮想マシンを操作する方法は沢山ありますが、今回は VM が Windows OS ですのでシンクライアントは RDP を使って、Hyper-V Server へアクセスすることにしました。
↑図5：VM は IP を付与するためリモート操作が可能
ところがシンクライアントから RDP で VM へアクセスすると、通常の事務業務 （Office などのビジネスアプリケーション操作） は遅延なく行なえましたが、ネットワークトラフィックのかかる処理 （とくに WEB カメラの閲覧） となると、そりゃぁもう遅いったらなんのまぁもう…やぁねぇオクサン…な状態でした。。
ただ RDP ではなく Hyper-V マネージャ （VMconnect） から VM を操作したところ、RDP ではあんなにカクカクした WEB カメラの描画がとてもヌルヌルと映し出されるのです。繰り返しになりますが 「じゃぁこの VMconnect ってなにもの？」 という疑問にたどり着き、今回の記事を書くことになったのです。
↑図6：RDP の VM アクセスが遅い
VM のパケットを解析
ここからは一気に書いてしまいます。まずは RDP からです。
毎度おなじみの Wireshark を実行させ、シンクライアントから RDP 接続したときのパケットの流れを監視しました。その結果 「ポート 3389」 への TCP ハンドシェイクを確認した後、RDP 通信の大量のパケットが流れてきました。PPTP のメモでも書きましたが、TCP 通信ではハンドシェイクが必ず行われます。また、ポート 3389 は RDP 通信に用いられるポート番号ですから、シンクライアントと VM の RDP が確立していることが分かります。
↑図7：RDP 通信
次に同環境で VMconnect を使ったアクセスを試みました。しかし結果 「パケットを受信しませんでした」。VM は操作できるのに VM からのパケットを1つもキャプチャしなかったのです。
そこで次は Hyper-V Server のパケットを監視したところ、「ポート 2179」 のパケットが大量に流れてきました。また VMconnect を切断するとポート 2179 のデータが消えることから、どうやらこのパケットが VMconnect のパケットと見て間違いなさそうです。ということは VMconnect は VM を直接操作しているわけではなく、管理 OS へリモートアクセスした上で 「VM をローカル操作」 している動きになるようですね。
↑図8：VMconnect 通信
しかも VM をローカル操作するということは、仮想ネットワーク にネットワークトラフィックが発生しませんので、Hyper-V 内のネットワーク負荷が軽減されることになります。
ちなみに Windows に Hyper-V 機能をインストールすると NIC の構成が変わります。インストール前はホスト OS が 物理 NIC をバインドしていますが、インストール後は 「仮想スイッチ」 が物理 NIC をバインドし 、管理 OS や VM には 「仮想 NIC」 が割り当てられます。
↑図9：Hyper-V はネットワーク構造を変える
ということは、RDP パケットよりも VMconnect のローカルコンソール信号の方がデータ量が少ないということなのでしょうか…。もしそうだとしたら、VMconnect で VM をローカル操作した方がいいのかもしれませんね。
どちらにせよ、今回の目的であった 「RDP と VMconnect の違い」 については、RDP は VM にダイレクトに TCP リモート通信を行い、VMconnect は管理 OS へリモートコンソール接続し、ローカルで VM に接続するという間接的なものであることは分かりました。
個人的には VMbus の仕組みについてもう少し詳しく調べる必要がありそうですが、それよりも RDP についてもっと詳しい情報が必要そうですね。RDP についての技術的なことは分かっていないので、もしかしたら RDP の仕組みを知っていれば、案外答えは簡単に出たのかもしれません。
最後に
僕が初めて扱った仮想化技術は Hyper-V 、、、と言いたいところですが、実は VMware Player ……でもなく、知る人ぞ知るアノ Windows 7 の 「XP モード」 でした。
XP モードは Windows 7 に搭載された仮想化技術でして、Windows 7 の上に XP を動作させるものでした。「Windows 7 で動作しないアプリケーションは XP モードで動かせやｗ」 という Microsoft からのお言葉を受けたことが、僕の仮想化との出会いでした。
しかしこの XP モードが、超不安定だったのです。マシンのスペックを上げたり、構築の方法を変えたりと、様々な方法を模索・検証したのですがどれも失敗。
（仮想化ってこんなに使いにくいの！？ もう帰れよ！！！）
これが僕の仮想化に対する印象でした。
でもそれから VMware Player に出会い、そして Hyper-V を使うようになり、今となっては 仮想化大好き人間 になっています。けれども仮想化技術について勉強すれば勉強するほど……、
検証環境 → 仮想化最高！
本番環境 → 物理マシンで運用した方が安心する…
…と思ってしまうのは、また僕が勉強不足だからでしょうか。。
スポンサーサイト
