ラベル VMwareView の投稿を表示しています。 すべての投稿を表示
ラベル VMwareView の投稿を表示しています。 すべての投稿を表示

2015/04/10

Windows7 でシステムパーティションを削除する

32bit のWindows7 を通常の手順でインストールすると、100MBのパーティションが起動ディスクの先頭に用意される。

このパーティションはシステムパーティションと呼ばれており、マイクロソフトのページにその概要が記載されている。
UNIX的な感覚からするとちょっと違和感を感じるかも知れないが、起動時にのみ参照されるこのパーティションが「システムパーティション」であり、いわゆる C:ドライブは「ブートパーティション」と呼ばれている。

このパーティションにはブートローダやその設定などが格納されており、システム保護の観点からドライブ名もつけられず、GUIからは削除できないようになっている。また、BitLocker を使う際にはそのためのモジュールもここに格納される。BitLocker を使う場合、このシステムパーティションの存在は必須と言える。

さて、仮想環境上ではTPMが使えない兼ね合いから BitLocker を使うのは現実的ではない。
(使えなくはない。たとえばこのページを参照。)
Fusion や Workstation で1台2台をセットアップするなら別にどうでもいいが、Horizon View などで何十台何百台と Windows が実行される場合、100MBとはいえ決して馬鹿にできない浪費になるだろう。

では、このシステムパーティションなしのインストールができるのか?というと、これは可能だ。これもまた、マイクロソフトのページに記載されている。
手順としては以下の通り

  1. Windows7 のメディアで起動􏰀
  2. 最初の画面で SHIFT-F10 を押し、コマンドプロンプトを表示􏰀
  3. diskpart コマンドを起動、1パーティションでパーティションテーブルを作成
  4. コマンドラインを終了􏰀
  5. インストール時に作成したパーティションを指定􏰀


Windows7 のインストーラの画面で SHIFT-F10 を押すと、下図のようにコマンドプロンプトが表示される。

ここで、diskpart コマンドを実行し、先にパーティションを作ってしまうのだ。


その後、exit コマンドを実行し、インストーラに戻り、インストールを継続する。
通常の新規ディスクの場合、インストール先の選択が「ディスク0 未割り当て領域」となっているのだが、すでにパーティションが作成されているのでその代わりに「ディスク0 パーティション1」が選択しに現れる。

あとはインストールを続行する。
結果、下図のように全体で1ドライブとなる。

ここで作成されたシステムパーティションなしの 32bit Windows7 をHorizon View の ViewComposer でリンククローンで展開したが、全く問題なく利用できている。

シンディスクの場合、システムパーティションのほとんどは未使用のため実ディスク領域は割り当てられない、このため、別にあってもなくてもディスク消費に大差はない。しかしシックディスクでフルクローンの場合は、これで1仮想マシンごと100MBが回収できる。決して馬鹿にできない差異になるだろう。

● 64bit Windows7 ではどうなるか?

なお、64bit Windows7 の場合、以下のようになる。


NTFSのシステムパーティションではなく、FAT32の「UEFIシステムパーティション(ESP: EFI System Pertition)」になる。
これは UEFI で定義された領域で、(U)EFI を使用するコンピュータでは必ず作成される。
その代わりに Windowsによるシステムパーティションは作成されない。UEFI システムパーティションがその代わりとなり、BitLocker のモジュールなどが導入されるためだ。


UEFI 周りについては、また別途説明する。


2015/03/09

Horizon View Connection Server で「サービスが正常に機能していません」が表示される。

Horizon View の Connection Server を複数立てたとき、ダッシュボードの接続サーバに「サービスが正常に機能していません」というメッセージが表示されることがある。
なお、英文だと「The service is not working properly. 」の模様。

「サービスが正常に機能していません」のエラーメッセージ
そう言われましても...、って気分になる

KBを探してみても vCenterServer にこのメッセージが出る場合の記載ぐらいで、ログもそれらしいエラーがなく困っていたが、ようやく原因を特定できた。

二つの ConnectionServer で時刻同期がうまくいっておらず、時間が1分程度ないしそれ以上ずれていると、このメッセージが表示される。

