ESXiのSYSLOG設定するためのメモ

ESXiのSYSLOG送信設定するためのメモです。

GUIでも出来ますが、
今回はコマンドライン(SSH)で実施します。

また、デフォルトでは、すべてのメッセージをSYSLOGに送信してしますので送信レベルを”Warning”に変更しています。

syslog送信先は、192.168.29.105:512を想定しています。

設定後の反映には、サービスの再起動が必要になります。
(vSphereClientで直接ESXiに接続している場合は一旦切断されます。)

 

カテゴリー: 未分類 | コメントする

異常発生しているOS-HDDの交換

メインの録画環境を動かしているHP Micro Server N54LでOSの入っているHDDで、結構な異常ステータスが見られました。

現状、普通に動かすには問題ないようですが、
一部フォルダをコピーしようとするとエクスプローラが応答を停止したり、
イメージバックアップをとろうとしても途中でとまってしまってバックアップできなかったりと
結構危なげな状況です。

Smartを取得してみると、回復不能セクタが0x37(55)となっているのに、
代替処理中のセクタ数が1と結構ヤバイです。

イメージバックアップが取れないので、普通な方法では別のHDDにリストアできずに、OS再構築しかないかと思ったのですが、最近はエラーセクターがあっても、クローンが取れる装置が入手できるようになったので、試してみました。

AOK-CLONE-U3
https://www.amazon.co.jp/gp/product/B01MDTXXAA/ref=oh_aui_detailpage_o05_s01?ie=UTF8&psc=1

通常はHDD(2.5インチ、3.5インチ)を2つ接続できるUSB3.0スタンド(UASP対応)として使えますが、エラースキップ対応のクローン機能を持っています。

USB3.0スタンドとしては、USB3.0でPCと接続して、電源を入れれば使えますが、
クローン機能を使う場合は、ちょっと手順が必要です。

注意としては、クローン元のドライブ容量に対してクローン先のドライブ容量は同等または、それより大きい必要があります。また、クローン元、先でAFTと非AFTディスクは合わせたほうがいいです。

1.電源OFF状態でPC未接続にする。
2.クローン元のHDDをHDD1スロットに挿入
3.クローン先のHDDをHDD2スロットに挿入(入れ間違えると、大惨事になるので注意)
4.電源ON(アクセスランプ1,2が青く点滅します。)
5.クローンボタンを5秒間長押しする。(アクセスランプがすべて点滅します)
6.一度クローンボタンを離して、再度押すと、クローンが開始されます。

25%   50%    100%
00~25% ・・ 青点滅 消灯  消灯
25~50% ・・ 青点灯 青点滅 消灯
50~75% ・・ 青点灯 青点灯 青/緑点滅
75~100% ・・ 青点灯 青点灯 緑点灯/青点滅
100%    ・・ 青点灯 青点灯 緑点灯/青点灯 ・・・ 完了

なお、途中でエラーセクターがあった場合は、25%ランプが赤くなります。
75-100%時と完了時が少しわかりにくいですが、100%ランプでちらつきがなくなれば完了です。

WD20EZRXの2TBから、WD20EARXの2TBへのコピーでだいたい8時間弱かかりました。

 

後は、コピー先のHDDをPCに接続して起動できればOKです。

PCのマザーボードによっては、BIOSのDISKの起動順序が入れ替わったりする場合があるので、
その場合は再設定が必要です。
(N54Lの場合は、F10でBIOSセットアップでBoot Orderを再設定)

今回はこの段階で、うまくブートしてくれました。

 

それでも起動しない場合は、OSの起動ディスクで起動して、ブート領域の際インストールで直る場合もあります。

Windows 7の場合は、インストールディスクで起動してコマンドプロンプトを立ち上げて
以下のコマンドを実行します。

bootrec.exe
bootrec.exe /fixmbr
bootrec.exe /fixboot
bootrec.exe /scanos
bootrec.exe /rebuildbcd

これでだめなら、OSの上書きインストールですかね。
新規インストールよりはちょっとは復旧が楽になります。

 

カテゴリー: 未分類 | コメントする

GPDWin2 届きました。

GPDwinを使用していましたが、GPDWin2が届きました。
ちょっとだけ触ってみましたが、GPDWinをさらにGame様に特化したような進化をしていますね。

主な変更点
・全体的な高速化(CPU:Core m3,Memory:8GB,SSD:128GB)
・Displayが5.5インチから6インチに変更(解像度は変更なし)
・キーボードが5段から6段に変更
・WSDAキーのキートットの形が変わっていて、感触でわかるようになっている
・L3,R3キーが背面に移動(L3キーはキーボードにも存在)
・スピーカーがキーボード上にステレオで配置され、音がちゃんとステレオで聞こえます。
・Micro HDMIインターフェイス追加

ただ気になった点は以下の通り
・FAN音が結構うるさい(FAN停止スイッチなし)
・満充電時にさらに充電していると、コイル泣き音あり
・Enterキーが横長のため、周りのキーが少し膨らんでいる感じがあり、比較的膨らんでいないように感じるEnterキーが少し押しづらいかも
・一回り大きくなった様に見えるが、ヒンジのでっぱりがなくなってるため、大きさはほとんど変わりません。
・ジョイパットのDirectInputモードがなくなっている
・ジョイパットのマウスモードはちょっとした癖あり(おまけに記載)。
・GPDWinでは、マウスモードでキーボード上のL3,R3がマウスの左右クリックに対応していたため背面ボタン使わないでも操作できたが、GPDWin2では背面ボタン必須

私のように、GAME用途ではなく、リモートコンソール端末として使うような用途だと
一部微妙な点もありますが、正常進化ではないでしょうか。

一応La-mulana2は楽しみにしているのだけれども、
今年7-8月にホントに出るんでしょうか。。。。

 

おまけ

GPDWin2 ジョイパットのマウスモードの割り当て

左スティック(上,下,左,右)=(w,s,a,d)
十字キー(上,下,左,右)=(上スクロール、下スクロール、PageDown、左キー)
YAXBボタン=(上キー,下キー,左キー,右キー)
左ステック=マウス移動
L1=マウス左クリック
L2=マウス中クリック
L3=ENDキー
R1=マウス右クリック
R2=マウス移動ブースト
R3=下キー

L3,R3,十字キー右あたりはかなり変則的。
おそらくゲームでは便利そうな割り当てなのでしょう。

R3(下キー)は、R1(マウス右クリック)を押してメニューを出してR3(下キー)で選択あたりを想定しているのかな?

十字キー右(左キー)は、左右キーを左手(十字キー右)、右手(Bボタン)で分けて押せるように配慮?

あと、個人的は、L3キーのENDキー割り当ては、ブラウザなどで誤爆しそうなのでやめてほしかったです。

