仮想ハードウェア:ホットアド

『仮想ハードウェア:ホットアド』についてです。
利用するのはサーバでしょ?と思うでしょうが、フルクローンの個人PCの展開も想定に入っている場合は、ホットアドは設定しておくほうが良いと思います。
現職の環境では、稀に『Access2013がメモリ不足で動かないからメモリ増やしてほしい』という依頼があり、この場合にホットアドがない場合は利用者が出勤していない時間=早朝か深夜にVDIをシャットダウンして対応する必要があります。
ですが、このホットアドを設定しておくことでVDI稼働中に行うことが出来るので
無駄なシフト対応を取らずに済むようになります。

現時点でvCenter5.xを新規導入する事はほぼないでしょうから
VMware関係は気にする必要はありませんが、Windows7ではメモリホットアドは
問題ないですがCPUのホットアドはEnterprize以上の制限があります。
RDSH等も考慮するのであればServerOSも対応をチェックすることをお勧めします。

Windows クライアント OS のホット アド メモリ機能と動的メモリについて
http://blogs.technet.com/b/askcorejp/archive/2014/06/10/windows-os.aspx
Windows Server 2008 R2 の異なるエディションにおけるホット アド メモリ仕様およびホット アド vCPU 仕様のサポート (2093996)
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2093996

Windows 8 または Windows Server 2012 仮想マシンでホット アドされた仮想 CPU を認識できない (2101857)
 http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2101857


以上よりVDIで利用するOSのバージョンとしては以下を推奨と勝手に言ってみます。

Windows7
 フルプロビジョニング:社内的にProfessionalとEnterprizeが混合で問題なければEnterprize以上推奨
 Composer利用:Professional以上
Windows8
 Profesional以上
Terminal Server型VDI:Windows2008 DC以上かWindows2012系

VDIの作り方について

結局9/10から9/15までHorizon View環境のアップデートに掛かり切りになり
そのまとめをVMUGデスクトップ仮想部会用に資料を作っていたので
ここしばらく放置になっていました、すいません。


さて、『VDIの作り方について』というタイトルにしましたが
単に作り方そのものについては、教科書でも見て頂ければ良いかと。
今回扱うのは、プロジェクトを進める上でVDIのテンプレートを作成方針について
触れたいと思います。
プロジェクトに時間があれば、構築作業のうちvCenterのセットアップが完了後に
構築したvCenter環境で行うことを推奨します。
プロジェクトの工期が短いプロジェクトでは、担当SEが事前にVMworkstation等の環境でテンプレートを作成し、インポートすることを提案してくる可能性がありますが
高い技術力があるSEではない限り、工期を2-3日程度遅らせてでもこの提案は断るべきです。これには仮想ハードウェアのバージョンの違いにより発生することが多く、インポート直後の状態で稼働させた際にvSphere上のコンソールで操作した際にデータ読み込みエラーでマウスカーソルがラグで飛ぶように移動する状態になるケースやVMDKファイルの転送時に破損したことで処理ラグが出るようになった事もありますので
そういった事象がどこに依存するか切り分ける自信がない場合は出来るだけvCenterが利用できるようになるまで待つことを推奨します。

ESXi/ESX hosts and compatible virtual machine hardware versions list (2007240)
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2007240

Virtual machine hardware versions (1003746)
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003746 


VMDK ファイル内の仮想 SCSI アダプタ タイプの調整 (2081674)
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2081674


以下、トラブルKnowledgeBase

仮想マシンの仮想ハードウェアをバージョン 7 にアップグレード後、停止コード 0x0000007B (起動デバイスにアクセスできない)が表示される (2083956)
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2083956

シンクライアントの設定#2

今日予定していた作業が繰り上げとなったため、今日はこんな時間です。

シンクライアントの設定で一つ忘れていたので追記しますと
Windows XP Embedded時代はCtrl+ALT+Delを押すとそのままリダイレクトできましたが、Windows Embedded 7になってからセキュリティシェルが異なる影響でCADを押すとシンクライアントがロックされてしまいシンクライアントのUserアカウントのパスワードを知らないユーザがこれをやってしまい、ログイン出来なくなりサポートコールをしてきますので、このロックさせない設定に関しても実施する必要があります。

また、スタートボタンのシャットダウンボタンからユーザのロックが出来るのでこちらも操作不可となるようにすることが望ましいです。私はログオフだけの状態にしています。

これらの設定は、シンクライアントのローカルグループポリシとレジストリで対応可能です。パラメータはググれば分かりますのでそのうち書くかもしれませんが、とりあえず省略させていただきます。

将来的なVDIについて考えて(妄想)してみる

 

 9/10(土)から実施していたHorizon View5.xの6.23化作業でESXアップデート以外見事に全ての工程でトラブって2徹+α状態だったので更新できませんでした。
そして今も思い出すだけの気力がないので、妄想だけしてみたいと思います。

まず1つ目、先日触れたNestedESXの使い道です。
まだNestedESX自体も公式サポートではありませんし、現時点ではVMware製品自体のテスト環境の構築しかないと思います。ですが、今後正式サポートされて性能がある程度見込めるようになった場合に1つの使い方があります。例えば、NSXの小規模環境構築です。ESX単位での課金もしくはVDI単位での課金で、vCenter跨ぎやDR(ディザスタリカバリ)などを考慮する場合等のある程度の規模が見込める場合に有用性が見込めますが、そうではない場合はネットワーク間セキュリティを切り捨てるかサーバFirewallに頼るかといった方向性になると思います。ですが、マイナンバ対応のように高セキュリティ環境を構築しなければならない場合に、仮想環境ではNSXを導入したいと考えるはずですが、中途半端にESXの台数がある場合やVDIの台数がある場合に費用面で折り合いがつけられないかと思います。
このような場面でNestedESXが正式サポートされてるようになれば、NestedESX上にVDIを作成すれば最低限の環境、最低限のライセンス費用で必要な高セキュリティ環境を構築できるようになるのではないでしょうか?また、Oracleのように異常なライセンス体系を強制してくるソフトウェアに関しても、メーカの同意がえられればクリアできる可能性があるのではないかと思います。

