Ubuntu Linux で VMware View Client を動かす

さて、前回 Ubuntu Linux 版の ViewClient が出たという話をしたが、手元の環境では少々動かすのに苦労したのでメモ代わりに。

● 本来の手順

手順としては、 http://downloads.vmware.com から「VMware View Client」を選択

クライアント一覧から「VMware View Client for Ubuntu Linux」のダウンロードをクリック

 すると、Ubuntu ソフトウェアセンターが起動、パッケージが選択されているのでそれをインストール...するはずが、以下のように「見つかりません」と言われてしまう。

さて、どうしてだろうと調べてみた。

● 問題その1: サポートOS

まあ、一つはリリースノートを読むと書いてある。サポートOSだ。

以下に、Ubuntu Linux 版の ViewClient のリリースノート(和訳)だ。
http://www.vmware.com/jp/support/support-resources/pubs/viewclients_pubs/viewclient-linux-release-notes.html

Ubuntu 32 ビット 10.04 および 10.10 のサポート

私が試した Ubuntu  は 11.04 と 11.10 のため、新しすぎた、というのが一つ目の敗因だ。
このため、10.10 日本語 Remix をダウンロード、LiveCDで起動して試してみた。

● 問題その2: レポジトリ

10.10 でもやはり「見つかりません」と言われるので少々確認をしてみた。
どうも、Ubuntu の vmware-view-client は 「Canonical Partners」 というレポジトリにあるらしい。
そこで、10.10 のアップデートセンターでレポジトリを追加した。

