DOSブートディスクをWindows64bit環境で作成する

BIOSアップデートがDOSプログラムしかないサーバ用マザーボードで、BIOSアップデートを実施する必要が出た。
そんなわけで、DOSブート環境が必要になったわけだが、USB FDDを使うのではなく、USBメモリを使用したい、ということで調査した。

しばらく前の定番。
hpのUSB-keyメモリからのブート作成ツール
HP Drive Key Boot Utility
  cp006049.exe (45 MB) v7.41.3790.0 (8 Nov 2005)
USB-keyメモリからのシステムブートに関して
  cp004916.exe (28 MB) v7.10.3790.0

こいつをVista 64bit環境で実行したら、管理者権限+互換モードを必要とする、というのはまだいいのだが、
「フォーマット中、プログラムから応答がなくなる」
とか
「フォーマット後、ファイルが見付からない、というエラー出力」
とか
「作成できたもので結局のところブートできない」
とか発生した。
(なお、実行ファイルが日本語ディレクトリとか長いとかかな、と短い場所に置いても同現象)

代替を探したところ「RMPreUSB」がうまいこと動作した。

これの利点
・Portableエディションという、インストール不要バージョンもある
・USBメモリの認識のさせ方を3種類(FDD認識/ZIPドライブ認識/HDD認識)から選ぶことができる
・Free DOSが同梱されていてライセンスを気にしないでDOSブートできる
・DOSブート以外も作成できる

1. RMPreUSBを起動すると以下のような画面が現れる。
001

2. 以下のように、USBメモリが表示されていることを確認する。
005
ここで選択されているUSBメモリの内容が全て削除、フォーマットされ、DOSブートメモリとなります。

3. 「3 Bootloader Options」にて「FREEDOS bootable」を選択します。
002

4. 「4 Filesystem and Overrides」は「FAT16」「Boot as HDD」でひとまずやってみてください。
003
うまくブートしなかった場合は「Boot as FDD」とか「Boot as ZIP」を試してみてください。

5. 「6 Prepare Drive」をクリックするとフォーマット開始です。
004

使わなかったボタンがいろいろありますが、Free DOSのブートディスクを作るくらいであれば、これだけで問題ありませんでした。

ECCエラー多発してるエラーが取れたのでメモ

CentOS6サーバに、2GBメモリが2枚刺さってる。
久々に起動したら、ECC関連のエラーメッセージを吐きまくってるのでメモ書き。

Feb  8 16:42:15 cent6server kernel: EDAC MC0: CE page 0x1e23, offset 0x980, grain 128, syndrome 0x64, row 0, channel 1, label "": i3000 CE
Feb  8 16:42:16 cent6server kernel: EDAC MC0: CE page 0x1e23, offset 0x980, grain 128, syndrome 0x64, row 0, channel 1, label "": i3000 CE
Feb  8 16:42:17 cent6server kernel: EDAC MC0: CE page 0x1e23, offset 0x980, grain 128, syndrome 0x64, row 0, channel 1, label "": i3000 CE
Feb  8 16:42:18 cent6server kernel: EDAC MC0: CE page 0x1e23, offset 0x980, grain 128, syndrome 0x64, row 0, channel 1, label "": i3000 CE
Feb  8 16:42:19 cent6server kernel: EDAC MC0: CE page 0x1e23, offset 0x980, grain 128, syndrome 0x64, row 0, channel 1, label "": i3000 CE
Feb  8 16:42:20 cent6server kernel: EDAC MC0: CE page 0x1e23, offset 0x980, grain 128, syndrome 0x64, row 0, channel 1, label "": i3000 CE
Feb  8 16:42:21 cent6server kernel: EDAC MC0: CE page 0x1e23, offset 0x980, grain 128, syndrome 0x64, row 0, channel 1, label "": i3000 CE
Feb  8 16:42:22 cent6server kernel: EDAC MC0: CE page 0x1e23, offset 0x980, grain 128, syndrome 0x64, row 0, channel 1, label "": i3000 CE
Feb  8 16:42:23 cent6server kernel: EDAC MC0: CE page 0xfb802, offset 0x200, grain 128, syndrome 0x64, row 1, channel 1, label "": i3000 CE
Feb  8 16:42:24 cent6server kernel: EDAC MC0: CE page 0xfab1b, offset 0xa00, grain 128, syndrome 0x64, row 1, channel 1, label "": i3000 CE
Feb  8 16:42:25 cent6server kernel: EDAC MC0: CE page 0xfb8ac, offset 0x780, grain 128, syndrome 0x64, row 1, channel 1, label "": i3000 CE