一方が ServerCore で構成していたのだが、どっかのタイミングで Windows Time が起動されてなかったらしく、時々ずれがこの時間を超えて、なぜか赤くなる、を繰り返していたのだ。

わかってしまえば対処は簡単で、時刻同期がちゃんと実行されるようにするだけだ。

今回実施したのは、以下の通り
w32tm register
net start "Windows Time"
w32tm /config /update /syncfromflags:DOMHIER
w32tm /resync /rediscover
最初の行でサービスとして登録、二行目で起動する。
起動しないとそれ以降のコマンドが打てないので、とりあえず動かしておくのだ。

3行目でドメインコントローラから時刻をとるように設定を強制、4行目で同期を強制している。( どうも /redisover をつけないと同期先を古い設定のまま見に行くことがあるので注意。)

1,2 分程度のずれなのでこれで済んだ。
大きくずれている場合の同期方法については適当に調べてほしい。

なお、同期状況の確認は
w32tm /monitor
を実行するのが手っ取り早く、時間は
echo %time%
としたほうが、time コマンドより楽だ。
time コマンドだと、そのまま実行すると時刻の設定をしようとし、/T をつけると秒以下を表示してくれないため。

いろいろ探しても該当事例を見つけられなかったので、念のために記録しておく。















2013/04/03

ViewClient for Mac の USBリダイレクトを停止させる

VMware ViewClient for Mac 1.7 から Mac でもUSBリダイレクト機能が利用できるようになった。ローカルのMacに接続したUSBデバイスを、リモートのデスクトップ仮想マシンに認識させ、利用することができるようになったのだ。

これは便利なのだが、ただ困ったことに 32111/tcp が閉じられているなど諸々の理由でUSBリダイレクションがうまくいかない場合、下記のエラーメッセージが頻発して操作性が悪くなる。

USBリダイレクトに失敗するとこのメッセージが何度も何度も出る

Windows 版と異なり、Mac 版の USBリダイレクションはそのままでは有効にならず、一度メニューからサービスを開始させる必要がある。


USBリダイレクトを使うには、まず「リモートデスクトップUSBサービス」を開始させる必要がある
これはデフォルトでは有効になって板に
開始させようとすると上記警告と、管理権限のパスワード入力が求められる
必要なのは最初の一度だけで、有効にしたら最後 次回以降の起動では必ず有効になる

ところが、標準メニューではこれを有効にすることはできても向こうに戻すことができない。これは不便だ。

なので、調べてみた。

この「リモートデスクトップUSBサービス」だが、二つの要素でできている。

まずはユーザランド側で、「vmware-usbarbitrator」と「vmware-view-usbd」という二つのプロセスが起動する。vmware-usbarbitrator は VMware Fusion にも搭載されているUSBの調停プロセスで、おそらく OS X からUSBデバイスを引き取るのに使われているのであろう。

もう一つはカーネル側で、「vmioplug.kext」という KEXT (カーネル拡張) 。これが USBの通信を引っ張り出して、usbarbitrator などに渡しているものと思われる。

そして、インストール(dmg からコピー)直後の ViewClient ではこの vmioplug.kext がコピーしたユーザの権限になっている。対して「リモートデスクトップUSBサービスを開始」を実行した後はこれが root:wheel に権限が書き換えられている。

セキュリティのため、OS X では root:wheel 、権限が 755 な kext 以外をカーネルにロードできないようになっている。カーネルは最高特権で動作するので、ここに一般ユーザで書けてしまうファイルを書き込むのは極めて危険であり、同等権限を要求することで安全性を揚げているのだ。( root:wheel のファイルを用意できる時点でそのシステムは落とされているから、それ以上厳しくしても意味がない )

なのでこの vmioplug.kext の権限を root:wheel でなくしてしまう、ロードできないようにすることで元に戻す、「リモートデスクトップUSBサービスを開始」を選択する前の状態に戻すことができる。

とりあえずはこれでしのげた。

2012/04/14

VMware Tools のアップデート追記