通常、 Canonical Partners は「その他ソース」の項目に設定されており、チェック一つでレポジトリとして有効になるようだ。( 参考: http://vpc.uconn.edu/help/linux/ )

しかし、日本語Remix のアップデートセンターの設定では、この項目が見当たらない。

そこで、下の「追加」ボタンを押し、以下のCanonical Partners の APTラインを追加する。

deb http://archive.canonical.com/ lucid partner

これで準備完了だ。

Ubuntu Linux の Firefox で再び、VMware 社のサイトにアクセス、Download ボタンを押すと、以下のように「ソフトウェアの追加インストールを行いますか」のパネルが表示された。

そしてダウンロードが終わると、 インターネットメニューに「VMware View Client」が追加されている。

やっとインストール完了だ。

なお、このAPTラインを追加しても 11.10 などサポートより新しい UbuntuLinux では vmware-view-client が選択肢に出てこない。当分は 10.10 と 10.4 しか使えないようだ。

● VMware View Client for Ubuntu

初回起動時にはライセンス条項の表示と、確認が行われる。

 

こちらをOKすると、ConnectionServer / SecurityServer のURLを入力するパネルが表示される。見た目こそ異なれ、他の ViewClient と同じだ。

URLを入力、「Continue」 ボタンを押すと認証処理が行われる。これも他の ViewClient と同じだ。

認証に成功すると、かなり大きなアイコンが並び、デスクトップVMを選択する画面になる。
これは Mac 版の ViewClient に近い。アイコンの下にプロトコルが表示、選択になるのも同じだ。

アイコンを選択すると、デスクトップが表示される。もちろん PCoIP を使っての接続も可能だ。

ここまでくると非常に快適に利用できる。

課題としては、キーボードについてだ。今回 UbuntuLinux はFusion上の仮想マシンで、かつ LiveCD のため 106 キーボードに設定されており、かつ Mac 側が英語キーボードで配列が厄介な状態だったため確認できていない。

しかし、PCoIP のためおそらくデスクトップVM側に設定したキー配列がそのまま使われるのではないかと思われる。
混乱を防ぐためにも配列を統一しておいた方がいいだろう。

VMware View で RDP 接続しているとデスクトップVMが再起動してしまうことがある

出張が続いたのと、あと VMware Fusion がとある事情から一時的に動かなくなってしまってて更新が遅れてしまった。

さて、VMware View のクライアントソフトウェアが非常に拡充してきたのはご存じだろうか?

詳細は以下にあるので確認して欲しいが、Mac 用のクライアントが新しくなり、また Ubuntu Linux 用の公式クライアントが追加されている。
http://downloads.vmware.com/d/info/desktop_end_user_computing/vmware_view_clients/1_0

実のところ、これまでも Linux 用のクライアントがなかった訳ではない。

ただ、それは Googles Codes にソースコードの形で提供されていた。
http://code.google.com/p/vmware-view-open-client/

クライアントソフトウェア単体として動かすのではなく、Linux ベースのシンクライアント製品に組み込まれるためにこういうソースコード形態での提供がなされていた。

Linux は、今風に言うなら「断片化が激しい」ため、数多のディストリビューションをサポートするには手に余るし、それらを寄せ集めても Windows, Mac ほどの需要はなかったという訳だ。
しかし、ここ数年 Ubuntu Linux は(例のデスクトップ環境のごたごたはあるにせよ) Linux をデスクトップ端末として使う際の定番になっている。何か一つ Linux で ViewClient をサポートするなら、これは順当なところだろう。

また、 iPad 向けのソフトウェアも着実にアップデートされており、Android 用も増えている。

これらは全て PCoIP をサポートしており高精細の画面を効率よく転送することが出来る。
ここまで PCoIP 対応のクライアントソフトウェアが充実すると、VMware View で RDP を使うことはほとんどないだろう。

また今回紹介する以下の話からも、今後はRDPを使わない、PCoIP専門に持っていく方が良いといえる。
さて、前書きが長くなってしまったが本題に入りたい。

● 問題

非 Windows 環境の RDP クライアントで WindowsXP SP3 を実行する仮想マシンに接続した場合、接続先の WindowsXP SP3 がクラッシュすることがある。

● 原因

これは、Windows XP SP3 に含まれる RDPDD.DLL のバグである。
詳細は以下のKB963038 に記載があるので参照して欲しい。

・WindowsXP を実行しているリモートコンピューターへのリモートデスクトップ接続を確立すると、エラーメッセージ:"停止:0x1000008E"

また、以下の Blog にも類似の記載がある。

・リモートデスクトップを利用していてリモート先PCがSTOPエラーでブルースクリーン
・リモートデスクトップでOSが落ちる

確認方法としてはブルースクリーンを見るのが一番であるが、そもそもリモートアクセスしてるのだから vSphereClient でコンソールを見るなど難しいであろう。

事後の検証としては Nirsoft の BlueScreenView というソフトを使うと便利だ。
http://www.nirsoft.net/utils/blue_screen_view.html

これはクラッシュに生成される minidump を確認してくれるというものだ。
以下の図のように、ダンプ時の状況を表示してくれるが、ここで Bug Check Code を見ると確かに 0x1000008E であるのが分かる。

● 対応

ここまで分かれば話は早い。つまりはこの RDPDD.DLL の問題を解決すればいいのだ。
これには三つの手段がある。

1. RDPを使わない
2. マイクロソフトの 修正プログラム を適用
3. RDPDD.DLL を差し替える

一番いいのは 1. だ。冒頭に触れたように PCoIP 対応のクライアントは増えてるのだからわざわざRDPを使うことはない。


二つ目は、先に紹介したマイクロソフトのKBにリンクされている 修正プログラム を適用するというもの。Fix253552 というそれをあてればこの問題は発生しなくなる。

ただし、この修正プログラムは WindowsUpdate でははいってこず、先のKB963038のページの「この技術情報に対応する修正プログラムのダウンロードのリスト」にあるリンクからしか手に入らない上、メールアドレスは取られるわ、CAPTCHA はあるわで少々面倒だ。

三つ目は、先ほどリンクしたブログにあるように、WindowsXP SP2 の RDPDD.DLL に置き換えてしまうことで問題が消えるというもの。実際に消えるのは確認したが無理矢理DLLを置き換えるのもあまりよろしくないし、なにより他の問題を引き起こさないかが未知数だ。
だったら、2つめの修正プログラムをあてた方がまだいいだろう。

あと、この問題は WindowsXP SP3 でしか発生しない。つまり Windows7 ならば問題はないのだ。仮想デスクトップも Windows7 にしてしまうというのも解法としてはアリだろう。

[余談] MacOS X のVPN接続をコマンドラインから実行する

仮想化とは関係ないけど、余談で。

MacOS X では VPN接続機能が用意されており、システム環境設定の「ネットワーク」にて、左下の「+」ボタンを押すことで設定が可能になる。標準で用意されているのは、L2TP over IPsec, PPTP, Cisco IPSec の三つだ (Lion の場合)

それぞれを選択、アカウントなど適宜情報を記入することで L2で VPNを張ることができる。

ただ、その接続がシステム環境設定を開いて該当するネットワーク設定を選択、「接続」ボタンを押すか、メニューバーにVPN設定のアイコンをあらかじめ表示させておき、そこから選ぶか、になる。

そう頻繁にVPNを張らない人や、MacBookAir を利用しててメニューバーの横幅が足りないのであまりアイコンを表示させたくない人からすれば、一々システム環境を開くのは面倒だ。

そこで、ターミナルのコマンドラインから VPNを張れないかを調べてみた。
とりあえず、ざっと調べた限りではそれっぽいコマンドは見つけられなかった。のでスクリプトで対応させることとした。

#!/bin/sh
DoScript() {
/usr/bin/osascript << __EOF__
tell application "System Events"
   tell current location of network preferences
       set VPNservice to service "$2"
       if exists VPNservice then $1 VPNservice
   end tell
end tell
__EOF__
    return 0 ;
}
case $1 in
"connect")
    DoScript "connect" $2 ;;
