ESX4.1が原因不明のパープルスクリーンになった（Windowsでいうところのブルースクリーン）。
パープルスクリーンの画面をみたところ、下記のようなiSCSIに関するエラーが表示されていた。
～～～～ iscsivmk_TaskHandleTx ～～～～ ～～～～ iscsivmk_ConnProcessTxSchQueue ～～～～
VMwareのナレッジを探したところ、該当するものが見つかった。
iSCSIスタックに関する障害のナレッジが見つかった。
原因は、ストレージ側にあるようで、背景を探ると、ストレージに問題があり、切断中に競合すると、ESXのiSCSIカーネルのスレッドで問題が出るようだ。
iSCSIカーネルに対しては、VMwareから修正パッチが出ている。
■該当するナレッジ情報
vSphere HA (VMwareのHA)構成を使用している場合は、仮想マシンの自動起動は無効となり、ESXiを起動しても仮想マシンの自動起動はされない。
なお、自動起動の設定ができないというわけではなく、設定はできるが、HA上に仮想マシンを配置した場合は、無効化されて機能しない、というのが厄介。
■VMwareのドキュメントページ
vCenter Server 6から、バンドルのDBがPostgreSQLに変更されている。
OS要件がWindowsだったので、もともとSQL Server のExpress版がバンドルされており、
それを使用していた。
vCenter Server 6からは、PostgreSQLにバンドルのDBが変わっており、
これによりSQL Server Expressにあった制約も緩和されている。
6からは、ホスト20台、ゲストの仮想マシン200台まで対応しており、
5.5までのときよりもかなりパワーアップしている。
■参考
基幹システムなどの移行事例が増えていたvCloud Airだが、
VMwareの方針転換に伴い、提供が終了するとのこと。
閉鎖は、来年（2017年）の3月31日なので、あと1年足らずで閉鎖だ。
閉鎖的に自由に使えて、オンプレミスのvSphere環境とほぼ同じなので、
使い勝手が良さそうで注意して情報収集していたサービス。
基幹システムを始めとして、マルッと持っていけそうだっただけに、
サービスの提供終了は残念。
ソフトバンクなどが受け皿となるサービス（vSphere環境）を用意しているようなので、
実質的には、契約先が変わるだけでサービスとしては変わらないのかもしれないが。
それでも、新しいサービスへのシステム移行はきっと発生するのだろうけど。
撤退の背景には、日本の市場が直接契約ではなくて、ベンダーや通信キャリア経由で
発注したり、管理したり、という商習慣が影響しているのだろう。
（VMwareの発表資料でも、「日本市場の特殊性を鑑み」と言っているので。）
大手のパブリッククラウド撤退は、昨年、HPがIaaS型のパブリッククラウドを終了している。
日本だと、今回のvCloud Airが影響の大きさとしては一番だろう。
発表から1年で切られてしまうところを考えると、フットワーク軽く自分たちで
クラウドサービスの載せ換えができるような人がいる会社じゃないと、
おいそれとクラウドサービスの利用は使えないかも。
日本には、オンプレミスのプライベートクラウドが向いている、
と再認識されせられた。
http://www.publickey1.jp/blog/16/vmwareiaasvcloud_air2017331.html
http://vcloud.vmware.com/jp/using-vcloud-air/vca-customer-letter-japan2016
ちょっと前にひょんなことから、話は耳に入っていたけれど、やっと発表された。
発表されないと、嘘か誠かわからないから。
VMware PowerCLIのバージョンを調べるには、
PowerCLIを起動させて、以下のコマンドを実行する。
Get-PowerCLIVersion
Virtual Machine To Phisical Machine を行う手順や注意事項。
（P2Vではなく、仮想から物理に変更する手順）
なお、「Converter およびその他の VMware 製品では現在、仮想マシンから
物理マシンへの移行をサポートしていません。」とのこと。
一応、できるようだけど、自己責任。
せっかく調べたのでメモ。
vCenterで設定しているアラームが、vCenter上で正常な状態に戻り、 発生中のアラーム画面でも消えているのにもかかわらず、アラーム通知がされる。
アラームの画面では、既に消えているため、vCenter上でのアラーム解除ができない。 この状態の対処方法。
発生したのは、「ネットワーク接続が失われました」のアラームとして説明。
これで、アラームのアクションが消える。根本的な解決は、ESXiにアップデートパッチを当てる。
ESX4.1上の仮想サーバで、CPUが不足しがちなので、CPUを追加したところ、 以下のエラーが表示され、ESX上で電源を入れることができない。
仮想マシンに 8 個の仮想 CPU がありますが、ホストがサポートするのは 4 個
のみです。仮想 CPU の個数は、その仮想マシン用に選択したゲスト OS また
はホストのライセンスによって制限される可能性があります。
調べたところ、ESX4.1 Standard EditionではCPUが4個（4 vCPU）までという制限があり、 設定画面上は8CPU（8コア）まで選択できるが、電源をいれることはできない。 ESX4.1で8CPUを使うには、Enterprise Plusである必要がある。
高いエディションを使うよりも、ESXをバージョンアップした方が他のメリットもあるため、 安いし、早い。
VMwareのナレッジ。
8 個の vCPU で構成されている仮想マシンのパワーオンに失敗する (2086711)
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2086711
VMwareの機能でスナップショットがある。 変更前の時点を記録（スナップショット）できる便利な機能。
このスナップショットの注意点。
この注意点を守らずスナップショット付のまま使用すると
が発生する。 通常の使用だと気にならないが、高負荷のかかるサーバだと多少の劣化も影響があるので注意。
Windows Server 2008 R2のクローン時にvCenterの機能でSysprepしても、クローン後にSysprepしても、Sysprep後の再起動の時に下記のErrorが発生して、必ずブルースクリーンになり、再起動とブルースクリーンを繰り返す。
autochk program not found - skipping AUTOCHECK
■環境
■対応方法 SysprepしてSkippingのエラーがでる環境からの対応方法。
diskpart
list volume
select volume 1
attributes volume
attributes volume clear nodefaultdriveletter
■参考情報
VMwareのナレッジ
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2004505