2015年4月28日火曜日

vCenter Serverにドメインアカウントでログイン出来ない

vSphere Web ClientよりvCenter Serverにログインすると"認証サーバが予期しないエラーを返しました"と表示されてログイン出来なくなってしまいました。

表示されたメッセージでKBを検索すると見事にヒットしました。
# どうもvCenter Server 5.1特有の問題のようです。

vCenter Server へのログインまたは Single Sign-On が Active Directory ドメインのすべてのユーザーについてエラーで失敗する
http://kb.vmware.com/kb/2100430

KBには、Active Directoryのいずれかのサービスがダウンしている時に発生するとの記載があり、サービス稼働状況を確認してみましたが、特に問題はありませんでした。

対処方法として、正常に機能していないアイデンティティソースを削除するとの記載もあったので、こちらも試そうとしたところ、、最初の手順で躓きました。。

SSO 管理者として vSphere Web Client にログインします。
これは、デフォルトでは admin@system-Domain です。

・・・ん? admin@system-Domain?

たしかにWindows版のvCenter Serverを構築した時にはインストーラでパスワードを設定した記憶があるのですが、今回はVirtual Appliance版で構成していたこともあり、パスワードが分からずログイン出来ません。。
# 覚えていないだけかもしれませんが。。

色々調べたところ、Virtual Appliance版には「root@localos」というアカウントが存在し、こちらで同様にvSphere Web Clientにログイン出来るようです。

# ドキュメントにしっかり書いてありました。。

VMware vCenter 仮想アプライアンスの vCenter Single Sign On モードの構成
http://pubs.vmware.com/vsphere-51/index.jsp#com.vmware.vsphere.vcenterhost.doc/GUID-689AC3F1-6654-4EE2-A146-663BD157FDC2.html

【抜粋】
このユーザーは Single Sign On 管理者ユーザーです (通常、Windows で実行される Single Sign On インスタンスの場合は admin@System-Domain、別の vCenter Server アプライアンスで実行される Single Sign On インスタンスの場合は root@localos)。

「root@localos」アカウントでログインしてみたところ、無時にログイン出来ました。

vSphere Web Cientにログイン出来たので、後はKBの対処法に沿ってアイデンティティソースを修正すればエラーを解消出来そうです。
# 少し長くなってしまいましたので、、実際の対処法にご興味のある方は続きをどうぞ。

2015年4月27日月曜日

ESXiにおけるTPSのデフォルト無効化

ESXiにおける透過的なページ共有 (TPS) によってAES暗号キーの決定に用いられるメモリタイミングの計測が可能であるとの学術研究を受けて、特定のESXi Updateよりデフォルトで仮想マシン間のTPSが行われないように変更されるようです。

【参考】セキュリティの考慮事項および仮想マシン間透過的なページ共有の禁止
http://kb.vmware.com/kb/2100628

TPSがデフォルトで無効となるvSphereバージョンならびにパッチレベルは以下の通り。
ESXi 5.0 パッチ ESXi500-201412401-BG 2014年12月4日
ESXi 5.1 パッチ ESXi510-201410401-BG 2014年10月30日
ESXi 5.5 パッチ ESXi550-201410401-BG 2014年10月16日
ESXi 6.0 2015年3月12日

Windows Vista以降、ラージページが採用され、TPSの効果はあまり期待出来ないと言われていますが、VDIなどのように同じOSやアプリケーションがたくさん集約されるような環境では活用出来た方がよいということで、有効にする方法や実態について確認してみました。

ご興味のある方は続きをどうぞ。

2015年4月21日火曜日

Workspace PortalでThinAppのネットワーク共有設定に失敗する

Workspace Portalを再構築したところ、ThinAppのネットワーク共有設定に手こずったので、メモ。

ThinAppパッケージの格納先として、DFS-Rで組んだファイルサーバーを用意したのですが、ネットワーク共有設定が何度やってもエラーとなってしまいます。

