PowerCLIをもう少し使いこなしたい
明けましておめでとうございます。
12月はDWHのストレージ入れ替えで担当業者の大手SIerのPL,PMを1ヶ月で2回もしかも部長込みでクビにせざるを得ない状況で対応していたため、月末は書く余裕がありませんでした。DWHの件はやっとハード構成が完了し今月データ移行テストが開始されました。
書く事が余りありませんが、共有VDIのプールでの問題でプール内のVDIがログインしたままになっているものも含めて使い切られている状態であることを利用部署の部門長等が確認出来る仕組みがあるほうが望ましいです。もちろん自力でVDIの再起動まで実施してくれれば何の問題もありませんが、そこまでしなくても最低限『誰々がこのVDIにつないだままにしているのを強制ログオフしてほしい』という形でリクエストしてもらえるだけでもシステム部門としては運用が楽になる事請け合いです。
Viewを導入する前にWindows XPのVDIをCitrix XenDesktop4とvCenter＋RDPで利用していたのですが、その際に共有PCの利用状況をチェックし結果をHTML化するスクリプトを作成していました。その際にはPowerCLIなどといった便利ツールはありませんでしたので、管理サーバから共有PCのリストに対してPINGを実行して稼動確認を行ったうえで、起動している場合はpsexecでVDIに接続しqwinstaコマンドでRDP接続しているユーザの情報を取得する方法で実装していましたが、その際には100台程度で１周させるのに１０分程度掛かっていました。
それを考慮するとConnectionServerでPowerCLIの以下のコマンドを実行することでシャットダウン以外のVDIのステータスを短時間で取得できます。
PowerCLIは経験値が足りないので、VBScriptと合わせれば以前作成したような各プールごとの利用状況を取得しつつ、ADに対してLDAPでログイン中のユーザIDの詳細情報と合わせた利用状況をリストアップするスクリプトを作成できるでしょう。残念ながら、今VcenterのDBから個人割り当てのVDIの情報と移動プロファイルとフォルダリダイレクト対象者を処理するスクリプトを優先して作成する必要があるため、このスクリプト作成は当面先になると思います。
> Get-RemoteSession -pool_id 『プール名』
session : 160
Username : ドメインFQDN\ユーザID
pool_id : tcv-pl013
startTime : Thu Jan 05 08:36:43 JST 2017
session_id : ドメインFQDN\ユーザID(cn=s-1-5-21-2620938040-1617289647-3374191743-4885,cn=foreignsecurityprincipals,dc=vdi,dc=vmware ,dc=int)/1@cn=9b09f52d-7a3c-4f8a-abcf-c1176e1cbc10,ou=servers,dc=vdi,dc=vmware,dc=int.cn=tcv-pl013,ou=server g roups,dc=vdi,dc=vmware,dc=int:PCOIP:0:DESKTOP DNSName : vishare-c001.hoge.Local
duration : 23 minutes
lastSessionTicks : -4402145
state : CONNECTED protocol : PCOIP
想定しないことをしてみた
これまでシックプロビジョニングな個人割り当てのVDIがメインだった環境にComposerと移動プロファイルとフォルダリダイレクトを導入するためにFlexPodをVDI環境として増設しました。さて、うちのユーザだけでなく、システムメンバに対しても想定しない事を想定しなければならないためComposerで利用するVDIのイメージに対してこんなことを実施してみました。
個人割り当てのVDIではsysprepしてからテンプレートに変換し、そのテンプレを使ってデプロイするという手順だったので、同じくテンプレとしてスナップショットを取るVDIにsysprepしてからスナップショットを取って、そのスナップショットを参照するようにプールに設定してみました。sysprepによるハード初期化時にエラーが出てWindowsが起動しませんでした。
手順書にスナップとる前にsysprepするなよ？！するなよ？！と書かねば。。。orz
VDIテンプレートの設定はADのグループポリシで
やるのは推奨できません。甘い期待を持つのはやめましょう。
※2016/12/19追記 時間をおいて読み直した結果、修正コメントを追記することに致しました。申し訳ありません。
ADでの設定は必要ですが、念には念を入れて出来るだけローカルポリシやレジストリを編集した状態で、必要であればADのGPOを適用しましょう。という意味です。
一方でSIの方が、ADのGPOで設定すればOKですというのは鵜呑みにしないようにと警告することを目的としていました。
システムインテグレータの方達が『VDIの設定はADのグループポリシで』と言っていたとしても鵜呑みにしてはいけません、なぜなら彼らは『構築の仕方は知っていても運用は知らないから』です。
ゼロから作ったクリーンな環境で正しく構築されていれば、誰がやっても正常に動きますが、実際にはドメコンのメモリ不足等々で正常に動かなかったり、PCを強制電源OFFなどでOS破損していて適用されない等は当たり前にあります。我々が想定しなければならない環境は、『クリーンで正しい環境』ではなく、『必ずしも正常稼働するとは限らない環境で、必ず同じ結果を出す』事です。.そうすることで一人社内インフラエンジニアの私は自分の作った環境で発生するトラブルで眠れない日々を眠れる日々に変えています。
自身の常識になっている事が世の中的にそうではない事を実感する事が多いのでこのような書き出しにしました。
前職のまだXP全盛時代に金融機関のActive Directory管理をしていたなかで、PCに当てる予定のポリシが当たらないというエスカレーションを受けて、温厚なチームメイトがコンチクショイ！と言いながら対応していた情景がまだ脳裏に残っています。つまり、PCが調子悪かろうとドメコンが調子悪かろうとそれらの通信が調子悪かろうと適用されない時は適用されない、それがActive Directoryのグループポリシだと思っています。
View5.x系環境でWindows 7をリリースした後に、想定よりも早く共有PCのプロファイルが溜まりすぎてVDIのCドライブが一杯になり、利用できなくなるケースがありました。一方で個人利用のPCでは休職や長期出張でPCを利用しない人が稀にいるため、GPOのWMIフィルタで分別してもよかったのですが、面倒だったので急きょ共有PCの一台にローカルポリシーでプロファイルを一週間で消すように追加設定を入れて、ローカルポリシーのファイルをPSEXECでコピー配布して対応したことがありますが、これも必ずしも適用されない場合があります。
こういった事を経験しているとVDIで必須となるポリシーだけでなく、既存で利用しているポリシがあればVDIテンプレートに組み込んでおくほうがスタートラインをそろえることが出来るので環境としては望ましいと言えるでしょう。
ローカルポリシはグループポリシで上書き出来ますので、変更が必要な場合はグループポリシで上書きするようにするほうが負担軽減となるでしょう。
vSphere上で起動直後に画面が真っ黒のままで開けない#2
前回はVMwareのKBに従いポリシーをいじる操作を行って、起動時・再起動時のコンソール画面が真っ黒で最悪通信エラーが表示されることに対する対応をしましたがもう一手対応しました。KBを見ると『WSUSサーバとの疎通が…』とありますのでWSUSサーバのセッションリセット等を考慮しサーバの再起動を実施したところポリシーを変更せずともコンソール画面の状態が改善するようになりました。
っ[とりあえず再起動]
vSphere上で起動直後に画面が真っ黒のままで開けない
いまさらですが、ここを参考にして設定したけどうまくいかんわー！とか2次災害起こしたやんけー！とかそういうのは受け付けません。あくまで自己責任でお願いします。
さて本題の『vSphere上で起動直後に画面が真っ黒のままで開けない』ですが、環境によってはvSphere上でゲストOSを再起動したり、電源をONした直後に画面が真っ黒のまま繋がらない状態になって開きなおさなければ表示されない症状が出るかと思います。私もISOイメージマウントしたいのに操作できんやんけー！とイライラすることがままありました。
この症状は以下のKBで改善する場合がありますので試してみてください。
仮想マシンのリモート コンソール画面の表示に最大 1 分かかる (2058959)
見落としていました。。。。
View5.xでもvSphere Web Clientの操作性が悪いのでvSphere Clientを利用していてあげたあともそのままだったツケを払わさせられました。とはいえ、9月に設置以降にDWHシステムのリプレースが二件あり、どちらも担当SEが(以下省略)で片方はデータ移行方式すらこちらから詳細な指示を出す羽目になったのですが、これらのせいでViewの異常対応は構築を頼んだ業者に任せっきりになって解決になかなか至りませんでした。先に言っておきますが、社内SEの本業はトラブルを楽しんだりプログラムを解析して改造することだとは思っていません、あくまで会社の要望に従い導入し管理運用することで自分に何かあってもシステム運用を誰であっても継続できるようにすることだと思っています。ですのでBCP的に影響のない、もしくは少ない増築作業のトラブルは優先度を下げているだけです。
話を戻しますが、何が起きていたかというとView6.2.3にアップデート後に新規クラスタを作りESXを追加したのですが、DRSのプロセスでsdrsinjector.34と言うものがあるのですがこれが数分置きにCPU利用率3200％(コア数32だから)wwwもう笑うしかありませんでした。これではユーザに提供出来ないので、まずはSAS回りを疑いVMのサポセンに問い合わせたところVMのサイトからISOを落としたものだったらしいのですがサポート対象外のバージョンですと言われCisco問い合わせて登録に関する調整をしてもらいつつ調査をしたところ新しいドライバーが含まれていないISOだったらしく更新を頼んだのですが治らず( ノД`)…
やっとVMのサポセンが対応してくれるようになったところで『vSphere Clientで表示されないパラメータの(データストアの「I/O統計収集の無効化」)』と分かりとりあえず無効にしました。無駄に負荷を上げるプロセスを勝手に有効にしないで欲しいです、VMさん。正直今回の件はVMのセールスSEの方にも動いていただきましたがCisco社のVMware社への登録漏れやその程度でサポートしないと言い切られるのはユーザとしては非常に困りものです。
