5/9のWindows UpdateでCVE-2018-0886の更新が予定されていますが、この更新、業務影響大きい気がするのに、全然騒ぎになっていない気がする。
簡単に言うと、以下の運用の場合は、5/9以降クライアントからサーバ側へRDPで接続出来なくなる可能性があります。
・サーバはWindowsUpdateしない運用
・クライアントは自動でWindows Updateがかかるようにしている、
https://blogs.technet.microsoft.com/jpntsblog/2018/04/20/cve-2018-0886/
https://support.microsoft.com/ja-jp/help/4093492/credssp-updates-for-cve-2018-0886-march-13-2018
Views: 3
メインの仮想環境Z800->Z820の暫定修復が終わったと思ったら、
３台ある残り２台の仮想環境のうちの1台の、一番いろんな実験をしていたサーバも、
物理的に死にました。
このサーバでやってた変態的いや、いろいろな運用の例
・USBブートESXi [一様公式だけど、本番運用では普通しない]
・安鯖[NEC Express5800/GT110b]にCPU i7 870 & 32GBメモリ交換での運用
・筺体内ストレージ仮想マシンによる自作自演NFSストレージ(2TB*4 RAID5 & 2TB) [今で言うVSAN的運用]
・Radeon 5570をVMDirectPathでWin7仮想マシンに直結 [今で言うvDGA運用]
・USB3.0インターフェイスをVMDirectPathでWindowsストレージサーバに直結してのファイルサーバ（管理Disk容量約65TB）
・Xen on ESXiによる仮想 on 仮想環境
元々、一度電源を落とすと５,６回、多いときだと十数回、電源OFF.ONを繰り返さないと起動できない状況 & マザー搭載VGA機能死亡状態で
３年ぐらいだましだまし使っていたのですが、
電源OFF.ONを繰り返しているうちに、
起動用USBにダメージを受けてしまった＆色々試行錯誤しているうちに、マザーボードのストレージコントローラを完全に見失っていて、ジ・エンドとなりました。
ただ、GT110bは発売からすでに10年経っている機種なので、何かあったときに入手困難となる可能性があったので、
共食い修理用の同型機種を２台ほど確保済みだったので、この予備サーバを使って復旧実施。
・保管してあった予備サーバに、CPU,メモリ、ストレージ、起動用USBメモリを移植
・ESXiのアップグレードインストール(ESXi 5.0->5.5、以前のコンフィグを継承するため)
いままで、なかなかふんぎりつかなくて、交換できていなかったのですが、
いざ始めてみたら、交換開始からさくっと２－３時間ぐらいで復旧。
（まったくの同一機種なので、移植は非常に楽。）
ちょうど、GWぐらいに先日暫定復旧したZ820環境にDISK拡張した後に、
この環境もマージできるように各種単体機能テストをしようかと考えていたのだけど、このタイミングで完全に壊れるとは・・・
Views: 12
突然死したZ800ですが、交換用のZ820が到着しました。
到着したのは、
HP Z820 水冷モデル
CPU :E5-2687W @3.10 x 2
MEM:32GB(RDIMM 1600メモリ 8GB x4)
GPU :Quadro K2000
とりあえず故障したのZ800からパーツを移植
・メモリ192GB (RIMM 16GB x12)
・Quadro4000 x1
・Intel CT NIC x1
・ストレージ系(SSD 960 x2,SDD 128 x1,4TB SATA HDD x3,300GB SAS HDD x4)
特にZ820サポート外のDDR3 RIMM 1333メモリを搭載したけど、普通に認識してメモリチェックもOK
メモリはZ820についていた32GBも追加して、現状224GBという中途半端な容量に。
ただ、Quadro4000とIntel CT NICを搭載したらBIOSのメモリオーバーエラーがでてしまったのでBIOSでbootに必要な誘うなNIC系のBIOSを切る必要がありました。
とりあえず、既存のSSDに入っていたESXiは普通に起動
ただ、SATA 6ポートのうち、6Gbpsのポート２つに挿したSSD2つは認識してVMFS領域もマウントできたけど、
残りの4ポート(3Gbps)が、ブロックSCSI扱いではなく、SCSI扱いになっていて、認識はするけどVMFS領域マウントせず。
どうやらvCenterに昔のVMFS領域のシグネーチャが残っていて、
接続がブロックSCSIからSCSI扱いに変わっている影響で同じシグネーチャでも、違うものとして認識しまったのに、すでに同じVMFS領域名が登録されているため、マウントできない模様
とりあえず以下をしたら、マウントできました。
・vCenterに残っているVMFS領域の名前を変更
・既存のVMFS領域のシグネーチャを更新してマウント
ただ、VMFS領域においてあった仮想マシン&VMDKは再登録する羽目になりましたが（仮想マシン２つ＆VMDK6個だけでしたが）。
なお、vCenterに昔のVMFS領域が残っていたのは、その領域を使用している仮想マシン&VMDKが登録されていたためだったようで、それを消したら、昔のVMFS領域は消えました。
もしかしたら、以下の手順のほうが簡単に復帰できたかも知れず・・・
・昔のVMFS領域を使用している仮想マシンをvCenterのインベントリから削除
・DISKを再マウント
・インベントリから削除した想マシンの再登録
とりあえず、これでストレージ系の復旧は完了。データ欠損なし。
あとはNICのMACアドレスが変わっているので念のため以下のコマンドを実行
# esxcfg-advcfg -s 1 /Net/FollowHardwareMac
（ESXは、ESXのインストールを実施したときにvmk0のNICのMACアドレスをシステムに登録してしまって、NICが変更されても依存のMACアドレスで通信するため）
ただ、コレをやると、該当サーバで仮想マシンを最初に立ち上げるときに「移動」したか、「コピー」したかを聞かれてしまうので、ハード交換をしないのであれば、しなくてもいいかも。
https://kb.vmware.com/s/article/1031111?lang=ja
とりあえず、暫定復旧は完了。
あとは、ちょっとしたグレードアップとして
流用したRIMM 8GBメモリx4を、追加購入予定の16Gメモリx4に変更して合計メモリを256GBにするのと、
SAS 300GBx4を、SATA 8TBx4に置き換えを計画するくらいですかね。RAIDは5にするか10にするかは迷っていますが。
Views: 15