昨日公開した VMware Tools のアップデート情報だが、間の悪いことにこれに関係するもう一つ新しいアドバイザリ VMSA-2012-0007 が出ていたので追記したい。

これは、Windows 向けの VMware Tools のフォルダの権限付けにミスがあり、これを突くことでゲストOS上の特権を奪えるというものだ。

上記のアドバイザリを参照して頂ければ分かるが、この脆弱性をもつ製品は非常に幅が広い。

  • VMware Workstation 8.0.1 とそれ以前
  • VMware Player 4.0.1 とそれ以前
  • VMware Fusion なら 4.1.1 とそれ以前
  • ESX/ESXi なら 3.5, 4.x, 5.0 

まぁ、要するにこの脆弱性への対応パッチやアップデートを含まれてない製品全て、ということになる。ホスト製品の場合はそれぞれ後継製品に、ESX/ESXi の場合は該当パッチを適用することで内蔵される VMware Tools に更新されるので、アップデートやパッチ適用後、Windows をゲストOSとする仮想マシン全ての VMware Tools をアップデートする必要がある。手間がかかるが必ず実施した方が良い。

なお、VMware Fusion 4.1.2 をダウンロード、その中の VMwareTools を確認したところ、バージョンは 8.8.3 (8.8.3.12575)、ビルド番号は 683185 のようだ。

2012/04/13

VMware Tools のアップデート

少々旧聞だが、VMware 製品のセキュリティアップデートを通知する Security Advisories & Certifications に掲載された VMSA-2012-0004, VMSA-2012-0005 にて 「Windows版VMwareTools に含まれるディスプレイドライバ(XPDM, WDDM双方)にてメモリ管理の脆弱性があり仮想マシン内の Windows で特権を奪われる可能性がある」旨が告知されている。

対策としてはパッチ適用(ESXi500-201112402-BG など)になるが、これは ESX/ESXi に含まれる VMwareTools のイメージをアップデートするだけだ。具体的にこのパッチでのアップデート事項は KB 2007672 を参照して欲しい。

すぐに気がつかれたかと思うが、ただパッチを当てるだけでは問題は解決しない。各仮想マシンの VMware Tools をアップデートする必要がある。
逆に言えば、パッチを当てなくても VMware Tools さえ最新版を入手、アップデートすればこの問題については回避できる。

最新版の VMware Tools (Windows版)は以下ページから入手できる。


x86(32bit)と x64(64bit)があるのでそれぞれ入手して欲しい。


また、VMSA-2012-0005 では VMware Workstation 等ホスト製品については問題がないとされているが、これはその環境で仮想マシンを動かしている場合に限られる。

VMware Workstation 7.1.5 より前、Player 3.1.5 より前、VMware Fusion 4 より前の各製品で作成、当時の VMware Tools をインストールしている仮想マシンを ESX/ESXi 環境に持って行った場合、VMware Tools のバージョンが古くてやはり問題が発生する。
もちろん、そもそも仮想マシンを ESX/ESXi 環境に転送しないなら問題はない。

対策としては、VMware Workstation なら 8へアップグレードする、7.x なら 7.1.5 にする、Player なら 3.1.5 をダウンロードしてアップデートする、VMware Fusion なら 4 を購入し、その上で VMware Tools をアップデートしておくといい。
とはいえ、仮想化製品をそうもアップデートできない、購入できない場合もあるだろう。その場合はやはり上記のページから VMware Tools をダウンロード、アップデートしておいた方が安全だ。


なお、VMSA-2012-0004 では同じ問題を記述しているが、こちらは VMware View に対するアドバイザリで、対策として「View 5.0 か 4.6.1 へアップグレード後、各仮想マシンごとの ViewAgent をアップデートする」という手順が記載されている。

脆弱性は VMware Tools 内のディスプレイドライバなので奇妙な話だが、View を使ってる場合は ViewAgent もあわせてアップデートしておいた方がいいだろう。


2012/03/21

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側に設定したキー配列がそのまま使われるのではないかと思われる。
混乱を防ぐためにも配列を統一しておいた方がいいだろう。


2012/03/18

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 にしてしまうというのも解法としてはアリだろう。