ちなみに、読み込まれているドライバは以下でした。

# lsmod|grep edac
i3000_edac              3471  0
edac_core              46581  3 i3000_edac
#

ちなみに「rmmod edac」を実行すると、エラーログを出力させなくすることもできます。
(もちろん、エラーがなくなるわけではない)

ESXi5.1でIntel NICを認識するけど使えないという事象

SupermicroのマザーボードPDSM4+を使ってvSphere環境を構築中、悩んだ点が1つ。

ESXi5.0だと特に問題なく動くのに、ESXi5.1にすると、オンボードNICがvmnicとして認識するけれども通信ができない、という症状。
MACアドレス認識するし、IPアドレスも普通に設定できるのに通信ができない。

いろいろ調べたら解消するための事例を発見。
VMWare ESXi, SuperMicro X7SB4, Intel 82573, Network trouble, сетевая проблема」と、その元ネタ「VMWare community」を発見

曰く

・Intel NICのうち82573E/82573Lで認識されているもので発生する
・ESXi 5.1をインストールした後に、ESXi5.0からnet-e1000とnet-e1000eドライバを適用せよ
・ネットワークがつながらないのでUSBメモリでコピーする必要あり
 ・USBメモリはFAT32フォーマット不可。FAT16でフォーマットする必要あり
 ・ESXiにUSBメモリをさす前に「/etc/init.d/usbarbitrator stop」を実行せよ
・「esxcli software vib install -d /vmfs/volumes/datastore1/ESXi500-201207001.zip -n net-e1000e」というような形でファイルはフルパス指定でコマンド実行

で、実際にためした結果、上記以外に以下の注意点もありました。
・ESXiをUSBメモリにインストールしているんだったらLinuxにマウントして直接コピーしてもよい
・さらに新しいESXi5.0のパッチ「ESXi500-201209001.zip」でもokだった。

また、ESXi5.1に最新のパッチ「ESXi510-201212001.zip」を適用しても通信は不可でした。
パッチ適用後、再度、ESXi5.0のnet-e1000eを適用する必要がありました。


2013/03/08追記

正攻法の突破方法として、対応するドライバをコンパイルして使える様にした、という事例を発見しました。

環境さんぷる「ESXi5.1のドライバを作成してみる(intel 82579LM/82574L編)」と、その更新版の「ESXi5.1のドライバを作成してみる(intel I217/I218/82579LM/82574L編)

Intelで公開されているドライバソースから作成したとのこと。
こちらは、VMwareの署名が無いドライバのため、インストールにはESXiの設定変更が必要です。

ちなみに、ここの人、他にもドライバを公開していました。
ESXi5.1のドライバを作成してみる(VIA VT6130/VT6122編)
ESXi5.0のドライバを作成してみる(Silicon Image 3124/3132/3531編)

DELL PowerEdge SC1435につかえるメモリ

DELL PowerEdge SC1435に使えるメモリはSPDに特定の値が記録されている専用メモリじゃないと認識しない、なんて説があるようですが、海外サイトを見るとそうでもないような感じ。
(国内サイトでの言及例:bushimichiの日記 / 長崎大学 長島雅裕のホームページ / kazuhoのメモ置き場)

丁度、hpサーバから出てきたPC2-6400(800MHz) 2GBのメモリが4枚、まとめて入手できたので、さしてみた・・・

・・・・

BIOS 1.4.4(05/02/2008)においては、普通に認識しました。
メモリクロックは800MHzでした。
交換前は667MHzだったんですが、エラーも無しに800MHzになるとは・・・

そんなわけで、メモリ2GBだったマシンが8GBになった上にメモリクロックもアップという結果になりました。

メモリの詳細

メモリ上に貼られたhpシール上のhp P/N: 499276-061
販売されているBOXとしてのhp P/N: 501157-001
P/N:501157-001としての公式スペック:2GB (256MBx4), 800MHz, PC2-6400, Dual Rank (DR) registered ECC DDR2 DIMM memory module
メモリ上にSAMSUNGの製品シールあり
SAMSUNGシール上の記載1行目: 2GB 1Rx4 PC2-6400P-555-12-H3
SAMSUNGシール上の記載2行目: M393T5660QZA-CE7QO