"disconnect")
    DoScript "disconnect" $2 ;;
esac

DoScript 関数がこのシェルスクリプトの実体で、osascript にヒアドキュメントで AppleScript を流し込み、実行している。

tell application "System Events" により SystemEvents に対して指示を送り、さらにその中で「current location of network preferences」、つまり現在のネットワーク設定に指示を送っている。
OS X をあまり使われてない方には馴染みのないことだが、OS X では「場所」ないしは「ネットワーク環境」という名前で、使用するネットワークインターフェイスやインターフェイス冠の優先順位、IPアドレス、DNS、デフォルトルート、プロクシーなどの設定をまとめて切り替えることができる。ネットワーク管理をやってた頃はいく先々ごとにこのネットワーク環境を作り、ついたら切り替えることでたとえ固定IPアドレスや特別なプロクシの設定が必要でも一気に切り替えられたので便利なのだ。
ThinkPad など一部のベンダーのPCにも同様の機能はあるが、OS標準でないため細かいところで面倒だったのと、やはりUNIXコマンドが標準搭載なのもあり Macのノートは私の回りのネットワーク管理者にとっては必須のデバイスであった。

何を送ってるかというと $2 にはVPNサービス名が入り、$1 には connect か disconnect が入るため、set VPNservice to service "何らかのVPNサービス名" で、VPNService という変数にサービス名を突っ込む。

それから、if exist VPNservice でそのサービス名に該当する設定があるかを確認、あれば $2, つまり connect(接続)もしくは disconnect(切断)を行う。

case でくるんでるのは、コマンドラインからは connect でも start でもよくしようとして、途中で面倒になったからそうなっているだけだ。( "connect") を "connect"|"start") とかするだけなのだが)

さて、このスクリプトを vpnc という名前でパスの通るところに保存、実行フラグを立てる。システム環境設定のネットワークから「MyOffice」というVPN設定を作った後

$ vpnc connect MyOffice

とコマンドを叩けば、接続される訳だ。
なお、厳密には「接続を指示する」ところでこのスクリプトは終了してしまう。VPNの接続確立までに時間がかかる場合は、そのぶん待った方がいい。

私は接続先に既知のサーバがあるので、ちょっと待ってから ping を打って繋がってる確認した後に利用するようにしている。

もう少し頑張ればVPN明があるかをチェックしてなければエラーを返すとか、色々改善もできるだろうが私の用途ではこれで十分なのでそこから直していない。

USBメモリから起動するOSを仮想マシンで利用する(1)

先日、とある事情にてUSBメモリに書き込まれたOS (Linux) を仮想環境上で起動することになった。その時の手順のメモ。

残念ながら、VMware Fusion は、いや VMware Workstation もその他製品も、USBメモリからのブートを直接対応していない。起動可能なデバイスは仮想環境上で

HDD, 光学ドライブ, FD と認識されるものか、ネットワークブート(PXE)だけだ。