RepoUpdateRegistry() failed with error: ERROR_INVALID_DATA

RepoUpdateRegistry() failed with error115

設定情報はこんな感じです。

今回はネットワーク共有にDFSを利用しているために、"DFS共有およびHttpDownloadモードの展開に必要"にチェックを入れて、その下の共有のユーザー、共有のパスワードを設定していますが、どうもここで引っかかっていたようです。

ふと思い立って、共有のユーザーをUPN(ユーザー名@ドメイン名)で指定したところ、さらっと設定完了しました。

今回はアクセス方法やHttpDownloadモードの詳細には触れていませんが、HttpDownloadモードはドメインに参加していないPCでもWorkspaceからThinAppアプリを利用させることが出来る便利な機能です。HttpDownloadモードを構成する場合でもThinAppリポジトリへのアクセス方法はアカウントベースで構成する必要があるので、同じ問題に遭遇かもしれません。

アクセス方法やHttpDownloadモードについては以下をご参考下さい。

ThinApp パッケージおよびネットワーク共有リポジトリのための Workspace の要件
http://pubs.vmware.com/workspace-portal-21/index.jsp#com.vmware.wsp-resources_21/GUID-8AF678D8-AD07-4DB0-9659-1112E270DE3A.html

2015年4月14日火曜日

Composer通常ディスクのサイズ拡張方法

前回のディスポーザブルディスクに続き、Composer通常ディスクについても確認する機会がありましたので、メモも兼ねて紹介しておきます。

View Composerを使用してリンククローンで専用プールを構成する場合に、ユーザーデータを格納するためのComposer通常ディスクを構成出来ます。

Composer通常ディスクを構成することで、ユーザープロファイルがComposer通常ディスクにリダイレクトされ、ベースイメージを更新してもユーザーデータを維持出来ます。

残念ながらComposer通常ディスクには、ユーザー固有のアプリケーションまで含めることは出来ません。そんな時には、AppVolumesのWritableVolumeが有効です。
# こちらもいずれ紹介したいと思います!

リンククローンで専用プールを選択すると、Composer通常ディスクはデフォルトで有効になっており、サイズは2GBに設定されています。
# Composer通常ディスクのサイズはプールで一意の設定になっており、プールを利用するユーザーすべてで共通の設定となります。

そのため、基本的には全ユーザーの要求を満たすサイズで設定することになりますが、特定のユーザーだけがデータを格納し過ぎて、ディスクが一杯になってしまった、、なんということも少なくないのかなと思います。

デフォルトの2GBだと少し足りない気がしますので、Composer通常ディスクを構成される場合にはサイズ設計には注意しましょう。(笑

と言っても、なってしまったものは仕方がありませんので、Composer通常ディスクを拡張する方法を検討・試してみましたので、ご参考までに紹介しておきます。

ご興味のある方は続きをどうぞ。

2015年4月10日金曜日

ディスポーザブルディスクのリセット

Viewのディスポーザブルディスクについて調べる機会がありましたので、メモも兼ねて投稿。

View Composerを使用してリンククローンを構成する場合に、ディスポーザブルディスクという特殊なディスクを構成出来ます。

ディスポーザブルディスクは、ページングファイルなどの一時的なファイルを別ディスクにリダイレクトすることで差分ディスクの拡張を抑え、ストレージの消費量を削減出来る機能です。

簡単なイメージに描いてみるとこんな感じです。

リンククローンでプールを構成する場合、専用/流動問わずデフォルトで有効になっています。

ディスポーザブルディスクは、仮想マシンがパワーオフされた際にリセットされるのですが、この"パワーオフ"に少し語弊があり、View ClientvSphere Clientで仮想デスクトップにログインし、パワーオフ(シャットダウン)した場合には、リセットされません

View接続サーバーがパワーオフした時のみリセットされます。
# いわゆる更新(Refresh)/再構成(Recompose)を行った場合。

実際にリフレッシュされる/されないを確認してみましたので、ご興味のある方はどうぞ。