vMotionが掛からない
11月から毎月3-5日程度の出張と深夜メンテの繰り返しで正直余裕が全くありませんでした。
何でしょうね、11月は台風22号の最中に宮崎、長崎と出張して宮崎で飛行機欠航＆JRもNG、しょうがなく長距離バスに乗ろうとしたら目の前で行ってしまって、乗り継ぎ便にしたら乗り継ぎ場の4-5キロ手前で事故渋滞で予定便に乗り継げず、結局8時間程度移動に掛かったりと言いたい事はチョモランマより高くあるような出張が続いていました。
さて、本題。
先日Horzion6.2.3環境でVDIが起動しない症状が発生しました。
※この先の操作は、vCenterの設計を考慮すると問題はないはずですが
必ずしも解決を保障しませんし、2次災害に繋がっても責任は持ちかねます。
必ず自己責任で実施してください。
IPMIのログが溜まるせいで、ESXが正常に動作しなくなるというのが主原因で
再起動が必要になります。
前回は、メンテナンスモードに入れて再起動できましたが、今回はメンテナンスモードに入れようとしても、入らないという状況でした。
サポセンに問い合わせはしたものの、もう少し詳細調査した結果、VDIの電源ON状態ではvMotionが掛からない、またシャットダウン後も同じくvMotionが掛からないという状態でした。
このため、シャットダウンしたVDIをvSphereからインベントリから削除(ディスクから削除をしないように！）で障害の発生したESXから削除し、データストア上でvmxファイルを右クリックで再登録してVDIの電源をONする事で復旧させられました。
また、今回の症状でvDSとVDIとの接続情報に不整合が発生したようで50台程度のVDIのvNIC付け直しが必要になりました。vDSのVLAN変更では改善せず、vNIC自体を付け直さないと接続が回復しませんでした。
更に、今回の件の影響なのかわかりかねますが、DeepsecurityのManagerサーバがvNIC付け直しを行ったVDIを認識させられず、結局DeepSecurityのmanagerとRelayの再起動が必要になりました。
今年で5年目に入りますが、VDI1000台(ESX18台、平均実稼動5-600台)、DeepSecuirty、3年目でHorzionを6.2.3にアップグレードし、4年目よりLinkCloneを利用し始めましたが、DBのクリーンナップとShurinkを定期的に実施できないのであれば、VDI環境用のDBサーバは1台で運用せず、vCenter用、ConnectionServerのイベント、DeepSecurityと3つに分けないとキューが溜まって上記の症状が発生するように見受けられます。
DBを分けるか、定期クリーンナップ＆Shurinkかを導入時に検討が必要だと判断します。
これらについては今後検討します。
USBのNICを利用したHorizon Clientの利用
先日ユーザ会の会員の方からの問い合わせでWindows7のノートPCにHozion Clientを入れて、USBのNIC経由でVDIを利用したところ2時間程度で画面が真っ黒になるという問い合わせがありました。
症状としては、真っ黒になった後にNICの抜き差しをすると正常に接続できるようになるという事だったのでNICの省電力対応のチェックを外してどうなるかを切り分けてもらい、それでも改善しなかったので別NICを試したかを確認したが、既に実施済みということでUSB NIC依存ではなく、ノートPC側の問題というところまで切り分けました。
その後にデバイスマネージャのUSBの電源管理(例えば、Generic USB Hubのプロパティの電源の管理タブ)にもNICと同じく電源管理の『電力の節約のために、コンピュータでこのデバイスの電源をオフにできるようにする』のチェックを外す必要があるようです。
O365の認証関係
以前、某メーカの営業の方がOffice365の認証はプロキシ除外に入れなければならないが除外サイトが増えるのを製品側で常時チェックしてアップデートするという話がありました。これでそのサイトを調べたところ(要するにうちの環境では利用していないのです)、以下のURLだということが分かりました。
https://support.content.office.net/en-us/static/O365ipaddresses.xml
で、製品でそのURLに登録されているサイトをプロキシ除外に登録すれば、その製品を導入しなくても実装できるなぁ、と思っていましたが自分で使わないのにスクリプト作るのめんどいなあ、と思って更に調べたところ以下のTechNet記事を見つけました
Download and convert the O365IPAddresses.xml file to a custom PowerShell object
https://support.content.office.net/en-us/static/O365ipaddresses.xml
動作確認まではちゃんとしてないのですが、一応それっぽいのが出るところまでは。。。
これがあれば、Proxy.pak保存先かどこかで実行して定期的に更新すれば何とか、という感じではないでしょうか
イライラしてやった後悔はしていないが公開する(Win10のRDP)#2
もう一点、Active Directoryにユーザを作成しログイン先制限を掛けた。対象のサーバのホスト名（NETBIOS名)を入れて接続するとなぜか繋がらぬ。ログイン制限をはずすと繋がるので接続元のPCのホスト名を追加する、、、繋がる。解せぬ
イライラしてやった後悔はしていないが公開する(Win10のRDP)
パケットキャプチャまではしないで解決法見つけてしまったので正確な情報かまでは保障しませんが、某社が提供するWindowsに設定するVPNサービスを新規取引の業者に提供する際のお話。
検証サーバ(Windows2012R2で構築し、業者に渡すためVPN接続テストをテザリングとWindows10で実施したところ、やけにリモートデスクトップ接続が切れる。今回の検証サーバは若手にデプロイさせた物だったので検証サーバの基本設定を再チェック。
結果、1つ目はNICの電源管理設定が漏れていた。テンプレ修正すればいいのだが忙しすぎて忘れてたわけで。。。
頻度はかなり下がったものの、いまだに1分おき程度でバツバツ切れるのでまずは通信の安定を見るため、接続元のWindows10からPing連打しつつ状況を見るが、特段極端な遅延もパケロスもないのに『切断しました、再接続します』と出るのでRDPクライアント周りだと絞って、まずはサーバ側を見ることにする。
ローカルポリシをチェックするため『gpedit.msc』で起動し、サーバ側では再接続設定や接続の確認をN分おきに実施するなどがあるが効果はなく、結局RDP8が原因と判断しリモートデスクトップクライアントのポリシーにあるUDP通信の無効で解決しました、詳細は以下のとおり。RDP8からUDP優先接続みたいですね、これ。
１．gpedit.mscを実行
２．以下の順にツリーを開く
ローカルコンピュータポリシ＞コンピュータの構成＞管理用テンプレート
＞Windowsコンポーネント＞リモートデスクトップサービス
＞リモートデスクトップ接続のクライアント
３．画面右にある『クライアントのUDPを無効にする』を開いて有効にチェック
ThinAppのパッケージングの際に
先日のVMUのVDI会でThinAppの説明をいただいた際に、意外と知られていなかったようなので触れてみます。
仮想化放浪記で手順が公開されているので詳細は省きますが、"Show entry points used for debugging"を有効化によりcmd.exeとregedit.exeが表示されるが、動作検証時以外は無効を推奨とあります。
◆仮想化放浪記
http://makoiin.blogspot.jp/2014/12/thinapp.html
もちろん、高セキュリティが求められる環境やThinAppのパッケージの更新と配布が維持できるのであれば問題ありませんが、一人社内SEで手が足りない！という方にはこの
"Show entry points used for debugging"で表示される項目が非常に便利です。
パッケージ作成画面終了後、ThinAppのプロジェクトフォルダにあるPackage.iniの末尾に[cmd.exe]と記載された行以降を編集します。
この際の注意点としてcmd.exeのままにするとThinAppのパッケージ内なのか通常のWindowsのcmd.exeなのか区別がつかないので[cmd.exe]に接頭語としてvirtualの"v"とかThinAppの"TA"とか[TAcmd.exe]のように適当につけましょう。
ビルドするとThinAppのポインタ(exe)とdat以外に[TAcmd.exe]と[TAregedit.exe]が生成しますので、何かあればこの[TAcmd.exe]を実行してコマンドでSandBoxに設定を追加する事ができます。
また、生成したポインタ(exe)をそのまま提供せずにバッチかVBScriptでポインタを実行する形にする事を推奨します。こうする事で、このバッチやVBscriptに[TAcmd.exe]を利用したアップデート用のスクリプトを仕込んでおくと、パッケージされたThinAppに対してパッチを適用する事ができます。
イメージとしてはThinAppでOffice2013がパッケージされている場合にServicePackを適用したいケースでTHcmd.exe にサービスパックを適用してからポインタで起動するようにするケース(こんな大きなアップデートは推奨できませんが)や、ThinAppでパッケージしたもののドメイン不参加のWindowsサーバにアクセスするためのIDとパスワードが各端末に必要だったが、パッケージ作成操作で忘れた場合などに有効に利用できます。
また、SandoBoxが破損するとどうしようもなくなりますが、上記手段が利用できるとThinAppのリパッケージする時間がないがリリースしなければならない場合などに
外部から配信してとりあえず更新する事ができます。
簡単な例であれば以下のようにバッチファイルで取り込む操作ができますので
ユーザにばれにくいように取り込んで更新をしたい場合に便利です。
echo off
@if not "%~0"=="%~dp0.\%~nx0" start /min cmd /c,"%~dp0.\%~nx0" %* & goto :eof
cd "C:\Program Files\XXXXXThinApp版 (VMware ThinApp)"
◆TAcmd.exeを利用しサーバのユーザアカウント情報をSandBOXに追加する
TAcmd.exe /c cmdkey /add:SERVERNAME/user:SERVERNAME\USER /pass:PASSWORD
◆PC上の設定が書かれたxmlファイルの最新版をThinAppのパッケージに取り込む
TAcmd.exe /c copy /y .\conf\*.xml c:\SUN_CL_SYS\EXECPGM
◆ThinAppのポインタを実行
"XXXThinApp版.exe"
VLSCのSQLSERVERのライセンス認証
SQLSERVERをvCenterDBとして構築しEvaluationモードでセットアップ後にライセンス認証を通すような手順になった際に、ライセンスキーが分からないためVLSCのサポセンに聞くと『再インスト』といわれますが、ISOイメージ内の\x64\Default.iniにあるのでそちらで通す事ができます。
…ほぼ備忘録ですね、これは