割り当ては、JoyTiKeyあたりで自分でマッピングも手ですね。

 

カテゴリー: 未分類 | コメントする

強制的にESXiの仮想マシンを停止する方法。

vsphere(ESXi)で仮想マシンが応答なくなって、どうしてもとまらないときの最終手段

一歩間違えると、別のプロセス落としてしまって、取り返しのつかなくなることもあるので、本気で最後の手段

 

ESXiのコンソールに入って、以下のように操作

最初にPSコマンドで親プロセス番号を確認(麗では、仮想マシン名がwalbrix)。
psで親プロセス番号を確認しますが、2つ目の数字が親プロセス番号(2189879)です。

 

親プロセス番号を探したら、kill <親プロセス番号>でプロセスを殺します。

 

EVCを設定していない環境でvMotionとかやると、
コレじゃないと回復できないことがあります。

 

SXi ホストで仮想マシンをパワーオフできない (2075271)
https://kb.vmware.com/s/article/2075271

カテゴリー: 未分類 | コメントする

PCNETのブラックマーケットで記念にThinkPad L430のジャンク品GET!!

PCNETのブラックマーケットで記念にTHinkPad L430のジャンク品をGET!!

お値段2000円也

とりあえず選んだ理由はUSB3.0インターフェースが1つついていたことのみ。
現地で起動するのは確認できたけど、power-onパスワードがかかっていたので、
それ以上の情報はわからず。

もう一台USB3.0インターフェイスが3つもついていたノートPCがあったけど、
こちらは電源は入るけど、ディスプレイや外部モニタの応答がなかったのであきらめました。

 

別途Lenovoの電源アダプタ(20V3.25A)を用意して復活の儀です。
復活できる可能性は五分五分といったところですが、試してみます。

L430のメンテナンスマニュアルを確認してみます。
https://download.lenovo.com/ibmdl/pub/pc/pccbbs/mobiles_pdf/l430_l530_hmm_en_0b48570_02.pdf

power-on passwordの解除は、BIOS Supervisor Passwordがかかっているかどうかで
出来るかどうかが変わります。

Supervisor Passwordがかかっている場合は、パスワードがわからないとどうしようもありません。
(実はマザーボードが見えるまで分解して、とあるチップの足をショートさせることでクリアできるらしい。)

Supervisor Passwordがかかっていなければ、復活の可能性ありです。
作業的には、以下の通り

・電源OFF
・AC Adapterの取り外し
・バッテリパック取り外し
・内蔵のバックアップバッテリの取り外し
・AC Adapterの取り付けと、電源ON

・power-on passwordの解除を確認

・電源OFFとAC Adapterの取り外し
・内蔵のバックアップバッテリの取り付け
・バッテリパック取り付け
・AC Adapterの取り付けと、電源ON
・BIOS 設定のデフォルト設定の保存

以上で復活完了です

大変なのは、「内蔵のバックアップバッテリ取り外し」です。
内蔵のバックアップは、キーボードを取り外したところにあるのですが、
キーボードを取りはずしするには背面カバー(HDDのところ)をはすして、キーボード固定のビスを2本を抜き、キーボードをスライドさせて取り外すとあります。

で、ジャンクのL430の状態ですが、
CPU:Celeron B830 1.8GHz (Sandy Bridge世代:Mobile:DualCore)
MEM:DDR3 メモリ 2GB(キーボード裏。背面側は未搭載)
HDD:抜き取り済み

といった感じでした、ジャンク品にしてはめずらしくメモリが抜かれていませんでしたが、
キーボードの裏側のほうだったので、確かに取り外すほうが大変かもしれませんね。

さて、問題はこのノートの使い道ですが、
ファイルサーバの代わりにするか、
ChromeOS(CloudReady)あたりを試すか悩みます。

 

カテゴリー: 未分類 | コメントする

Oculus Go到着

Oculus Goを水曜日に公式サイトから注文したらもう届いた。
すごい届くの早いな。

ただ、セットアップにAndroid5.0以上が必要で、唯一対応していたスマートウォッチのFinow X5でセットアップを実施。400×400のRound液晶だけどなんとかセットアップ完了。

後でいろいろ試す予定。

カテゴリー: 未分類 | コメントする

Windows7でタスクスケジューラでエラー(Windows7から一度Windows10にアップグレード後に元に戻した環境でご注意を)

いつの間にか、タスクスケジューラーを開くとエラーメッセージが出るようになっていたみたい。
「タスク イメージは破損しているか、または変更されています。HRESULTからの例外:0x80041321)」

調べてみると、Windows7から一度Windows10にアップグレード後に元に戻した環境で起こるらしい。(何年気づかなかったんだろう・・)

この状態だと、タスクもうまく動いていないみたいだし、再度Windows10にアップグレードする際に問題になりそうなので、今のうちに修正。

修正は、1つ1つ修正していく方法もあるみたいだけど、手順が複雑&レジストリもいじるみたいなので、ツールを探して対応します。

ツールは、RepairTasksというもので、以下からダウンロードできます。
https://github.com/Dijji/RepairTasks/releases

上記リンクから、以下のものをダウンロードしておきます
RepairTasks.zip
・Windows7.Tasks.zip

次にツールで修復します。
まずは、RepairTasks.zip を解凍します。

では、「RepairTasks.exe」を管理者として実行します。

RepairTasksが起動しますので、「Scan」をクリックすると、現在の状態を調査します。

44個の問題が見つかりました。
「Backup Tasks」でバックアップを取った後で、
「Repair」で修復します。

44個のうち、39個が修復され、5つの修復が失敗しました。
失敗したタスクは以下の5つでした。
(複数のマシンで修復を実施しましたが以下の5つは失敗するみたいです)

この5つが、残ったエラーになる原因です。
Windowsのtasksフォルダ[C:\Windows\System32\Tasks\]から階層をたどって、
エラーになったすべてのタスクのファイルを削除(もしくは移動)します。

「Microsoft\Windows\PerfTrack\BackgroundConfigSurveyor」であれば、
「C:\Windows\System32\Tasks\Microsoft\Windows\PerfTrack\」フォルダの
「BackgroundConfigSurveyor.で始まるファイルになります」

エラーになったタスクファイルが削除したら、
タスクスケジューラを起動します。

今度はエラーは出ないはずです。(もし出たら、別のことが原因かも知れません。)

一旦、これで修復は完了ですがエラーになったタスクは削除していますので、
必要に応じて再登録します。
今回エラーになった5つのタスクであれば、Windows7の初期タスクですので、
RepairTasks.zip」と一緒にダウンロードした「Windows7.Tasks.zip」を解凍し、

