ソースの表示以前のリビジョンバックリンク全て展開する/折り畳む文書の先頭へ Share via Share via... Twitter LinkedIn Facebook Pinterest Telegram WhatsApp Yammer Reddit Teams最近の変更Send via e-Mail印刷パーマリンク × サーバのESXi化が泥沼化 VMFS-5で物理RDMしてもFreeBSDで3TBのHDDが変な件の続き。 SAS6i/Rを試してみる SAS6i/Rを入手したので、こいつにHDDをぶら下げてPCIパススルーでかつる!!と思いきや、勝てなかった\(^o^)/ パススルーしてみたら、FreeBSDのブートでこけやがる…。デバイスは認識されるもののmpt_wait_req(6) timed outというログが出て先に進まない。非仮想環境だと普通にブートする。 そして、SAS6i/Rには2TBの壁があった・・・orz 搭載されているLSISAS1068Eの仕様のようで、どう足掻いても回避不能。2.2TB超のドライブは先頭2047GiB分しか使えない。ググってるとファーム更新で“support 3TB HDD”的な情報も引っかかるが、3TB HDDを認識するようになったという意味での“support 3TB”っぽいので要注意。1068EなHBA持ってる人は素直に諦めるんだ。君も男なら聞き分けたまえ。 英語力が足らないので間違ってるかもしれないが、3Gbps世代のLSI Logicのコントローラには2TBの壁があると見て良さそう(→この辺)。 さらばSAS6i/R。今どき3TB HDDに対応してないI/Fなんて使えるかああああ!! オンボードSATAをパススルーしてみる というわけで、最終手段、オンボードSATAをパススルーしてみる。 うちの鯖にくっついてるストレージは以下の10台。 システム用HDDx2(RAID-1) データ用HDDx7(3台でRAID-Zにしてストライピング+スペア1台) ESXiのデータストア用SSDx1 これらが、H77(6ポート)、ASM1061(2ポート)、88SE9123(2ポート)の3系統にぶら下がっている。 データストアが繋がってる系統はパススルー出来ない──つまり、HDD9台のうち1台はRDMで繋がざるを得ない。となるとESXiの2TBの壁に当たるが、システム用HDDが750GBなので取りあえずは問題なし。この1台だけda扱いとなり非常に気持ちが悪いが、最早止むを得まい。 H77 SATAとASM1061をパススルーしてESXiを再起動。 ・・・あれ、恒久ストレージが無いってvSphere Clientに怒られてるんですけど。パススルーしてないハズの88SE9123が見えないんですけど。どうなってんだー。 VMFS-5で物理RDMしてもFreeBSDで3TBのHDDが変な件 2TB超のHDDは何かと扱いが面倒だが、ESXiにも2TBの壁があるそうで。 ESXi 5、正確にはESXi 5から採用されたVMFS-5を使う事で、物理Raw Device Mappingの時に限って60TBまでのストレージが扱えるようになった模様(→公式ソース)。ちなみに、他の上限値はconfiguration maximumsでググると出てくる。 そんな事情があったとは露知らず、何の気なしに3TBのHDDを物理RDMしてFreeBSDのVMにアタッチしたら da3: <ATA ST3000DM001-9YN1 CC4B> Fixed Direct Access SCSI-5 device da3: 0MB (no media?) (da3:mpt0:0:3:0): unsupportable block size 0 (da3:mpt0:0:3:0): unsupportable block size 0 … なーんてエラーが出る。容量が0MB?なんじゃそりゃ。 ググってみたものの症例自体あまりヒットしないし、当然解決方法も分からないし、タイトルにあるような結論に至ると。SATA-USB変換器の2TB制限に遭遇した時以来の衝撃だわ。 FreeNAS 8.2.0 BETA 3 sees 3TB ESXi 5 RDM as 0MBを見ると、HGSTのドライブは大丈夫でSeagateはダメ、HBAがオンボードだとダメでLSI Logicだとおkなんて書き込みもあるが、情報が少な過ぎて何とも分からん。 HBAそのものをパススルーしてしまえば回避出来るハズだが、マシンの構成上、どうしてもHDD1台だけパススルーなHBAから溢れちゃうのよねorz PCIeのSATAカードは余ってるがスロットが埋まってるし、完全に詰んだ\(^o^)/。その1台だけRDMという手もあるが、流石に気持ち悪くてやりたくないw SAS6i/Rでも買うかなぁ……SFF-8484ケーブルの方が高く付きそうではあるが……。 VMware Fusion上でVMware ESXiを動かしVMware Fusion上のWindows XP上のvSphere Clientから接続 家鯖を仮想マシン化するべく作業中。うちの鯖は台所に設置してあり、モニターのある所まで持って行くのが面倒なので、VMware Fusionをフル活用してお手軽構築。 まず、VMにESXiのISOとUSBメモリをアタッチして、ESXiをインストール。 次にUSBメモリのESXiをブートしたいが、VMwareはUSBブートに対応してないため、Plop Boot Manager経由でブートして、IPアドレスなどを設定。 最後に、もう1つのVM上のvSphere Clientから接続出来る事を確認して完了。鯖マシンにUSBメモリを挿して完成。うはwwww仮想マシンテラ便利wwwww ………はずだったんだけど、鯖のUSBブートが無効になってて、結局モニターに繋いだ訳ですが('A`)。ついでに、USBブートでも仮想マシンの設定保存のために固定ディスクないしネットワークストレージが必要って事が判明したので、鯖にSSDを増設してESXiを入れ直す事になった訳ですが。 ESXi 5.1からは管理ソフトとして従来のvSphere Clientに代わり、vSphere Web Clientの使用が推奨されてるようになったらしい。ESXi 5.1では仮想マシンバージョンが9になったが、vSphere Client経由ではバージョン8までの仮想マシンしか作れず、そもそもvSphere Clientに結構不具合がある模様。 ならばWeb Clientを使おうと調べてみたら、有償製品であるvCenter Serverがないと使えないっぽい。うーん、ESXiの未来は暗い感じがするな……Xenを使った方が良かったりするんだろうか。 一気に仮想化熱が冷めてしまったでござる。 gptzfsboot error 49 家鯖を久々にモニタに繋いで起動してみたら、ブート時に gptzfsboot error 49 lba 32 gptzfsboot error 49 lba 1 という謎エラーが出てた。なにこれこわい。 直前にHDDのSATAポートを入れ替えたりしてたので「もしかして弾みでHDDをぶっ壊した!?」とビクビクしながらググってみたら、FreeBSDのMLがヒットした。 やり取りによると、49というのはBIOSが返すエラーコードで「No media in drive.」を表すそうな。ZFSブートストラップがリムーバブルドライブを見つけ、かつメディアが入ってない場合に出る警告で、今まで通りシステムがブートするなら無視しておkとの事。 そういえば先日、内蔵のSDカードリーダーをブート候補に加えたので、きっとそのせいだな……。 と言う訳で一件落着。 Portsにnetatalk 3.0.1がキタ━━━(゚∀゚)━━━ !!!!! この問題はnetatalk 3.0.2で修正されました。 FreeBSD Portsのnetatalkが3.0.1になっていたのでインストールした。 前のバージョンはビルドでこけていたが、今回はすんなり入った。 HATさんのところを参考にafp.confを書いて、netatalkを起動。Macからログインユーザーのホームディレクトリにアクセスしてみたら、「Something wrong with the volume's CNID DB, using temporary CNID DB instead. Check server messages for details!」ウィンドウがキタ━━━(゚∀゚)━━━ !!!!! ログを見るとcnid_metad {netatalk_conf.c:1316} (E:Default): getvolbypath(“/usr/home/Decomo”): no volume for pathとのこと。はて、/usr/home/Decomoは間違いなく存在してるんだけどな…。ならばと、basedir regex = /usr/homeにしてみると、今度は共有一覧にホームディレクトリが出なくなってしまった。passwdのホームディレクトリパスは/home始まりだから、マッチしなくなったんだろうね……多分。 他の共有ボリュームも同様のエラーが出たので調べてみたら、netatalk 2とはシンボリックリンクの扱いが変わったっぽい? うちのFreeBSD鯖はMacの流儀に合わせ、/Volumes以下に必要なボリュームのシンボリックリンクを置き、それらを使うようにしてある。netatalkも例外ではなく、/Volumes/XXXXを公開する設定にしていたのだが、これらボリュームで軒並み Somethin wrong… CNID DB と、no volume for pathが発生していた。 pathを実体に置き換える事で問題は無く使えるようになったが、俺的運用では微妙に不便というか気持ち悪い。 てか、この仕様だとFreeBSDで[Homes]を使ったログインユーザー毎のホームディレクトリ共有が無理っぽい気が。 basedir regex = /homeだとgetvolbypathで失敗するし、かといって/usr/homeにするとpasswdからユーザーのホームディレクトリを引けなくなる。オワタ。設定か何かで回避出来るんだろうか…? とりあえず、家鯖は自分一人しか使ってないので、通常ボリュームとしてホームディレクトリを共有する設定にした。最終的なafp.confはこんな感じ。 ; ; Netatalk 3.x configuration file ; [Global] ; Global server settings vol preset = _DEFAULT log file = /var/log/netatalk.log [_DEFAULT] file perm = 0600 directory perm = 0700 ;[Homes] ;basedir regex = (/home|/usr/home) ;home name = $u [Decomo] path = /usr/home/Decomo [Time Machine] ;path = /Volumes/TimeMachine/ path = /zdata3/NFC/backup/TimeMachine time machine = yes vol size limit = 2097152 [Data] ;path = /Volumes/Data path = /zdata3/NFC/data [Public] path = /usr/home/PUBLIC file perm = 0660 directory perm = 0770 < Newer Posts 1 2 ... 62 63 64 65 66 67 68 ... 83 84 Older Posts > start.txt 最終更新: 2022-07-27 15:26by Decomo