これは、VMware が実現している仮想ハードウェアが Intel 440BX という90年代中盤に存在したチップセットのエミュレーションをしていることが遠因だ。

当時は CD-ROM ブートですらできるとは限らなかった。( Windows NT4 や OS/2 Warp など当時のOSはフロッピーで起動、ドライバを読み込んでからインストール用のCDを認識したものだ。)
そもそも USBについては  Windows 98 の登場までほとんど利用できず、実質的な普及は98年末の iMac の爆発的な普及の後からだ。USB起動は考えられてなかったのは仕方のないことだ。

この時はあまり時間もなかったので手っ取り早い手段で解決した。

● Plop Boot Manager

Plop Boot Manager はその名の通りOSの起動を制御するブートマネージャで、HDD や CD-ROM, USB メモリからOSを読み込み、起動させることができる。

この記事を書いてる時点の最新は 5.0.14 。実は試したときは 5.0.13 だったがそう大きな差はない。上記のダウンロードページから zip ファイルをダウンロード、展開すると iso イメージが入っている。

この iso イメージを、仮想マシンの設定の CD/DVD にて選択、仮想マシンに割り当てる。

そして仮想マシンを起動する。

まだOSを入れていない、空の仮想マシンならそのまま PLoP Boot Manager が起動する

なお、VMware は HDD にOSが入ってるとそちらから優先して起動される。CD/DVD ドライブから起動したい場合は設定の「起動ディスク」から選択するか、仮想マシンの起動直後、VMware のロゴの BIOS初期化中にタイミング良くウィンドウをクリックしキーボードのフォーカスを入れて F2 を押すと表示される Phonix BIOS の Boot メニューから CD-ROM の優先順位を上げるといい。後者は VMware  製品共通だが、タイミングが難しいので Fusionなら前者を選ぶのが良いだろう。

ともあれ、PLoP Boot Manager が起動すると星の流れる校歌の右上に「FLOPPY」「CDROM」「USB」といったメニューが表示されている。おもむろにUSBメモリを挿し、仮想マシン側へ割り当てた後にこのメニューからUSBを選択すると、USBメモリ内のOSで起動される。

ただし、製品にもよるが USB メモリからの起動は決して速くない。

結局のところ、Ubuntu Linux のインストールメディアから仮想マシンを起動、dd コマンドで USBメモリの内容を頭から丸ごと仮想ハードディスクに丸々コピーし、そちらから起動するようにしてしまった。フロッピーや CD/DVD-ROM などと異なり、USB メモリのレイアウトはHDDと同様なので、MBRから丸ごと全部コピーしてやればだいたい動いてしまうのだ。

VMware Fusion で XP Mode は動くの?

VMware Fusion 上の Windows7 で XP Mode は動作するかどうか、というと動作する。
これは VMware の KB(ナレッジベース)で説明されている。

・Using Windows 7 Virtual PC XP Mode in Fusion
http://kb.vmware.com/kb/1017526

英文を読むと「ハードウェア仮想化機能が仮想マシン上にはないので XP Mode が動かない」とある。さらに読めば「MSからパッチが出てるので適用せよ」となっている。

以下は XP Mode のダウンロードページだが、持っている Windows7 のエディションと言語を選択すると 3つのコンポーネントがダウンロードできる。

「最初にインストール」とあるのは XP Mode の仮想マシン。VHD 形式のイメージと構成ファイルが用意されている。

「2番目にインストール」とあるのが Windows Virtual PC 。フリーで配布されている Virtual PC 2007 と違い、Windows7 専用のホスト型仮想化ソフトウェアで、エクスプローラとの統合されてて扱いやすい一方、同時に1つしか仮想マシンを実行できないという違いがある。細かい違いは MSのFAQを参照。

なお、この時点ではまだ Intel-VT や AMD-V といったハードウェア仮想化機能が CPU に搭載されている悲痛用がある。

元々はこの2つをダウンロード、実行すれば良かったのだが、Windows7 登場時は思いの外 ハードウェア仮想化に対応したCPUを持つデスクトップマシンが少なかった。