エラーになったタスクを「タスクのインポート」からインポートします。
(実は5つのうち2つ(1つ目と3つ目)は無効状態のなので、インポートしなくても問題ないのですが、念のため)

ダウンロードしたファイルは.xmlファイルではないので、インポート時のファイル選択時に、すべてのファイル(*.*)にして表示させる必要があります。

タスクが読み込まれますので、そのまま「OK」を押して登録します。

タスクが登録されました。他のタスクも同様に登録します。

 

これで、復旧完了です。

カテゴリー: 未分類 | コメントする

BSデジタル周波数再編(トランスポンダ変更)に対応したPCでの録画環境設定変更(5/28更新分反映)

BSデジタル周波数再編(トランスポンダ変更)の影響で、PCでの録画環境の設定変更が必要な模様です。
(特にBonDriverを使用した録画環境の場合は必須の模様)

BS JAPANは普段とっていないので気づきませんでしたが、
5/9夜にNHK BSプレミアム関連でEDCB 9xでエラーウィンドウが出ているので気づきました。
EDCB 10系では、特に何もエラーダイアログは出ていませんでしたが、録画には失敗するようです。
5/22もなんとか、対応完了。
一般に言われていた新しいTSIDが予想と違っていたため、
直前の情報収集が必要でした・・・

某掲示板より

 

4月16日(火曜)BS JAPAN 完了
5月8日(火曜)NHKBSプレミアム 完了
5月22日(火曜)ディズニー・チャンネル、BS アニマックス 完了
5月28日(月曜)スターチャンネル 2、スターチャンネル 3 完了

ただ、対策はチャンネルスキャンするだけではだめで、
少なくともBondriverの定義ファイルをいじらないと受信できないらしい。
定義ファイルのないBondriverの場合は、BonDriverを直接バイナリエディタでの変更が必要みたいです。

おそらく、修正内容は以下の通り。
(20180522:ディズニー・チャンネル,BSアニマックスのTSIDが誤っていたため、修正)

(1)BSジャパン(2018年4月16日~)
周波数:11765.840→11727.480
名称 :BS03/TS1→BS01/TS2
TSID :0x4031(16433)→0x4012(16402)

(2)BSプレミアム(2018年5月8日~)
周波数:11996.000→11765.840
名称 :BS15/TS2→BS03/TS1
TSID :0x40f2(16626)→0x4031(16433)

(3)ディズニー・チャンネル(2018年5月22日~)
周波数:11842.560→11765.840
名称 :BS07/TS2→BS03/TS2
TSID :0x4672(18034)→0x4632(17970)   [TSID :0x4672(18034)→0x4032(16433)]

(4)BSアニマックス(2018年5月22日~)
周波数:11842.560→11957.640
名称 :BS07/TS1→BS13/TS2
TSID :0x4671(18033)→0x46d2(18130)           [TSID :0x4671(18033)→0x40d2(16594)]

(5)スターチャンネル2(2018年5月28日~)         予想(TSIDについては、別途確認の必要あり)
周波数:11842.560→11996.000
名称 :BS07/TS0→BS15/TS2
TSID :0x4470(17520)→0x40f2(11996)

(6)スターチャンネル3(2018年5月28日~)         予想(TSIDについては、別途確認の必要あり)
周波数:11842.560→11996.000
名称 :BS07/TS0→BS15/TS2
TSID :0x4470(17520)→0x40f2(16626)

 

家で使用しているBSCSチューナは以下の通り
PX-W3U2:Bon Driverの定義ファイル(.ini)にて対応化・・・・・・・・(1)
PX-Q3PE:Bon Driverの定義ファイル(.ini)にて対応化・・・・・・・・(1)
PX-BSCS:定義ファイルがないため、バイナリの直接変更が必要・・・(2)

(1)はBon Driverごとに用意されたiniファイルの中身を更新するだけです。

BSジャパン(2018年4月16日~)
CH004=BS3/TS1,171,11765840,0×4031

CH004=BS1/TS2,171,11727480,0x4012

NHK BSプレミアム(2018年5月8日~)
CH011=BS15/TS2,103,11996000,0x40f2

CH011=BS3/TS1,103,11765840,0x4031

ディズニー・チャンネル(2018年5月22日~):確定版
CH024 = BS7/TS2,0,11842560,0×4672

CH024 = BS3/TS2,0,11765840,0x4632

BSアニマックス(2018年5月22日~):確定版
CH017 = BS7/TS1,0,11842560,0×4671

CH017 = BS13/TS2,0,11957640,0x46d2

スターチャンネル2,3(2018年5月28日~):確定版
CH016 = BS7/TS0,0,11842560,0×4470

CH016 = BS15/TS2,0,11996000,0x40f2

 