もう1点妄想を。こちらはVDIのOS:Windowsです。正直業務に追われているなかでWindows10の検証もしなければならないことが嫌になりました。何か良い方法はないか?と考えたところでもうサーバOSにVDIも切り替えても良いのではないかと思いました。
サーバOSをVDIで利用する際の問題点としては、1点『クライアントOSでしか稼働しないソフトウェアをどうするか?』この1点です。これをクリアする方法として、クラサバ系などの対処以外にもう一点、以前の記事を見た方は思い浮かぶと思いますがThinAppです。
ThinAppでは各バージョンごとに対応したOSが決められていますが、その範囲でなら32bitから64bit、クライアントOSからサーバOSにソフトウェアを移行させられます。またパフォーマンスチューニングの面でもそう難しくなく、コスト面でもデータセンタエディションで集約出来れば悪い選択ではないと思います。

アクセスありがとうございます。

9月から始めてVMware製品の中でもVDIのみというドM縛りなブログですが

10日で130アクセスになりました、ありがとうございます

実は会社でVDI増設用にFlexPodを追加するプロジェクトとDWH2セット同時システム更新とインフラ用件だけですが、XXシステムのリプレースと4つのプロジェクトを一人で同時進行中です。

こんな中でも趣味に走ってVDIはコンバージドインフラ、XXシステムはvSANでベンダに構築させようと躍起になっています。XXシステムはベンダに責任を持たせるために共通基盤以外で構築する方向性らしいのでvSANにさせましたが、VDIのコンバージドは意味があります。今年のユーザ会総会でVMware社が推奨するハイパーコンバージドだけが選択肢ではない事をお話出来ればよいと思っています。

Horizon View 5.xのみのトラブル集ート?

今日は会社のHorizonを5.xから6.x系へあげるためのvCenter更新作業を実施します。
7系には2段階アップするのも手間掛かりすぎるので、小数点以下のアップデートなしは運用上不安要素が大きいため計画からはずしました。

なんとなく5系サヨナラ企画的に5系だからあったトラブルを書いてみます。

1.構築中でまだVDIが200程度しかない時期にdvShiledEndPointの某T社製品のバグ
  が見つかり問い合わせをしたところ、ESX5.1から5.1Up2に更新してくださいと
  言われESX15台、セットをせっせこアップデートした
2.キヨスク端末でView Clientをコマンドラインで自動接続させていたが
  View Clientのバグで接続先プールが2つあるとコマンドラインでの接続が
  他のプールになってしまう。(Horizon Client4.0.1では改善)

3.Horizon Clientで利用するUSBリダイレクションのドライバC:\Program Files (x86)\Common Files\VMware\USBのパスが通っていない。(Horizon Client4.0.1では改善)

4.SSOサービスのパスワードが切れてしまい、vCenterにvSphereクライアント接続中でShadowingの画面利用中に切断され、二度とvCenterにつながらなくなった。
SSOのパスワード期限切れなんて初見でわからないメッセージやめてほしいですよね。原因がわかってから見ると下のほうのメッセージで[LDAP]関係だというのがようやくわかります。 SSOに関しては全員利用していますが認知度が低いです。これはログインにActive Directoryのアカウントを利用するケースが多いことと、vSphere ClientではSSOの項目がなくvSphere Web ClientでもSSOアカウントでログインしないと項目がDisabledになっていることに起因します。

f:id:rujihara:20160910201928p:plain

Composerを利用しないフルクローンVDIの共有PCには注意が必要

Horizonは別投稿でも書いた通りComposerを利用することが前提で設計されてます。
この影響でフルクローンVDIの流動プール(共有PC)では本来使えなければならない
1つの機能が利用できません。

それはView Administratorの流動プールの設定項目の一つで
帰宅時シャットダウン運用をする場合に、ブートストーム対策として
N台のVDIを先に電源を入れられるようにする項目です。

この設定があることで、流動プールでは複数人同時にログインリクエストしても
処理できるようにする機能なのですが、もう一つ意味がありますそれはこの設定で2台以上に設定しておくと、VDI起動中に何らかのエラーやView Agentサービスが起動しきらずポートが解放されないなどの症状(ZombieVM)が発生した場合でも予備があるので
ユーザのログインが継続的に処理されるようになります。

なぜこれを無効にしたのかは私にはわかりません。

とはいえ、このような自体が私の環境では発生したので
VMware社のサポートに鬼神の如く電凸しまして以下のKBを作らせました。
その際のサポートからの回答です。

 本件についてエンジニアリング部門で検討した結果、Zombie VM が Spare VM とし
てカウントされて
 VM を割り当てられなくなる動作に問題があるとの判断に至りました。

 Spare VMが無い状況では、既存の仮想デスクトップを割り当てようとする動作は仕様となるため
 コード上の修正ではなく、Zombie VM の発生を無くす設定を回避策として
 正式な KB という形で公開させて頂く事となりました。

 Unable to assign desktop even when unassigned desktops in manual pool are
present (2111621)
 http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=d
isplayKC&externalId=2111621

ざっくりと纏めますが、Connection ServerにADSI.editでLDAP接続して
プールの設定を1からNにする、という内容です。

個人的にはVDIは結局パソコンなのだから、エラーで起動失敗することを
想定して起動直後にZombieVMになったと思われたら強制再起動する機能を
Connection Serverが持つべきだと思います。