また、ハードウェア仮想化機能は BIOSでPC起動時に有効化する必要があるのだが、対応CPUを搭載していてもほとんどの場合BIOSでは無効化されており、BIOS設定を変更して有効化する必要がある。一部PCに至っては BIOSにこの設定がなく(削除されており)、ハードウェア仮想化機能を有効化することができない。

デフォルトで無効なのは、使わないのにハードウェア仮想化機能が有効化されていると、そこにウィルスが入り込みOSの下に潜みこむことができてしまうから、つまりはセキュリティ上の要請からなのだが、さすがにどうやっても有効化できない、ってのはやり過ぎた。

筆者は Windows7 の登場時、何度も「このパソコンは XP Mode が利用できるか」や「XP Mode が利用できるパソコンを見積もって欲しい」という依頼を受けたが、ハードウェア仮想化機能を有効化できるかはメーカに聞いても教えてくれない事があまりに多く閉口したことがある。

普段扱っているサーバ機器でメーカ窓口が Intel-VT を有効化できるかできないかを知らないなんてあり得ない話だが、当時のデスクトップ/ノートPC側のサポート窓口ではまだそのような情報は出回ってなかったようだ。

結局、オンラインでダウンロードできるマニュアルをさがし、BIOS設定項目を探したものなのだ。

閑話休題。

ともあれ、マイクロソフトが思った以上にハードウェア仮想化機能はデスクトップ環境に広まってなかった。そこで「ハードウェア仮想化機能がなくても Windows Virual PC を動かせるパッチ」( KB977206 )が提供された。

上記ページで、「三番目にインストール」とある Windows XP Mode update が、この KB977206 のパッチなのだ。

つまり、3つ目までインストールした時点で、ハードウェア仮想化機能がなくても Windows Virtual PC が使えるようになる。

VMware の KB に記載されているのはこの KB977206 を適用せよ、という事なのだ。

なお、Windows Virtual PC が起動する際に NICをプロミスキャスモードに設定する。

VMware Fusion で Windows7 を実行、その上で XP Mode を使おうと Windows Virtual PC を起動すると仮想NICをプロミスキャスモードに設定しようとして、Fusion が警告パネルを表示するだろう。

全くの余談だが vSphere (ESX/ESXi) 上の Windows7 で XP Mode を使おうとするとこの点が問題になる。ESX/ESXi の仮想スイッチ上にポートグループのデフォルト設定では、プロミスキャスモードの設定を許可していない。リモートデスクトップなどで Windows7 仮想マシンに接続しながら XP Mode を有効にするとプロミスキャスモードへの移行を拒否する余波でリモートデスクトップが切れてしまい、何が何だか分からなくなる。

対処法はプロミスキャスモードを許可したポートグループに仮想NICを接続すること、だ。

VMware Fusion の「言語固有のキー マッピングを有効にする」 について

某勉強会で話したことの転載。

VMware Fusion の環境設定にある 「言語固有のキー マッピングを有効にする」 について。

結論から言うと、日本人はまったく気にする必要がない。

VMware Fusion のマニュアルによると、以下の機能を持つ

入力メニューをサポートされるキーボード レイアウトに変更すると、追加のキー マッピングがキー マッピング リストに追加されます。現在、VMware Fusion はフランス語とドイツ語をサポートしています。この機能は、Mac OS X Server 仮想マシンでは使用できません。

「追加のキーマッピング」とはなんぞや?と思われるが、これはフランス語やドイツ語のキーボードにある追加キーが有効になる機能を意味する。

日本語のキーボードにある「かな」「英数」などについてはこのチェックの有無にかかわらず、日本語キーボードを繋いでいれば利用可能だ。

つまり、日本人が日本語環境や英語環境で VMware Fusion を利用、仮想マシンを実行する限りは何の意味も持たない。気にする必要はないのだ。

VMXNET3 を使用した Windows7/ Windows2008 仮想マシンをクローンするとNICの名前が変わってしまう

● 問題

vSphere 環境にて、VMXNET3 を利用した、ゲストOSとして Windows7 もしくは Windows Server 2008 R2 をインストールした仮想マシンのクローンを取ると、ゲストOS上のネットワークデバイスの前が「ローカルエリア接続」ではなく「ローカルエリア接続 2」など、後ろに数字が付加されてしまう。

● 原因