「M393T5660QZA-CE7」で検索すると、メーカOEM版じゃない製品が見付かると思う。

Windows Server 2012とInfinibandによる高速転送について

Interrop 2012でマイクロソフトがWindows Server 2012 Betaを使ったデモンストレーションを展示しているらしい。
Microsoftのtechnet blogのJose’s Briefings, Diagrams and Annotationsより「Windows Server 2012 Beta with SMB 3.0 – Demo at Interop shows SMB Direct at 5.8 Gbytes/sec over Mellanox ConnectX-3 network adapters

内容は、SMB3.0を使用したネットワーク越しでの高速転送技術について。

SMBサーバ側はFusionIO ioDrive2(単独で1.5Gbytes/sec)を4枚並べてストライプ。
そこに、高速ネットワークを使って別のサーバからアクセスして、どれくらいの速度がでるか、というもの。

上記の様な状態で、IO benchmarkを測定すると、以下の様な感じとなる。

テスト内容 サーバ ローカル 10Gbps Ethernet 32Gbps Infiniband 54Gbps Infiniband
512KB IO/8スレッド/8 outstanding
バンド幅 5808MB/sec 1129MB/sec 3754MB/sec 5792MB/sec
IOPS(512KB/sec IOs/sec 11616 IOPS 2259 IOPS 3754 IOPS 11565 IOPS
CPU負荷 ~6.6% ~9.8% ~3.5% ~4.8%
8KB IO/16スレッド/16 outstanding
バンド幅 5103MB/sec 571MB/sec 2620MB/sec 2683MB/sec
IOPS(512KB/sec IOs/sec 525225 IOPS 73160 IOPS 335446 IOPS 343388 IOPS
CPU負荷 ~90.4% ~21.0%
(転送できてないので暇)
~85.9% ~84.7%

( 検証環境の構築手順: Deploying Windows Server 2012 Beta with SMB Direct (SMB over RDMA) and the Mellanox ConnectX-2/ConnectX-3 using InfiniBand – Step by Step )

ま、単純に10Gbps < 32Gbps < 54Gbpsの差、と見ることもできるけど、 512KB IO時のCPU負荷が10Gbpsより低い、というのは、注目ポイントかもしれない。 なぜ、その様なことが発生するのか? それは、Infinibandを使用するSMB 3.0では、RDMAという技術を利用しているから、である。 RDMAは「Remote Direct Memory Access Protocol」の略で、Infiniband環境下では当たり前のように使用されている技術である。 参考文献1:SMB Advanced Networking for Fault Tolerance and Performance
これの5ページ~10ページに詳細が書かれているが、ようはプロトコルオーバーヘッドが少ないから、ということになるのだが、ちょっとここの説明だと理解しづらい。

参考文献2:SMB 2.2. over RDMA

参考文献2を見ると、SMB over RDMA自体はSMB 2.2からサポートしているらしい。
RDMAがなぜ早いのか?という仕組みの説明としてはこちらの19ページと20ページの図がわかりやすい。
実際のデータ転送部分に関しては、直接サーバ上のメモリを参照してもらう、ということで、高速化を図っている、という感じである。

SMB3.0での改善点は他にもあり、上記の参考文献1の11ページ~18ページでは、「SMB Multichannel」という技術の話がされている。
これは、高速転送時、いままでのSMB実装では、1つの転送に対して使用できるCPU coreは1つしかなかったので、CPU coreが頭打ちになると、それ以上は帯域や他のCPU coreが空いていてもそれ以上は早くならない、という問題がある。(参考文献1 13ページ)
それを複数のCPU coreで処理を担当できるようにする、というのがSMB Multichannel。
SMB Multichannelにより複数NICを使った場合の分散処理もかなり改善される。

(訂正: 参考文献3 SMB 2.2: Bigger, Faster, Scalier (Part 1)を見るとSMB 2.2からあるようだ)

参考文献4 The basics of SMB Multichannel, a feature of Windows Server 2012 and SMB 3.0
という記事があがり、Multichannelとかの機能について解説されている。