(2)は、Bon Driver(.Dll)を直接バイナリエディタで書き換えが必要です。
[https://mevius.5ch.net/test/read.cgi/avi/1521541943]

●BSジャパン(2018年4月16日~):確定
純正(?)ボンドラ利用の場合
[BonDriver_BSCS.dll (158,720 Byte)]
;BSJ 周波数変更 BS3/11766(0x2DF6) → BS1/11727(0x2DCF)
022A38: F6 CF
;BSJ TSID変更 16433(0x4031) → 16402(0x4012)
022A3C: 31 12

●BSプレミアム(2018年5月9日~):確定
純正(?)ボンドラ利用の場合
[BonDriver_BSCS.dll (158,720 Byte)]
;NHK P 周波数変更 BS15/11996 (0x2EDC) → BS03/11766 (0x2DF6)
022918: DC F6
022919: 2E 2D
;NHK P TSID変更 16626 (0x40f2) → 16433 (0x4031)
02291C: F2 31
02291D: 40 40

●ディズニー・チャンネル(2018年5月22日~):確定
純正(?)ボンドラ利用の場合
[BonDriver_BSCS.dll (158,720 Byte)]
;ディズニー・チャンネル 周波数変更 BS07/11843 (0x2E43) → BS03/11766 (0x2DF6)
022DE0: 43 F6
022DE1: 2E 2D
;ディズニー・チャンネル TSID変更 18034 (0x4672) → 17970 (0x4632)
022DE4: 72 32
022DE5: 46 46

●BSアニマックス(2018年5月22日~):確定
純正(?)ボンドラ利用の場合
[BonDriver_BSCS.dll (158,720 Byte)]
;BSアニマックス 周波数変更 BS07/11843 (0x2E43) → BS13/11958 (0x2EB6)
022D98: 43 B6
022D99: 2E 2E
;BSアニマックス TSID変更 18033 (0x4671) → 18130 (0x46d2)
022D9C: 71 D2
022D9D: 46 46

●スターチャンネル2,3(2018年5月28日~):予想(TSIDについては、別途確認の必要あり)
純正(?)ボンドラ利用の場合
[BonDriver_BSCS.dll (158,720 Byte)]
;スターチャンネル2,3 周波数変更 BS07/11843 (0x2E43) → BS15/11996 (0x2EDC)
022BE8: 43 DC
022BE9: 2E 2E
;スターチャンネル2,3 TSID変更 17520 (0x4470) → 16626 (0x40f2)
022BEC: 70 F2
022BED: 44 40

 

上記修正のあとは、チャンネルスキャンで移動したチャンネルが認識されます。
もし、Spinel経由でチューナーを使っている場合も、Spinelサーバ側のBonDriverで修正すればOKのようです。

もし、チャンネルスキャンをしない場合は、チューナーごとのファイルを書き換えてもよいですが、チャンネルスキャンをお勧めします。

 

EDCB 9.x系であれば、\EpgTimerBonフォルダ内のBSCSチューナのChSet.txt、ChSet2.txtファイルを書き換えます(チャンネルスキャンをした場合は不要)。
(例)

BonDriver_PX_Q3PE_S0(PX-Q3PE S0).ChSet.txt

BonDriver_PX_Q3PE_S0(PX-Q3PE S0).ChSet2.txt

「ChSet3.txt」も同様に変更が必要です。
(チャンネルスキャンした場合でも、昔の情報が残っているので削除推奨)
作業後は、EDCBの設定から「EPGデータ取得設定」で、変更したチャンネルがEPG取得対象になっていることを確認してください。

 

 

EDCB 10.x系であれば、\Settingフォルダ内のBSCSチューナのChSet4.txtファイルを書き換えます。
(チャンネルスキャンをした場合は不要)
(例)

BonDriver_Spinel_BCUD0(Spinel:PXBCUD_0/S0).ChSet4.txt

「ChSet5.txt」も同様に変更が必要です。
(チャンネルスキャンした場合でも、昔の情報が残っているので削除推奨)
作業後は、EDCBの設定から「EPG取得」で、変更したチャンネルがEPG取得対象になっていることを確認してください。

 

家は結構いろんなチューナを使っているので、対策が結構大変。

 

とりあえず、修正はコレで完了ですが、
既に予約している番組は対応チューナーがなくなったと認識されているので無効化推奨です。
自動予約していない場合は、手動での登録が必要です。
EDCB10.0系の場合一括置換することも出来るようです。

また、自動予約を対象のチャンネルで登録している場合は、こちらも修正が必要です。
EDCB10.0系の場合一括置換することも出来るようです。

 

 

とりあえず、メインの録画環境だけ修正したので、現在様子見中
残すは後一回。5/28にもやらないといけませんね。

参考
http://soranikakaruhashi.blog.fc2.com/blog-entry-379.html
http://heikin.hatenablog.com/entry/BS_Restruct2018
https://nyanshiba.hatenablog.com/entry/2018/04/16/193910
https://mevius.5ch.net/test/read.cgi/avi/1521541943

 

カテゴリー: 未分類 | コメントする

ESXi5.5でのFirePro W7000用vSGA環境構築

HP Z820(ESXi5.5U3)に、FirePro W7000を接続して、vSGA環境構築して見ました。
(vSGAについてや、vSGA for Quadro4000 については、こちら)

このHP Z820(ESXi5.5)は既にQuadro 4000でvSGAを使用していましたが、
ESXI6.0になるとQuadro 4000がvSGAデバイスとして使用できなくなりますので、
ESXi5.5の今のうちに動作するかを確認してみます。

なお、HP Z820は公式にFirePro W7000をサポートしているので、そのあたりは安心の構成です。

まずは、ESX5.5を動かしているHP Z820に刺さっているQuadro4000を取り外しし、そのスロットにFirePro W7000に差し替えして、ESXi5.5を起動します。

起動後のW7000の認識は以下の通り

 

「Module Name: None」となってるので、ドライバは読み込みされていません。
まだ、ドライバを入れていないので当然といえば当然ですが。

 

では、ドライバを導入します。
メンテナンスモードにして、ESX5.5用のドライバである以下のドライバを導入します。

esxi5.5用
https://support.amd.com/en-us/download/workstation?os=VMware%20vSphere%20ESXi%205.5#pro-driver
vSGA用ドライバ
fglrx-12103.1135534-1oem.550.0.0.1331820.x86_64.zip

VIBファイル名
「fglrx-12103.1135534-1OEM.550.0.0.1331820.x86_64.vib」

なお、–no-sig-checkをつけないでインストールしようとするとエラーになったので、
オプションをつけて、再実行しています。

再起動は不要となっているようなので、この状態でもう一度ドライバ読み込まれているか確認します。

まだ、ドライバは読み込まれていないようです。
ではインストールしたドライバ名を確認(fglrx)して、強制ロード、再度確認してます。

「Module Name: None」ですので、まだ読み込まれていませんね。
ESXi5.5を再起動してみます。

「Module Name: fglrx」となって、ドライバが読み込まれました。

では、gpuvmで状態を確認してみます。

FirePro W7000はメモリ4GB搭載していますが、ちゃんと認識しています。

ためしにこの状態で仮想マシンを起動して、ログを確認してみます。

仮想マシン起動時に、GPUにアクセスしている形跡がありますね。
ちゃんと、仮想マシンから、vSGAデバイスとして使えているようです。

WebClientから確認してみると、ちゃんとvSGAデバイスとしてGPUを認識しています。
Pitcairn XT GL(AMD)でタイプsharedとなっているのがW7000のようです。
もう一枚NVIDIAQuadro K2000がタイプDirectで認識していますが、後でvDGAで試を予定のものです。この時点では既にESXiカーネルからは切り離されているものです。

これを見て、あれ?っと思った方もいるかもしてませんが、
本来vSGAを使うためには、vSGAで使用するGPUとは別に、ESXiコンソール用にもう一枚VGAカードが必要です。
ただ、この構成でも、ESXiコンソール画面上にちらつきやノイズが出ることがありますが、とりあえず動いているようです。もちろん推奨は出来ませんが。
(Quadro4000のときも同様でした。)

 

なお、Quadro4000のときと比べると、NVIDIAGPU用のGPUの負荷や温度などを調査出来る「nvidia-smi」コマンドが使用できないため、標準ではこのあたりの情報は取得できないようです。

Web Clientにもそのような項目はないようです。

このあたりはLinux用のコマンドである「aticonfig」や「radeontop」コマンドをESXi用に用意できればもしかしたら取得できるかも知れませんが、現状そのようなものは見つかっていません。もう少し調査してみます。

 

さて、後はESXiを5.5から6.0にあげれば、なんとか一連の作業は完了しそうです。

 

カテゴリー: 未分類 | コメントする

vSGA調査結果(Quadro4000,FirProW7000 for vSGA ドライバ情報)

今、ESX5.x系でvSGAを使用するためにQuadro 4000を使用しています。

vSGA(Virtual Shared Graphics Acceleration)は、
ESXi仮想マシンの標準GPU(VMware SVGA)をGPUのハードウェアを使用して高速化するものです。
仮想マシンからは普通の「VMware SVGAアダプター」として認識しているが、DirectX9.0cとOpenGL2.1が高速化されます。
なお複数の仮想マシンからは、VGAのメモリが許す限り同時に利用できます。
vMotionなども普通に可能なため、非常に使い勝手のよい技術になります。

なお、いままでコミュニティレベルで実施され、通称「GPUパススルー」とかいわれていた、
VGAをPCI パススルーで仮想マシンに直接接続し、仮想マシンからGPUの全機能を使用可能するものは、VMwareから正式に vDGA(Virtual Dedicated Graphics Acceleration)という名称がつきました。こちらは1GPUごとに1仮想マシンが対応となります。
PCI パススルーを使用しているので、vMotionや電源On中の仮想マシンリソースの拡張等はできなくなります。(ESX6.7でvMotionが出来るようになるかもしれません)。

またこの拡張で、vGPUやMxGPUという技術もありますが、これはGPU側の機能で1枚のGPUを複数の論理GPUとして分割し、論理GPUを仮想マシンに接続できるようにするものです。
こちらもPCI パススルーを使用しているので、vMotionや電源On中の仮想マシンリソースの拡張等は出来ない制限がありますが、ESX6.7でvGPUの場合のvMotionは可能になるようです。

 

Quadro 4000の概要は、以下の通りです。
(Fermiコア,CUDAコア256,メモリ2GBG DDR5,PCI-e 1Slot)
(最大消費電力142 W,電源補助ケーブル必須[シングル6ピン])

 

Quadro 4000 の ESX5.5U3での認識情報

ただ、Quadro4000はすでにVMware Compatibility Guideからも削除されており、NVIDIAのドライバの詳細にも書かれておらず、なかったもの扱いされている状態です。

VMware Compatibility Guide for vSGA ESX5.5U3

 

現在ESXi5.5使用できているQuadro4000用ドライバは 319.65というものです。
NVIDIA-VMware_ESXi_5.5_Host_Driver_319.65.zip

このドライバでサポートしているGPUは以下の通りですが、このバージョン以降はQuadro 4000サポートがなくなっているとの情報もあります。

なお、ESXi5.1の頃は、以下のドライバが使用可能でした。
NVD.NVIDIA_bootbank_NVIDIA-VMware_304.76-1OEM.510.0.0.802205-999851.zip
(NVIDIA-VMware-304.76-1OEM.510.0.0.802205.x86_64.vib)

すでに、Quadro4000はESX6.0用のNVIDIA sVGAドライバでは認識しないとの情報もあることなので、現状Quadro4000は、ESX5.5U3までしか対応していないことになります。

 

ドライバのインストール方法は、この辺とかこの辺とかが参考になります。

現在、ESXi6.0U3へのバージョンアップを検討していますが、Quadro4000が対応していない以上、vSGAをあきらめるか、別のカードを使用するかですが、NVIDIAの対応カードですと最近のビジネス用ハイエンドGPUしか対応しておらず、価格帯も中古でも2桁万円Over、下手すると3桁万円クラスなので、Home Lab用としてはなかなか手が出せません。

こんな情報もありましたが、ちょっと怖いですね。

 

で、色々調査した結果、AMDのFirePro W7000というGPUであれば、
ESX5.5およびESX6.0までの対応であれば比較的入手が楽そうであるとの情報を見つけました。

FirePro W7000 for vSGA情報(VMware Compatibility Guide)

現状、AMD GPUでESX6.5以上ではMxGPUで対応する用で、AMDのvSGAサポートががVMware Compatibility Guideでも認証されていない状況のようなのでESX6.5にあげることはできなさそうですが、どうせESX6.5以上になるとvSphere Client(C# Client)が使えなくなるのでまずはESX6.0にあげられるだけでも助かります(ちょっとvvolをつかってみたいので)。

 

というわけで、FirePro W7000 GPUを入手しました。

ちなみに、ドライバは、以下のものが使用できそうです。

 

esxi5.5用
https://support.amd.com/en-us/download/workstation?os=VMware%20vSphere%20ESXi%205.5#pro-driver
vSGA用ドライバ
fglrx-12103.1135534-1oem.550.0.0.1331820.x86_64.zip

esx6.0用
https://support.amd.com/en-us/download/workstation/esxi6
vSGA用ドライバ
vmw-esx-6.0.0-fglrx-12103.1224202-3638089.zip
vDGA用ドライバ
15.20.1041.1004-FirePro-Guest-Windowsx64-Retail.exe

なお、MxGPU対応ソフトウェア郡(S71x0用)のESXi6.0と6.5用のは以下からダウンロードできる模様です。高くて買えないので、情報だけ。

ESX6.0用
https://support.amd.com/en-us/download/workstation?os=VMware%20vSphere%20ESXi%206.0#pro-driver

ESX6.5用
https://support.amd.com/en-us/download/workstation?os=VMware+vSphere+ESXi+6.5#pro-driver

 

とりあえず、Quadro4000が入っているESXi以外は ESX6.0U3にあげたので、
そのうちFirePro W7000に挑戦して、こちらもあげようと思います。

(参考:https://community.spiceworks.com/topic/1749384-vmware-horizon-vsga-amd-w7000)

 

 

カテゴリー: 未分類 | コメントする

ESXiの仮想マシンのハードウェアバージョンのダウングレード

ESXiの仮想マシンで誤ってハードウェアバージョンをあげてしまった場合、
そのとき仮想マシンを動かしていたESXiのバージョン以下のESXiで動かせなくなってしまいます。

公式には、以下の方法でダウングレードするとなってます。

  • 仮想マシン ハードウェアをアップグレードする前に作成したスナップショットに戻す
  • VMware vCenter Converter Standalone を使用して、[ターゲットの指定] ウィザードで必要な仮想ハードウェア バージョンを選択してコンバート
  • 必要なハードウェア バージョンで新しい仮想マシンを作成し、仮想マシンから既存のディスクを接続。

ハードウェアバージョンをあげる前にスナップショットを取っている場合は戻すだけですが、他の2つを選択した場合でも、いままでのログや稼動情報が消えてしまいますし、ダウンタイムがかなりとられます。

この場合の裏技ですが、実は、ハードウェアバージョンをあげる作業というのは、仮想マシンの定義ファイル(.vmx)のあるパラメータを書き換えているだけだったりします。

ですので、.vmxファイルを直接書き換えれば、ダウングレードできてしまいます。

該当するパラメータは、以下とおりです。

  • virtualHW.version = “11”

この”11″を該当するHW番号に書き換えて保存し、
仮想マシンの編集などをせずにそのまま仮想マシンを起動します。

書き換えるハードウェアバージョンは以下のURLが参考になります。

ESXi/ESX ホストおよび互換性のある仮想マシンのハードウェア バージョンのリスト (2020181)

すると、書き換えた内容が認識され、ハードウェアバージョンがダウングレードされて起動します。

アンサポート的な作業ですが、覚えておくといざとなってときに便利です。

 

 

カテゴリー: 未分類 | コメントする

Z800からZ820へのESXi環境移行&リソース増強完了

先月中旬にマザーボード不良で突然死したHP Z800ですが、
後継機種であるHPZ820を調達し、拡張パーツの移植を行い、一旦暫定対応し、
必要なパーツを取り寄せてどうにか、ハード的に復旧&リソース増強が完了しました。

主な仕様と変更点は以下のとおり

HP Z800 WorkStation HP Z820 WorkStation 備考
CPU Xeon x5690  Dual
[Westmere EP]
(6コアx2CPU, 2.7GHz,)
Xeon E5-2687W     Dual
[Sandy Bridge-EP]
(8コアx2CPU, 3.10GHz)
冷却方式 水冷モデル 水冷モデル
MEM 192GB
(DDR3 Registerd 1333MHz 16GB*12)
256GB
(DDR3 Registerd 1333MHz 16GB*16)
ただし、Z820は1333MHzメモリは未サポート
ストレージアダプタ SATA 3Gbps 6ポート
SAS    3Gbps 8ポート
SATA 6Gbps 2ポート
SATA 3Gbps 4ポート
SAS   6Gbos 8ポート
ストレージ
(VMFS領域)
SSD 960GB
SSD 960GB
SSD 240GB
SATA 4TB x 3
SSD 960GB
SSD 960GB
SSD 240GB
SATA 4TB x 3
一部領域をNexentastorでNFS領域として提供
(RSIDZ 2TBx3で実効領域約4TB)
ストレージ
(NFS仮想マシンへ直結)
SAS 300GB x4 SSD 120GB
SSD 120GB
SSD 480GB
SATA 8TB x4
Nexentastoreでnfs領域を提供
RAID10(8TB x4、j実効領域約16TB)
Logデバイスとして120GBx2
Cacheデバイスとして480GB
NIC GB ether x2
Gb ether x1
GB ether x2  (E1000e,E1001e)
Gb ether x1  (E1000)
2ポートは通常ネットワーク用
1ポートはストレージネットワーク用
Graphiceボード Quadro 4000 Quadro 4000
Quadro K2000
Quadro 4000はブート兼、vSGA用
Quadro K2000はvDGA用(予定)
USBポート USB 2.0 (内蔵) USB 2.0 (内蔵)
USB 3.0 (内蔵)
USB 3.0 (増設)
増設USB3.0ボードはUSB3.0RX4-P4-PCIEで、仮想マシンに直結
OS ESXi 5.5U2 ESXi 5.5U2 ESXi 5.5 U3にアップ予定

こんな感じになりました。

Z800とZ820は、後継機種だけあって、内部仕様やベイの数がほぼ同じなので、その点は楽でした。
ただ、ストレージアダプタのうち、SATA4ポートの認識がZ800と異なっており、ESXi上でHDD上のVMFS領域がそのままマウントせずに、調整が必要だったのが少し大変でした。

これで、もう少し戦えます。

 

カテゴリー: 未分類 | コメントする

厄除け & おかいもの (2018/05/01)

なんかここ半月ぐらいで、お家のいろんなものが壊れまくっている

  • 送風機
    電源入れても起動せず
    ->予備機と交換
  • サーバ(HP Z800:メインESX)
    仕事から帰ったら電源落ちてた。どうやらマザーボード不良
    ->HP Z820を購入し、Z800から拡張パーツを移植するニコイチ修理で回復
  • サーバ(NEC GT110b:サブESX)
    Z820への換装完了後再起動したら、OS立ち上がらず。BIOSでSATAコントローラ認識してない。
    ->予備のNEC GT110bを引っ張り出してきて、ニコイチ修理で回復
  • hdd1台(WDC WD40EFRX)
    ZFSによるRAIDで使用していたがエラーがでてFAULTED状態に。業務影響なし。
    ->同型HDDをAmazonで購入し、交代して対策
  • 部屋の上の蛍光灯照明器具
    紐を引っ張っても、明かりが消えず・・・寝たいんですけど。
    ->引越しのときにあまっていた蛍光灯照明器具と交換。

が、一斉にではなく、1つづつ壊れていっている状況。
既に全部復旧済みですが、 あまりに故障がつづくので、ちょっと神田明神にお参りにいって、「招福除災」のお守りもらってきましたのでマシンルームに飾っておきました。

 

ついでに、秋葉原でお買い物

今回の収穫物

 

ついでに、本日5/5頃に到着予定だったメモリが、5枚ほど到着しました。
DDR3 Registerd 16GB(PC3L-10608R-09-11-E2-03)

4枚をいまZ820に入っている8GB 4舞と交換して、残りは予備予定。
これで、Z820のメモリが256GBになります。

 

さて換装しよっかな

 

カテゴリー: 未分類 | コメントする

仮想環境内で実行中のNexentastorのDisk交換(Raidを組んでいないESXIのDisk交換)

うちの仮想環境では、ESXIの仮想マシンとして、NexentastorというストレージOSを実行し、RAIDとNFS機能をESXiに提供しています。

で、いつの間にか1つのプールがデグレートしていたので、確認と対策です。

RAIDZ-SATA-1のc2t1d0の調子が悪いようです。
修復コマンド[zpool clear RAIDZ-SATA-1]も試してみましたが、少し経つとまたデグレートします。

c2t1d0は、ESXiが直接認識しているSATA HDD上のVMFS5上にあるVMDKが実態です。確認してみます。

実際に調子悪いデータストアは、VMSV03-SATA-5のようです。
この情報は控えておきましょう。
特に、HDD番号、ファイルパス、容量、ディスクSCSI IDは控えておきましょう。

VMSV03-SATA-5を丸ごと交換しますので、このデータストアを使用している仮想マシン名と、割り当てしているVMDKを控えておきます。(今回は、Nexenta仮想マシンの1台のみ)
vCenterで管理している場合は、データストアで割り当てしている仮想マシンの一覧が確認できます。ただ、テンプレートなどは出てこないので、データストアブラウザでも必ず確認しておきましょう。

では、ESXiのデータストアで、VMSV03-SATA-5の情報を確認します。

対象ディスクのIDは、naa.50014ee2ba5bb332のようです。
(esxcli storage vmfs extent listコマンドでも確認できます。)

ESXiのコンソールから、naa.50014ee2ba5bb332の詳細情報を確認します。

VMSV03-SATA-5のDisk(naa.50014ee2ba5bb332)の実態は、
“WDC WD40EFRX-68W”
とのことです。

ESXiのストレージアダプタのところで、naa.50014ee2ba5bb332を探すと、
ストレージアダプタが「Patsburg 4-Port SATA Storage Control」で
ランタイム名が「vmhba2:C2:T0:L0」となっています。

Z820でいうと、内蔵SATAポートのうち、3Gbps対応4ポートの3番目に接続されているHDDですね。

できれば交換用パーツも同型番がよいので、WDC WD40EFRXを用意します。
(Amazonの翌日配送すごく便利)

また、今回のように仮想マシン内でRAIDを組んでいるディスクであれば不要ですが、そうでない場合は、できるだけデータストア「VMSV03-SATA-5」上の仮想マシンデータ(vmxやvmdk)を別のデータストアに待避しておきましょう。
vCenterで管理している場合は、データストアで割り当てしている仮想マシンの一覧が確認できます。ただ、テンプレートなどは出てこないので、データストアブラウザでも必ず確認しておきましょう。
(今回はHDDの死に掛け状態でデータの待避する余裕がありましたが、完全にHDDを認識しなくなる場合もありますので、バックアップやRAID化による冗長化をお勧めします。)

交換用パーツが用意できたら、壊れたHDDを交換します。
HDDのホットプラグに対応していなければ、一度PCの電源断が必要です。

交換したら、ESXiのストレージで、対象のDiskがなくなっていることを確認します。もし、まだあるようであれば、違うDISKを交換したということです。
すぐに正しいDIskと交換しましょう。

では、交換したDiskをストレージの追加からESXiに認識させます。
ストレージから、ディスク/LUNとして追加させますが、ここで注意が1つ。
ESXiをvCenterで管理している場合、以前使用していた「VMSV03-SATA-5」というデータストア名は使用できません。(vCenterで以前のデータストア名に仮想マシンが紐付けされてしまっているため)
とりあえず、「VMSV03-SATA-5-2」と名前を変えて、追加します。

新しいディスクをデータストアとして登録できたら、以前のデータストア「VMSV03-SATA-5」に日も図いていた仮想マシンのVMDKを修正していきます。
vCenterで管理していれば、データストアの「VMSV03-SATA-5」に仮想マシンが登録されていますので、順次該当ディスクの割り当てを変更していきます。
該当ディスクかどうかは、仮想マシンの編集から、ハードディスクをクリックして、ディスクファイルが、「VMSV03-SATA-5」で始まっているものを確認します。状態が認識できていないので、サイズが0となっているのでこちらも確認して、削除しします。

そのまま、Diskを新しいデータストア「VMSV03-SATA-5-2」に割り当てします。控えておいた以下の情報を元に、Diskを以前と同様に追加していきます。
(容量、ディスクSCSI IDは必ず一致させましょう。)

 

すべての仮想マシンのディスク割り当てを同様に修正していきます。
データストアに紐ついた仮想マシンがなくなれば、vCenterから以前のデータストア「VMSV03-SATA-5」が削除されます。

以前のデータストア「VMSV03-SATA-5」が削除されたのを確認したら、今回追加した新しいデータストア「VMSV03-SATA-5-2」を「VMSV03-SATA-5」にリネームします。

これで、vSphereとしては、復旧完了です。

 

Nexentastorで実施しているRAID冗長化は、Nexentastorの仮想マシンを起動すれば、自動的に新しいDISKが挿入されたことを確認して、リビルドが開始されます。
(リビルドが実行されない場合は、NexentastorのWeb GUIからreplaceを実施)

約9時間後にリビルド完了

 

 

(余談)
取り外しした調子の悪くなってしまったHDDですが、別のWindows PCにUSBで認識させて「Crystal Disk Info」で確認してみましたが、そんなにひどい状況ではありませんでした。
・代替処理済みのセクタ数         0
・代替処理保留中のセクタ数    3
・回復不可能セクタ数    3

正直、このHDDをVMFS領域として使用するのはためらわれますが、
NTFSで完全フォーマットすれば一時ファイル領域としてはまだつかえそうなので、NTFSでフォーマットしようとしますが、今の状態ですと領域開放でできません。

VMFS5でフォーマットされたディスクはWindowsからは認識できないのと、
「GPT保護パーティション」がかかっているため、ボリュームの削除ができません。

GPT保護パーティションを開場するためには、DiskPartでコマンドを実行する必要があります。

・Diskpartを起動
・list Disk  (対象ディスクを確認)

・select disk 3     (対象ディスクを選択)
・list partition (確認)
・clean       (保護パーティション属性のクリア)

http://www.atmarkit.co.jp/ait/articles/1106/10/news117.htmlWindowsでGPT保護パーティションを削除する

以上の作業で、VFS領域がクリアされます。
後は、完全フォーマットを実施してみて、smart値が正常に戻ればも儲けものです
(完全フォーマット開始から24時間ほどかかって現在61%完了。)
(この時点でsmart値がすべて正常に戻りました。)
(このHDDはまだがんばってもらえそうです。)

 

カテゴリー: 未分類 | コメントする

ESXiでsmart値の確認

ESXiでDiskのSmart値を確認するには、以下の方法があります。

方法1.esxcliコマンドを使用する方法

データストアのプロパティからも、該当デバイス名を確認します。

データストアの一覧の画面からデータストアを選択して、右クリック->「クリップボードにコピー」からも確認できます。

 

また、esxcli storage core device listからも、ストレージのDevice名を確認できます。

Device名を確認したら、esxcli storage core device smart get -d <デバイス名>でSmart値を確認します。

なお、ストレージやインターフェイスがSmart取得をサポートしていない場合は、以下のように表示されるようです。

 

 

方法2.VMware support取得ツールの一部である Smartinfo.sh を利用する方法

こちらは、ストレージ上のデバイス全部のSmart値を一括表示できます。

 

 

カテゴリー: 未分類 | コメントする

Z820にESXi 5.5用e1001eドライバ (Intel 82579LMドライバ) を組み込む

Z820は、マザーに2つのNICが実装されています。
・82574L Gigabit Ethernet Controller (通称 intel E1000e)
・82579LM Gigabit Ethernet Controller (通称 intel E1001e)

このうち、82579LMは、ESX5.5U3からは標準で認識しますが、
それ以前ですと認識しません。この場合は、個別でvibをインストールしないといけません。

ドライバの入手先は、以下のサイトで可能です。

https://vibsdepot.v-front.de/wiki/index.php/Net-e1000e

実際のインストールは以下の手順になります。

他にもいくつかのドライバーやツールなどがこのサイトにはありますね。
https://vibsdepot.v-front.de/wiki/index.php/Welcome

カテゴリー: 未分類 | コメントする

5/9のWindows Update

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

カテゴリー: 未分類 | コメントする

さらに仮想環境用サーバ壊れました(gt110bサーバ)

メインの仮想環境Z800->Z820の暫定修復が終わったと思ったら、
3台ある残り2台の仮想環境のうちの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 仮想環境

元々、一度電源を落とすと5,6回、多いときだと十数回、電源OFF.ONを繰り返さないと起動できない状況 & マザー搭載VGA機能死亡状態で
3年ぐらいだましだまし使っていたのですが、
電源OFF.ONを繰り返しているうちに、
起動用USBにダメージを受けてしまった&色々試行錯誤しているうちに、マザーボードのストレージコントローラを完全に見失っていて、ジ・エンドとなりました。

ただ、GT110bは発売からすでに10年経っている機種なので、何かあったときに入手困難となる可能性があったので、
共食い修理用の同型機種を2台ほど確保済みだったので、この予備サーバを使って復旧実施。

・保管してあった予備サーバに、CPU,メモリ、ストレージ、起動用USBメモリを移植
・ESXiのアップグレードインストール(ESXi 5.0->5.5、以前のコンフィグを継承するため)

いままで、なかなかふんぎりつかなくて、交換できていなかったのですが、
いざ始めてみたら、交換開始からさくっと2-3時間ぐらいで復旧。
(まったくの同一機種なので、移植は非常に楽。)

ちょうど、GWぐらいに先日暫定復旧したZ820環境にDISK拡張した後に、
この環境もマージできるように各種単体機能テストをしようかと考えていたのだけど、このタイミングで完全に壊れるとは・・・

カテゴリー: 未分類 | コメントする

突然死したZ800の復旧(Z820へのリプレース)

突然死した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のポート2つに挿したSSD2つは認識してVMFS領域もマウントできたけど、
残りの4ポート(3Gbps)が、ブロックSCSI扱いではなく、SCSI扱いになっていて、認識はするけどVMFS領域マウントせず。
どうやらvCenterに昔のVMFS領域のシグネーチャが残っていて、
接続がブロックSCSIからSCSI扱いに変わっている影響で同じシグネーチャでも、違うものとして認識しまったのに、すでに同じVMFS領域名が登録されているため、マウントできない模様

とりあえず以下をしたら、マウントできました。
・vCenterに残っているVMFS領域の名前を変更
・既存のVMFS領域のシグネーチャを更新してマウント
ただ、VMFS領域においてあった仮想マシン&VMDKは再登録する羽目になりましたが(仮想マシン2つ&VMDK6個だけでしたが)。

なお、vCenterに昔のVMFS領域が残っていたのは、その領域を使用している仮想マシン&VMDKが登録されていたためだったようで、それを消したら、昔のVMFS領域は消えました。

もしかしたら、以下の手順のほうが簡単に復帰できたかも知れず・・・
・昔のVMFS領域を使用している仮想マシンをvCenterのインベントリから削除
・DISKを再マウント
・インベントリから削除した想マシンの再登録

とりあえず、これでストレージ系の復旧は完了。データ欠損なし。

あとはNICのMACアドレスが変わっているので念のため以下のコマンドを実行
# esxcfg-advcfg -s 1 /Net/FollowHardwareMac
(ESXは、ESXのインストールを実施したときにNICのMACアドレスをシステムに登録してしまって、NICが変更されても依存のMACアドレスで通信するため)
ただ、コレをやると、仮想マシンごとにを最初に立ち上げるときに「移動」したか、「コピー」したかを聞かれてしまうので、ハードをしないのであれば、しなくてもいいかも。

とりあえず、暫定復旧は完了。
あとは、ちょっとしたグレードアップとして
流用したRIMM 8GBメモリx4を、追加購入予定の16Gメモリx4に変更して合計メモリを256GBにするのと、
SAS 300GBx4を、SATA 8TBx4に置き換えを計画するくらいですかね。RAIDは5にするか10にするかは迷っていますが。

カテゴリー: 未分類 | コメントする

メインのESXサーバ故障中

うちのメインのESXサーバが壊れて、電源が入らなくなってしまった。

Xeon X5690 Dual + メモリ192GB な HP Z800 水冷タイプなのですが、
昼に電源が落ちたらしく、家に戻ったときには電源が落ちていて、電源ボタン押しても、ビープ音が4回なるだけで起動せず。

すべてのPCIボード、メモリをはずしても同じ状況なので、ほぼ故障箇所はマザーボードっぽいのだがさてどうするか・・・・

とりあえず、管理基盤(AD,DHCP,vCenter,監視,)、ファイルサーバ、ネットワークサービス(http,mail,Webストレージ)、SSL-VPN
とかの最小限は、他の2台のESXで稼動させて縮退運用できたけど、
動いているESXはメモリが32GBのサーバが2台しかないので、これまでが限界。

シンクライアントアクセス先基盤と、動画エンコード環境、検証環境系は全滅状態。
やはり、メモリ192GBがいきなりなくなると痛い。

いまのところ回復案として検討中なのが以下の3種類。

・マザーボードだけ購入して、交換
推定予算50K
マザー以外が壊れている可能性があるのと、マザー到着が4/24以降っぽい
あとマザー交換がメンテナンス資料見た限りだとすごい大変そう。

・中古のZ800買ってきて、CPU,メモリ,水冷ユニット,PCIボード,ストレージ系その他もろもろ移植した共食い修理
推定予算100K
ただ、古いリビジョンのマザーだと、X5690乗らないらしいので、その辺の確認しないとだめそう。

・後継機種のZ820調達して、メモリ,PCIボード,ストレージを移植する
推定予算210K
Z800の残念ポイントであるストレージ3GBps制限やジャンボフレーム制限が解除できそうなのと、
CPU世代がWestmere EPからivyBridgeにあげられるのがメリット。
今使っているメモリのクロックが1333なので、うまく動くかは賭けだけど、
早ければ、来週早々には到着しそう。

一番現実的なのは、中古のZ800用意しての共食い修理なんだろうけど。
やはりZ820ルートも捨てがたい。
Z840まで行くと、メモリの流用ができないのと5インチベイ1個少ないからそのまま移植できないし・・・

カテゴリー: 未分類 | コメントする