この件に関する VMware 社の KB は以下の通り。

"Deploying Windows 2008 R2 and Windows 7 templates with vmxnet3 renames the NIC as #2"

http://kb.vmware.com/kb/1020078

上記に書いてあるとおりなのだが、かいつまんで説明すると...

Windows7/2008R2 では、PCIスロット上のデバイスは PCIのスロットIDをもって識別される。このため、あるPCI デバイスを別のスロットに挿すと「新しいデバイス」と見なされ別の認識をされる一方、同じスロットに同じ種類のカードで別のものを挿しても「同じデバイス」と見なされる。

例えばNICの場合、同じNICを別のスロットに移すと別NICと見なされる一方、異なるMACアドレスを持つ別の同メーカのNICを同じスロットに挿すと「同じNIC」扱いされて前と同じ設定が適用される。

一方、PCI Express に接続されたデバイスの場合はデバイスのシリアル番号などを引っ張って唯一性を確認するだけだ。例えばNICならば MACアドレスで違いを確認する。MACアドレスが同じならどのスロットにあっても同じデバイス、MACアドレスが異なれば同じスロットでも違うデバイス、扱いになる。

ここまで聞くと正しいと言えば正しいのだが、問題は仮想マシンでクローンを行った場合。

仮想NICでも Intel EtherExpress 互換(e1000) や AMD PCnet32 互換(フレキシブル) は PCIバス接続と見なされている。なのでクローンされて、MACアドレスが変わってしまっても「同じNIC」と見なされ、ゲストOSである Windows のレジストリにあるクローン前のNICの設定がそのまま利用される。

一方、VMXNET3は PCI Express 上に繋がっていると見なされるので、クローンされてMACアドレスが異なると「違うデバイス」扱いになる。レジストリにはクローン前の元のNICの設定とは別の設定が作られる。クローン前の設定が「ローカルエリア接続」ならば、新しく作られた方は「ローカルエリア接続 2」などになってしまうわけだ。

しかも、クローン前のMACアドレスを持つNICは繋がれないのにレジストリに設定が残ってしまって「ローカルエリア接続」の名前を占めてしまうので、できあがった「ローカルエリア接続 2」を「ローカルエリア接続」に名前変更を試みても失敗する。

● 対応

要するに Windows の挙動の問題のため、Windows 側にパッチを当てるしかない。

パッチは以下のマイクロソフトのKB から入手可能

• SP1以前の場合 : http://support.microsoft.com/kb/2344941
• SP1およびそれ以降のSPを適用後の場合 :  http://support.microsoft.com/kb/2550978

それぞれのページの上の方に「View and request hotfix downloads」というリンクがあるのでこれをクリック、ダウンロードするパッチを選択、メールアドレスを記入、CAPTCHA を記入後、「リクエストを送信する」ボタンを押すと、パッチの入手先がメールで届く。

なお、パッチは x86, x64, ia64 でそれぞれ別物なので注意。普通は x86 と x64 が必要になるだろう。通常は現在実行しているアーキテクチャだけが表示されているので、「Show hotfixes for all platforms and languages」あるいは「すべての環境、言語用の修正プログラムを表示する」のリンクをクリックすると全部のパッチが見えるので、適切なチェックを入れるといい。

メールのリンクをクリックすると、自己解凍形式の EXE ファイルがダウンロードされる。

これを実行すると、拡張子 .msu のパッチが出てくるので、"クローン元になる仮想マシンの Windows" にこのパッチを適用する。

適用後にクローンを行うと、この問題は発生しなくなる。

● ワークアラウンド

なお、問題は VMXNET3 で起こるものなので、e1000 やフレックスを使っていれば問題は発生しない。

発生した場合も以下のサイトを参照にゴースト化してしまったクローン前のNICの設定情報をレジストリから削除してしまえば名前をもどす事が可能になる。

・ネットワーク アダプターに IP アドレスを設定する際のエラー メッセージ

http://support.microsoft.com/kb/269155/ja

・第22回 Installer Clean Upユーティリティはどこにある？ 仮想マシンIDって何？ ゴーストNICを削除するには？

・デバイスマネージャに表示されないネットワークアダプタを削除する方法

http://last-resort.seesaa.net/article/152702546.html