ラベル ESXi の投稿を表示しています。 すべての投稿を表示
ラベル ESXi の投稿を表示しています。 すべての投稿を表示

2017/12/16

esxtop のご乱心とその対処法について

vSphere の管理をしていると、vSphere Client などGUIからではらちがあかず、SSH でログオンして様々なコマンドで状況を確認、解消する事もよく出てきます。

特にパフォーマンス問題で力を発揮するのが esxtop コマンドです。Linux, UNIX の top コマンドのように仮想マシンや関連プロセスの稼働状況、IOの状況を表示、定期的に更新してくれる優れものです。
esxtop : とくにパフォーマンス問題で無くてはならない管理者の友です
ただ、様々な端末を使っていると、ときにこの esxtop の表示が乱れたり、vi や less が下記の画像のような表示をして正しくスクロールしてくれなくなる事があります。
esxtop ご乱心!

terminal is not fully functional のメッセージ
リターンを押すと一応表示されるが、若干挙動がおかしくなる

これはどうしてかを簡単に調べてみました。

● 端末画面制御

esxtop や vi, less といったコマンドの特徴は、ただ出力のテキストを垂れ流すのではなく、画面の任意の位置を書き換え、適切なところに表示を行おうとする、事です。こうした端末画面の制御のためのデータベースとして、termcap と terminfo があります。とか言うと何故画面制御にデータベースが関係する? となりますが、これはUNIXと「端末」の歴史にもつながってきます。

60年代やそれ以前、極めて初期のコンピュータでは出力は「紙」でした。プログラムからの出力は紙に印字されて出力されていました。その後にブラウン管への出力に移っていきましたが、ごく初期のブラウン管の出力とキーボードなどの入力の組み合わせた機械、すなわち「端末」(Terminal)では、やはり出力をそのまま、左から右、上から下へだだっと垂れ流すしかできませんでした。これを「ダム端末」と呼ばれてました。dumb=馬鹿とかのろまとかという意味で、まあシリアルケーブルなどを通じて送られてきたデータをただ垂れ流し表示するだけ、なんの能もないからそういう名前になったようです。

少し時代が経つと、少し賢い端末がでてきました。ダム端末に対してこれらは「インテリジェント端末」とも呼ばれました。インテリジェント端末の定義は時代により様々ですが、出始めの場合、文字に色がつけれる、Tektronixと言う会社の端末のように グラフィックの表示機能を備えたものとかがインテリジェント端末と呼ばれました。
(後にはパソコンベースの端末でローカルでのアプリケーションの実行やそれとホストとの連携ができるもの、などがインテリジェント端末と呼ばれるそうですが、私はこの頃はよく知りません。)

インテリジェント端末の時代になってただ出されたテキストを垂れ流しで表示するのではなく、文字の色を変えたり、画面の任意の位置にカーソルを動かして「左から右、上から下」ではない順序での表示が可能になりました。

このような画面の操作を行うのにつかわれたのが「エスケープシーケンス」などと呼ばれる一連のテキストです。これは出力のテキストに混ぜて送られ、送られた文字をただ表示するのではなく、その文字列が指示する動き、例えば次の文字を赤く表示する、カーソルの位置を上から20左から30に移動させる、を実施しました。ちょうどHTMLのタグみたいなものです。この一連のコードはエスケープ(0x1B)を先頭にする場合が多かったこともありエスケープシーケンスと呼ばれました。

エスケープシーケンスは後にISOの共通規格にもなりましたが、問題は、インテリジェント端末の出始めは必ずしも端末のエスケープシーケンスが同じ、ではありませんでした。ホスト上で動くソフトウェア、例えば vi とか esxtop、が次はカーソルを左上に動かして強調文字で「ABC」と書きたい、とか思っても、端末ごとに送るエスケープシーケンスは異なる、端末ごとにアプリ側で対応が必要となりました。ホストに繋ぐ端末機器を変えるたびにアプリ側の設定変更(あるいはコードの修正)が必要になりました。

これは不便だと登場したのが BSD UNIX の「termcap」というデータベースです。/etc/termcap というファイルに、端末ごとのエスケープシーケンス、カーソルを上に動かす時はこう、色を変える時はこう、っという定義を記載、環境変数 TERM によりどの端末の種類かを定義、esxtop のようなアプリケーションはTERMの端末種別を元に termcap から適切なエスケープシーケンスを読み出し、適切な操作ができるようになりました。
環境変数TERM
SystemV では terminfo というほぼ同じ仕組みが作られました。termcap との違いは「termcap はテキストで人が読める」「terminfo はテキストの定義を元にバイナリに変換、アプリからの読み込みが手っ取り早い」と、まあその程度です。

なお、いまどきの Linux, UNIX では terminfo の方を使うのが一般的となってます。

Windows の TeraTerm Pro や Putty といったソフトウェアは、SSH や TELNET といったプロトコルで通信する機能を提供する一方、エスケープシーケンスを解釈し適切な表示を行う「端末」の役割も果たしてます。このため端末エミュレータとも呼ばれます。分かりやすいのは macOS の「ターミナル」や Ubuntu Linux などのターミナルアプリで、これらは「端末」としての表示のみを担当、SSH での通信は ssh コマンド、TELNET での通信は telnet コマンド、が担当しております。

余談ですが Windows 8 から 10 にかけて、ウィンドウズのコマンドプロンプトウィンドウもかなり機能強化されましたが、その一つとして端末エミュレータとしての機能強化もあります。マイクロソフト自身が OpenSSH を移植、Windows10 への標準搭載化を進めていますので、端末エミュレータとしての機能の受け皿が必要になった、というのもあります。

閑話休題、ともあれ termcap ないしは terminfo というデータベースを通じて端末の形式から正しいエスケープシーケンスを調べだし、適切な画面の制御ができるようになっている、というのが Linux, UNIX の端末画面制御になります。

なお、terminfo の情報は通常、/usr/share/terminfo 以下にあります。コンピュータの処理能力が非力だった時代からあるため、負荷軽減と検索の高速化のため、terminfo フォルダの下にサブフォルダを作成、1ファイル1端末種別 でファイルが格納されています。
macOS 10.12.6 Sierra での terminfo の設定ファイル数
1ファイル=1端末種別のため、約2600の端末機器に対応...ほとんどは使われないと思うけど。
macOS の場合、terminfo 以下には 2563ファイル存在、つまり 2563種類の端末に対応しています。

また、「ターミナル」アプリケーションでは、以下画面の10種類の端末形式に対応しております。
Mac の場合、ターミナルアプリのプロファイルにて、
プロファイルごとにどの端末の種別かを設定できる

vt100 はハードウェアだった端末でのデファクトスタンダードで、vt100互換、つまりvt100と同じエスケープシーケンスを受け付ける端末ハードウェアが多かったと伺っております。また、xterm は X Window System に付属のターミナルソフトで、rxvt は xterm を元に軽量化させたもので、一時期 流行ってたのを記憶しております。
( なお、私は NeXT(標準ターミナルアプリケーション) -> UX/OS(kterm) という流れで以降は Mac か Windows を端末に Solaris や Linux にリモートアクセスなので、xterm を少々使った事があるぐらいです。)

大まかに有名どころの端末のエスケープシーケンスに対応していると言えます。
この「ターミナルの宣言方法」を切り替えてから新規ターミナルウィンドウを開くと、環境変数TERMはその値に設定され、そして若干挙動がかわります。例えば、vt100 と xterm でそれぞれ less を実行、終了すると分かりやすいと思います。


● ESXi の端末情報データベース

さて、ようやく本題です。
ESXi Shell の環境も概ね Linux, UNIXの仕組みを継承しています。画面制御については実は terminfo を使っています。ではどれだけの端末の種類に対応してるでしょうか...。

ESXi Shell 環境での端末の種別。5行、すなわち5ファイルで、5端末種別、だけ...。
はい。たった5種類の端末にしか対応していません。内訳を見ると、screen, xterm, ansi, linux, vt102 です。screen は端末切り替えソフトの screen を使用の際に使われるもの、linux は Linux 起動時のコンソールで利用される端末の種別で、実際、コンソールでの ESXi Shell では環境変数TERM は linux に定義されています。
ローカルコンソールでの ESXi Shell
環境変数が linux になってるのが分かる
つまり、ssh接続などで一般的に使われる端末エミュレータとしては、xterm か vt102 しか対応していない、といえます。
Mac のターミナルアプリケーションのデフォルトの端末種別は「xterm-256color」です。ssh コマンドはデフォルトでローカルの環境変数TERMをリモートにも伝えてくれます。つまり ESXi にログインした場合、環境変数 TERM は xterm-256color が設定されますが、これは ESXi 側の terminfo に存在しない端末種別のため、esxtop のように画面制御ができずダム端末のようにテキストを流し込んでくるか、冒頭の less のように「制御できないけど、いい?」って聞いてくるようになります。

● どう対処すべきか

このような問題が生じている場合、簡単なのは送付する環境変数TERM を変えてしまうと言う事です。
例えば、以下のように env コマンドで環境変数TERMを xterm に変更後 ssh コマンドを実行すると、ESXi 側では xterm-256color ではなく xterm として扱ってくれます。

env コマンドで環境変数TERMを再設定してから ssh
結果、再設定したTERMの値が伝えられる
xterm-256color と xterm は、色に関するエスケープシーケンスが違うだけで互換性がありますので、このような無茶も通ります。

あとは、そもそも端末エミュレータ側の端末種別を xterm か  vt102 に設定してしまう、というのもあります。

この手の問題をググると、「だったら terminfo に設定追加すれば良いじゃん」的な答えが散見されますが、残念ながら ESXi Shell の環境には tic コマンド(terminfo でテキストの設定からバイナリの設定にコンパイルするコマンド)が存在しないので、やるとすると少々面倒です。また、ESXi Shell 環境というかあのファイルシステムにあまり独自のファイルを置くのはあまり推奨されません。やるなら tardisk とか ramdisk の仕組みをよく調べて、ESXi の動き、何処のファイルが温存されどれが消えうるかを確認、これらの意味をよく分かった上で実施すると良いでしょう。

ともあれ、vSphere の管理者にとって esxtop が使えない環境は最悪です。環境変数TERMをうまく扱う事でそんな環境はなくしていきましょう。


最後に、個人的な感想ですが、「いや、vt100互換が実際には vt102互換である事ぐらいは知ってるけどさ、何も馬鹿正直に vt102 だけを置いて vt100 を置かないってのもないんじゃねえの?」とか思いましたよ、ええ。


2017/08/31

仮想マシンとハードウェアクロック

PCの中には時間を刻むハードウェアが内蔵されており、今が何月何日の、何時何分何秒かを把握しております。歴史的な事情からこのハードウェアは単一ではなく、複数のものが存在していたりします。かつては RTC (Real Time Clock)という仕組みだけでしたが、これがあまり精度が良くなかった、使い勝手が悪かったなどの理由で HPET が登場し、CPU には TSC というタイマーが用意されたのでこれを使って時刻を図ることが行われ、また ACPI には ACPI PMT というこれまた時間を計る機能が存在します。

ともあれ、OS は起動時にPCハードウェアのこれらの時計から時間を取得、カウンターを利用して、取得後どれぐらい経過したかを知り、OS自身で時間を管理しております。
例えば Linux の場合は、OSの終了時に hwclock コマンドを使ってPCのハードウェア側にOSが把握している時間をかき込みます。Windows などの場合もおそらくOS終了時に時刻を書き戻しているでしょう。この理由は、PCのハードウェア上の時刻はずれていることがままあるためです。

この PC上のハードウェアの時計は「どの時間帯」の時間を記録しているでしょうか?実はこれは決まっていません。ほとんどの場合、ハードウェアの時計はローカルタイム、現地時間を記録してます。一方、ハードウェアの時計が UTC(世界標準時) であることを前提としているシステムもあります。例えば ESXi がそうです。ESXi は物理ホスト上のハードウェアの時計に UTC での時間をかき込み、起動時も UTC であることを前提に読み込みをします。

一方、Windows や Linux では、OSの内部では UTC をベースに構成されていますが、時刻の表示時には指定されたタイムゾーンを加味して現地の時間を表示しております。ハードウェアの時計に対しても、ローカルタイムがかき込まれているものと考えるのがデフォルトとなってます。先の hwclock コマンドも、OSから読み出した時間を /etc/localtime ファイルの示す時間帯を考慮した現地時間でかき込みます。


● 仮想マシンの時間

VMware の場合、初回起動時には ホストOSの時間がそのまま使われます。VMware Player や Workstation, Fusion では、新しい仮想マシンを作成して起動、BIOS設定画面に入ると現地時間での時刻が表示されます。
かつての ESX でもそうでした。ESX の場合、COS(サービスコンソール) の Linux 上の /etc/localtime を参照して仮想マシンの仮想的なハードウェアの時計に「ローカル時間」をかき込んでました。
ESXi の場合、/etc/localtime のようなタイムゾーンを把握する枠組みがありません。vSphereClient などで時間を見ると現地時間が表示されますが、これらはクライアントソフトウェア側で変換して表示しているもので、ESXi との時間のやりとりは UTC をベースとしています。

このため、ESXi で仮想マシンを作成、初回の起動時にBIOS時間を見ると、UTCで表示されます。日本の場合、9時間前の時刻が表示されていることになります。

新規に作成した仮想マシン
17:42 頃のものだが、8:42となっており、初回起動時は9時間ずれてるのが分かる
二度目以降の起動では少々事情が異なります。ゲストOSが終了時に(仮想の)ハードウェアの時計に時間を設定した時、VMware はそのかき込まれた時間と自身が把握している時間を比較、「差分」を検知します。ESXi の場合、上のOSが「日本時間」をかき込んでくると、9時間早い時間がかき込まれたことを検知します。この差分は nvram ファイルに保存されます。

二度目以降の起動時は、自身の時刻にこの差分を加味した時刻を、仮想マシンのハードウェアの時計としてセットします。先の例の場合、UTCに9時間を加えた時刻をハードウェアの時計とします。これは日本時間になります。ゲストOSはこの時間を読み込みますので、結果として正しい時間になります。
この挙動は VMware のこのドキュメントの「Virtual CMOS RTC」に記載されています。


● 他のハイパーバイザの仮想マシン

Hyper-V の場合は Windows の時刻管理に準じるためあまり深いことを考える必要がありません。

今回、この記事を書く動機になったのは KVMについてのハードウェアの時計がどうなってるかを調べたことからでした。KVM では、仮想マシンのモニタである qemu-kvm コマンドの引数 -rtc にどう設定するかによって決まります。主に以下2つのオプションが使われます。

  • clock : 時刻を何処で管理するか
    • clock=vm : 仮想マシン側で独自に時刻を管理する
    • clock=host : ホストの時間をそのまま利用する
  • base : 仮想マシンの起動時、(仮想の)ハードウェアの時計を何処に設定するか
    • base=2010-12-03T01:02:00 : 2010/12/03 01:02:00 に設定する
    • base=utc : UTCでの現在時間に設定する
    • base=local : ホストOSのタイムゾーンを加味した現地時間に設定する

OpenSUSE のドキュメントの例をみると
qemu-kvm [...] -rtc clock=vm,base=2010-12-03T01:02:00
となってますが、これは「時刻は仮想マシンで独自に管理」「2010 12/03 1:02:00 をハードウェアの時計の開始時間」として設定することを意味します。

(AHVについては記述が誤っていたため一旦削除しました。あらためて正しい情報を書きます。)

2016/12/08

vSphere 上での Nano Server のインストール

この記事は、vExperts Advent Calendar 2016 に参加しています。


Windows Server 2016 では Nano Server と呼ばれる、軽量化されたOSが含まれています。Windows Server 2016 をベースに新しいアプリケーションやインフラストラクチャーを対象に、そのための機能に研ぎ澄ましたもので、稼働させるだけなら数百MB程度のメモリとディスクがあれば動きます。

Windows Server 2016 そのものも 512MB が最低必要量になってますが、インストール時には 800MB 程度、デスクトップエクスペリエンスを備えるならやはり 2GBが必要となります。ストレージ容量なら32GBが最低容量となります。

一方、Nano Server は「研ぎ澄まされ」ているため、用途としては不適となります。たとえばローカルコンソールで操作できることは本当に最低限のため、リモート管理が必須となります。役割や機能もフルインストールの Winodows Server がサポートするものが全てサポートされるわけではありません。ライセンスから見ても、アップデートがCBBモデルなのもありSAが必須となります。

こうしたことから、インストーラーでぽんとインストールできるわけではありません。

Windows Server 2016 のインストーラーでは、デフォルトのの Server Core か、
デスクトップエクスペリエンス付きかの選択肢しかない

むしろ、インストールしてから用途に向けてセットアップしていくのではなく、コマンドラインで
「必要な機能を組み込んでいく」必要があります。

インストール手順自体はこちらにありますが、少々敷居の高いものとなっています。
では、VMware の仮想マシン上にインストールするにはどうすればいいでしょうか? ちょっと試してみました。

● EFI か、BIOSか?

まず最初に決めるべき事は、ファームウェアを従来のPC-BIOSか、UEFIにするかです。PC-BIOS
はこれまで使われてきたファームウェアで、リアルモードで動作するものになります。UEFI はより新しいファームウェアで、ブート前の状態でより多くの機能を提供できるものです。

Nano Server をインストールするにはどちらでも構いません。多くの VMware 製品は普通に仮想マシンを作ると PC-BIOS を設定します。VMware Fusion については macOS をゲストOSにしない限り、EFI は選択されません。(ユーザーインターフェイスから設定できない。ただし vmx ファイルを直接書き換えることで設定可能)

ここでは、最初に BIOS でのインストールを、次に EFI でのインストールを試してみます。

● Nano Server のインストール (BIOS編)

まず、仮想マシンを作成する。特に普通に作れば良い。今回はメモリは 1GB程度にしました。
仮想ディスクのサイズも1GB以上ならば問題ありません。

ESXi の仮想マシンのプロパティ
「リソース」の「起動オプション」にてファームウェアの指定が可能


注意点としては、ゲストOSとしては「Windows Server 2016(64bit)」を選択すると言うことぐらいです。

仮想マシンの作成画面より
OSは Windows Server 2016 (64bit) にする

できあがった仮想マシンに Windows Server 2016 のインストールメディアを認識させ、こちらから起動します。
Windows Server 2016 のインストールメディアから起動
通常はここでキーボードや言語の選択を行いウィザードを進めるが
Nano Server の場合はここで一旦停止

この画面が表示されたところで「SHIFT+F10」をおす。すると、コマンドプロンプトウィンドウが開きます。

Windows Server のインストールメディアでは、SHIFT-F10 でコマンドプロンプトウィンドウが開く
ここでは、D: ドライブの内容を dir で確認している

デフォルトの状態では、X:ドライブに一時的な起動ドライブが作成されております。インストールメディア自体はD:ドライブにマウントされており、初期状態では仮想ディスクはフォーマットもされていないため、どこにもマウントされていません。
D:\NanoServer フォルダ以下に、Nano Server の素の状態のイメージ(NanoServer.wim) と、デバイスドライバや役割、機能を備えたパッケージ(*.pkg)があります。


さて、ここからインストールを行います。インストールで行わなければならないことは、以下の4つです。

  1. ディスクのパーティション作成と、フォーマット
  2. Nano Server イメージの展開
  3. その他必要なパッケージのインストール
  4. 起動パーティションとして指定

・パーティションの作成

パーティションの作成とフォーマットは diskpart コマンドで実施します。まず、「diskpart」と入力し実行して、diskpart コマンドを起動します。このとき、「DISKPART>」のプロンプトが出ずハングする場合があります。その時は Ctrl-C をおして diskpart コマンドを終了し、しばらく待ってから再度実行するとプロンプトが出てきます。

diskpart コマンドを実行

DISKPART> のプロンプトが出たら、以下のコマンドを実行します。
  • select disk 0
  • create partition primary
  • format quick fs=ntfs label="nano server"
  • assign letter=c
  • active
select disk 0 で接続されている最初のドライブを選択します。
次の create partition で選択されたドライブに新しいパーティションを作ります。このとき、 primary を指定することでMBR のプライマリパーティションとしてパーティションが作成されます。
(MBRでは、そのままだと最大4つのパーティションしか作成できない。これらを「プライマリパーティション」と呼ぶ。4つ以上パーティションが必要な場合は、そのうちどれかを入れ子にして、別途パーティションテーブルを作成、分割する。この入れ子で作成されるパーティションを「論理パーティション」と呼ぶ )


上記コマンドに従い、パーティションを作成、フォーマットを実行
最近?の diskpart では、作成したパーティションが選択された状態になっているので、そのまま fomat コマンドを実行することで作成したばかりのパーティションをフォーマットします。fs=ntfs でntfsを選択、ボリュームラベルは nano server を指定、quick を付けることでクイックフォーマットを行ってます。
assign letter=c で、このパーティションを「C」ドライブと名付けます。名付けた時点で C: でアクセスが可能になります。

最後が重要です、active を実行することで、MBRに「このパーティションから起動する」という指名をします。この操作をしていないと、起動パーティションが分からずブートに失敗しますので注意してください。

起動パーティションを指定
list partition で先頭に*があるのがそれだ


終わったら、DISKPART> のプロンプトで exit を入力する、もしくは Ctrl-C で終了できます。

・Nano Server イメージの展開

空のC:ができたところで、ここにOSのイメージを流し込みます。
まず、カレントディレクトリを d:\NanoServer に移動しておきます。

ここで、以下コマンドを実行します。少々長いので打ち間違いに気をつけてください。

  • dism /apply-image /imagefile:.\NanoServer.wim /index:1 /applydir:c:\

dism コマンドでWIMイメージを展開

dism.exe は WindowsVista から用意された、Windows の展開イメージの管理コマンドです。インストーラーが使用する WIM形式のイメージや仮想ディスクイメージである VHD/VHDX形式、それからディスクに展開された Windows のシステムを管理することができます。

ここでは、imagefile で指定した WIM形式のイメージを applydir で指定したパスに書き出しています。/index:1 は、WIMイメージの2つめのボリュームを対象にしていることを指します。このWIMイメージの中にはEFIシステムパーティションがあるので、C: に相当するのは二つ目の(0オリジンで1の)ボリュームだからです。

dir c: とかすると、Program Files や WINDOWS など、おなじみのフォルダが展開されているのが分かります。

・その他必要なパッケージのインストール

このままでは Nano Server そのものしかインストールされておらず、起動する以上の意味を持ちません。追加のデバイスドライバや役割、機能をここでインストールします。

CABパッケージの追加インストールには、dism /add-package を使用します。
パッケージは d:\NanoServer\Packages フォルダの下に格納されております。

ここでは、d:\NanoServer\Packages フォルダにカレントディレクトリを移動させた後、Microsoft-NanoServer-OEM-Drivers-Package.cab を追加しています。

  • dism /add-package /packagepath:.\Microsoft-NanoServer-OEM-Drivers-Package.cab /image:c:\

add-package ではインストール先の「システムイメージ」を指定しますが、ここでは c:\ 以下に展開されたイメージが対象のため、c:\ としています。

パッケージを追加
警告が気になる場合は、2GB以上のディスクを用意する事

ここではディスク容量が小さく作業領域(ScratchDir)が小さいせいで警告が出ています。確かに、今回ディスクサイズを1GBにしたので、イメージを展開した分容量が取られており、空き領域が 1GBを切っています。仮想マシンのディスクサイズをそもそも2GB程度にすればこの警告は生じませんし、今回のように強行しても、1個ぐらいのパッケージなら問題なく展開できたりもします。

VMware 上の仮想マシンの場合、この Microsoft-NanoServer-OEM-Drivers-Package.cab は必ず入れてください。この中に LSI Logic の SCSIドライバなども含まれているため、このパッケージを追加しないと、OS起動後に C:ドライブをマウントできず、BSODになります。

その他の役割については、こちらのページを参照してほしい。「Creating a custom Nano Server image」の項目にある表が、概ね機能と対応するパッケージになります。厳密にはこの表は、事前にパッケージを組み込んだ NanoServer.wim を作るために使用する New-NanoServerImage コマンドレットの引数になってますが、たとえば Hyper-V の役割をインストールするための「-Compute」なら、「Microsoft-nanoServer-Compute-Package.cab」とか類推がつくかと思います。

また、c:\NanoServer\Packages フォルダの直下だけではなく、言語ごとのフォルダもあります。日本語の場合、c:\NanoServer\Packages\ja-jp というフォルダがあり、同名のパッケージがあるのでこちらもインストールしておいてください。
(ただし、NanoServer のコンソール画面は英語しか表示できないため、ローカルコンソールでの日本語関係は化けてしまいます。)

・起動パーティションとして指定

さて、最後に起動パーティションとして指定します。これは、bcdboot コマンドを使用します。

  • bcdboot c:\Windows /s c:

bcdboot でブートローダーの設定を作成


bcdboot.exe もまた WindowsVista から導入されたコマンドで、winload によるOS起動を制御します。ここでは、c:\Windows から Windows  を起動することを指定しています。その設定は c: に、つまり同じドライブに書き込まれます。

実のところ、これはちょっとした手抜きです。Windows をGUIからインストールした場合は PC-BIOS の場合も先頭に100MB程度のシステムパーティションが作成され、こちらに OS起動の設定が書き込まれます。UEFIの場合、EFIシステムパーティションが必須であり、こちらで認識する必要があるから別パーティションを用意する必要はあります。

一方、PC-BIOS の場合はその必要性はさしてないですし、仮想マシンの場合固定したOSを固定したパーティションから起動する、せいぜい起動オプションを変えたモードを用意するぐらいですので、これでも問題ない、という判断からです。
なお、Microsoft のページでも、「不要なら削除して構わない」となってます。

気になる方はシステムパーティションを作成し、/s の指定先をそちらにした方が良いでしょう。

bcdboot で設定が正しく書き込まれたかは、bcdedit コマンドで確認できます。
  • bcdedit /store c:\Boot\BCD
bcdedit コマンドでブートローダーの設定を確認
bcdedit 単体で実行すると、現在起動したOS(この場合はX:)の設定を表示するため、
ここでは /store でどこにある設定を読み込むかを指定している

Windows ブートマネージャー の項目が、ブートマネージャーそのものの設定、たとえば表示言語(ここではen-us)などが表示されます。ブートマネージャーの default に表示されている Identifier の項目が起動時に使われます。また、次の displayorder に複数の Identifier が表示されている場合、この順でメニュー表示され、どの設定から起動するかを選択することができます。メニューを表示して何秒待ったら起動するかは、timeout に設定されます。

ここでは {default} という Identifier の設定が一つだけ、 Windowsブートローダーの項目に表示されています。

詳細な内容については、こちらのページもあわせてご参照ください。


さて、これで準備は終わりました。コマンドプロンプトウィンドウを閉じて、下のインストーラーのパネルを閉じる事で再起動されます。または、コマンドプロンプトウィンドウから「wpeutil reboot」コマンドを実行する事でも再起動が行われます。

再起動後、HDDから起動が行われ、Nano Server が起動してきます。

Nano Server 起動中
ブートローダーはフルインストールと同じためここだけはグラフィカルだ


Nano Server 起動。
本当に何のUIもなく真っ黒だった 以前のTPと異なり、
TP5やリリース版では最低限のUIはついた。本当に最低限だが

初期状態では Administrator にパスワードが入っていませんので、ユーザ名に Administrator を指定してリターンをたたくと、初期パスワードを入力を要求されます。

ここで Administratror のパスワードを設定

DHCPから採取された IPアドレスなどは画面に表示されるので、あとはRSATを使って管理する、または SMTを使って管理するなどで、Nano Server を扱うことができます。
( Azure 管理コンソールで Windows Server もまとめて管理できる SMT は、マイブームだったり(笑) )

Networking を選択、リターンを押すとIPアドレスの設定が確認できる

● EFI の場合は?

PC-BIOS と EFI で異なるのは、ブートの手順になります。
BIOSの場合は、MBR に記載されたシンプルな一次ブートローダーがアクティブに指定されたパーティションの二次ブートローダー、つまりは winload を呼び出し、winload が bcdboot で記入した設定を読み込み、ブートします。MBR に入れることができるブートローダーはリアルモードかつ容量も限られているので、winload そのものを入れるのではなく、二段構えになっています。

EFI の場合は、 EFI システムパーティションに組み込まれたブートローダーがOSを起動します。Windows の場合は EFI に winload が存在し、これが Windows を起動します。EFIシステムパーティションは100MBないしそれ以上あり、EFIがブートローダーに提供する機能も BIOS に比べ張るかに高機能なことから、winload が直接利用できるわけです。

このことから、二つの部分がかわってきます。
一つはパーティションの作成。GPTパーティション形式にした上で、EFIシステムパーティションを用意する必要が出てきます。
二つ目は、bcdboot での指定。BIOSの場合は winload も bcdboot の設定も c: にごっちゃに入れてましたが、EFI の場合は /s で指定する格納先は EFIシステムパーティションになります。

では、手順を見てみましょう。

最初に重要なのは、仮想マシンを作成したら「ファームウェアをEFIにしておく」事です。ゲストOSの設定にもよりますが、Windows Server 2016(64bit)を選択してもデフォルトはBIOSになってます。

仮想マシンのプロパティの「オプション」「起動オプション」で
ファームウェアをEFI にして、OKを押す
そこからインストールメディアで起動し、diskpart を起動するところまではBIOSとわりません。

Windows Server 2016 のインストールメディアから起動
ここからコマンドプロンプトウィンドウを出すところは同じ

実行する DISKPART のコマンドが少し変わって、以下になります。
  • select disk 0
  • convert gpt
  • create partitoin efi size=100
  • format quick fs=fat32 label="System"
  • assign letter=s
  • create partition msr size=128
  • create partition primary
  • format quick fs=ntfs label="nano server"
  • assign letter=c

select disk0 で1本しか繋いでいない仮想ディスクを選択するところまでは一緒です。
次の convert gpt でパーティションの記録形式をデフォルトのMBR形式から EFI で使用する GPT パーティション形式にしておきます。

次に、create partiton efi で、EFIシステムパーティションを作成しておきます。GPTパーティション形式では、内部的には UUID でそのパーティションがどういうものかを記録しております。が、一々 長い UUID を入力するのは人間業では辛いので、「efi」というシンボルで EFIシステムパーティションであるというUUIDを入れてもらっている訳です。なお、size=100 は 100MiB のサイズで確保する事をさします。create partition でサイズ無指定だと開いてる所全部、となります。

その後、FAT32形式でフォーマットします。EFIシステムパーティションの実体はFAT32のため、FAT32でフォーマットする次第です。ボリュームラベルは Windows のデフォルトインストーラにあわせて「System」にしています。

また、ここでドライブレター「S」を割り当てております。EFIシステムパーティションはOS起動後はマウントされない、不可視のものですが、ここではBCDの起動設定を入れなければならないので、邪魔にならないところにマウントしている訳です。

EFIシステムパーティションの作成。
なお、EFIシステムパーティションを略してESPと呼ぶこともあります。
続けて、「create partition msr size=128」で MSR を128MiBで確保してます。MSRは、Microsoft 予約パーティションの略で、他のシステムパーティションに関する情報が格納される、とあります。(どうも、Reserved の R ではなく Recovery の R ではないのか?って気はするけど、さておき。)

ともあれ、EFIシステムパーティションの次、C: ドライブとなる Windows パーティションの前に配置することになってます。これはパーティションが存在すれば良く、フォーマットしたり一時的にドライブレターを割り当てて中に何かかき込む必要はありません。

さて、三つ目がプライマリパーティションで、要は Windows をインストールするパーティションです。パーティション作成後、NTFSでフォーマットして、C:をアサインしてます。

なお、BIOSでの起動(MBRパーティション形式)の時と異なり、active でアクティブパーティションを決める必要はありません。EFIは必ず、EFIシステムパーティションを見に行き、そこのブートローダを利用する、どのパーティションから起動するというのはブートローダ側の仕事となっているからです。
続き、MSRとC:ドライブを作成

WIMイメージからの展開と、ドライバーなどのパッケージの導入はBIOSの時と同じです。

さて、ブートローダの設定がBIOSの時とはまた変わってきます。

今回、実行するコマンドは以下になります。

  • bcdboot c:\Windows /s s:

WIMイメージの展開、パッケージの導入の後、bcdboot で起動ドライブを設定

起動するOSとして c:\Windows を指定するところまでは同じです。が、その後、ブートローダの設定をかき込むのは EFIシステムパーティションである s: ドライブになります。
その後の bcdedit での確認も、以下になります。

  • bcdedit /store s:\EFI\Microsoft\Boot\

EFIシステムパーティションでのブートローダなどは、ルートのEFIフォルダに格納されます。Windows のブートローダーwinload の設定は EFI\Microsoft\Boot 以下に記載される訳です。これはBIOSの時の\Boot\BCD とパスが違うので注意です。

さて、あとはシャットダウンして再起動するだけで、BIOSの時と同じように起動してきます。
一応、EFIから起動した Nano Server...別にBIOSの時と変わらないのですが。
BitLocker などを使わない限りは別にEFIでもBIOSでもOS起動後の動作は変わらないですし、そもそも vSphere では TPMが使えない(仮想TPMが存在しない...これも何とかしてほしいのですが)ので、ことさら EFI にする必要はない、といえます。

.

2015/03/12

アップグレードしたOSはカスタマイズできない

所用があり WindowsServer 2012 R2 をいくつかテンプレートから展開していたのだが、カスタマイズ仕様で指定した設定がなされていないことに気がついた。

該当のマシンにログオンし、 sysprep のログを見たところ、以下のメッセージが表示されていた。なお、sysprep のログについてはこちらのKBに記載がある。
[0x0f0036] SYSPRP spopk.dll:: Sysprep will not run on an upgraded OS. You can only run Sysprep on a custom (clean) install version of Windows.
...ああ、なるほど。このテンプレート、そもそもは WindowsServer 2012 で、R2 を後から適用したため「アップグレード」となってしまったわけだ。2012 を展開する用がなかったのでそのことをすっかり失念していた。

対処としては二つある。一つは、素直にOSを新規インストールし直すことだ。
今回はこちらを採用した。理由は簡単で、Windows.old が残っており、削除がやっかいで、そのうえ肥大した VMDK の領域回収を考えると、時間はかかるがほったらかしておけば終わる入れ直しの方が楽だったからだ。

もう一つは、アップグレードであるというフラグをつぶしてしまうことだ。
詳細はこちらのページなどを参照してほしい。

レジストリを操作するだけなので時間は短くて済む。
しかし、そもそもなぜアップグレードしたOSだと sysprep を拒否するようになってるかがわからないので、後々で面倒を抱えたくないというのもあり、この手を取らなかった。

2015/02/23

ESXi に使うべき フラッシュメディアのサイズ

ESXi 5.5 のインストールには最低 1GB のストレージ容量が必要で、scratch を配置する場合は 5.2GB 以上、となる。

これは ESXi のマニュアルに記載されている。

さて、ではサイズが異なると ESXi のインストレーションはどう変わっていくのだろうか?
VMware Fusion 上に ESXi をインストールし、その時の VMDK のサイズを変えて試してみた。

● 1,2,4GB の場合

これら 5.2 GB 未満のメディアの場合は、まったく同じサイズで5つのパーティションが作成される。

ID 開始セクタ 終了セクタ サイズ 形式(FS) 用途
1 64 8191 4MiB systemPartition (FAT32) EFI
5 8224 520191 250MiB linuxNative (FAT32) /boot
6 520224 1032191 250MiB linuxNative (FAT32) /altboot
7 1032224 1257471 110MiB vmkDiagnostic Coredump
8 1257504 1843199 286MiB linuxNative (FAT32) /store

IDはパーティション番号を意味する。
1は要するに EFI システムパーティションで、FAT である。
5 が実際の ESXi のシステムが入ってる bootbank で、6 は altbootbank である。
7 は診断パーティションとも呼ばれているもので、要するにコアダンプ用だ。
8 は visorfs の /store にマウントされるパーティションで、VMware Tools のインストール用 CDイメージなどが格納されている。

linuxNative とGUIDで記載されているパーティションが何故 FAT32かというと、GUIDパーティションテーブルでは、Windows のパーティションと Linux のパーティションに同じGUID が割り当てられており、区別できないからだ。

全体で1GiB も使ってないが、これは 1,2,4 GB どの場合も同じだった。
つまり、5.2GB 未満では、どの容量のメディアを使おうと、先頭 0.9 GiB程度しか使われない訳だ。

● 8GB の場合

さて、8GBのメディアにインストールすると、こうなる。

ID 開始セクタ 終了セクタ サイズ 形式(FS) 用途
1 64 8191 4MiB systemPartition (FAT32) EFI
5 8224 520191 250MiB linuxNative (FAT32) /boot
6 520224 1032191 250MiB linuxNative (FAT32) /altboot
7 1032224 1257471 110MiB vmkDiagnostic Coredump
8 1257504 1843199 286MiB linuxNative (FAT32) /store
9 1843200 7086079 2.5GiB vmkDiagnostic 拡張Coredump
2 7086080 15472639 4GiB linuxNative (FAT32) /scratch
3 15472640 16777182 約0.6GiB
(残り全部)
vmfs datastore01


前半のパーティションはそのままで、あらたに9, 2, 3 の三つのパーティションが追加された。

ID:9 はESXi 5.5 で新たに用意されたコアダンプパーティションだ。従来の110MiBのダンプでは全てを取りきれないため、2.5GBもの容量が確保されている。
ID:2 がいわゆる Scratch パーティションで、ログなど様々な情報が格納される。
このパーティションが存在しないと、ESXi が警告を発するのはご存じの通りだ。

ID:3 は VMFS であり、datastore1 となる部分だ。ここは、ディスクの残り領域がすべて割り当てられる。8GBのメディアの場合、600MiB程度が VMFSとして確保される。

ここであれ?っと疑問に思われた方は正しい。そう、VMFS は 600MiB なんてサイズでは構成できない。vSphereClient から datastore1 を削除した後、再作成は失敗する。

この制限以下の小さな VMFS は、インストール時にのみ現れる特別なものらしい。

閑話休題、scratch が必要な場合は 5.2GB 以上のメディアを使うようドキュメントにはあるが、0.9GiB + 2.5GiB(拡張ダンプ) + 4GiB(scratch) では、7.4GB 程度が必要に見える。

そこで、6GB の場合を試してみた。

● 6GB の場合

6GB では、パーティションテーブルはこうなった


ID 開始セクタ 終了セクタ サイズ 形式(FS) 用途
1 64 8191 4MiB systemPartition (FAT32) EFI
5 8224 520191 250MiB linuxNative (FAT32) /boot
6 520224 1032191 250MiB linuxNative (FAT32) /altboot
7 1032224 1257471 110MiB vmkDiagnostic Coredump
8 1257504 1843199 286MiB linuxNative (FAT32) /store
2 1843200 10229759 4GiB (FAT32) linuxNative (FAT32) /scratch
3 10229760 12582878 約1.1GiB
(残り全部)
vmfs datastore01


ID9 の拡張ダンプパーティションが消えている。その分、余りが増えるため VMFS 領域が拡大しているのが分かる。VMFS領域を抜くと、約 4.9 GiB になる。つまりは、SI単位系で言うところの約 5.2GB である。厳密に言うなら、scratch の最終セクタが 10229759 であり、1セクタが 512バイトのため、5237636608 バイトが必要である。これを1024 で割っていくと 4.87GB となり、1000 で割ると 5.2GB となる訳だ。

そして余った分が VMFS の領域になる。
もし、余りが 2.5GiB 以上あれば、拡張ダンプパーティションが作成され、そこからの残りで VMFS が作成される。


共有ディスクに、複数 ESXi のログまとめて管理したり、syslog で飛ばして LogInsight を使う、とかでも無い限り、scratch はあるに越したことない。

このため、おとなしく 5.2GB以上、実質的には 8GB のフラッシュメディアを用意しておくのが正解、となる。

なお、こちらのKBには面白いことが書いてある。
リテール購入品の 16 GB 以上の USB フラッシュ ドライブを使用すると、「予備の」フラッシュ セルで起動メディアを長持ちさせることができるのでお勧めしますが、コアダンプの拡張パーティションの保持には 4 GB 以上の高品質ドライブがあれば十分です。
16GB にしておくことで、ウェアレベリングが効いてより長持ちすると言うことだ。
後半の文章が謎だが、8GB の誤植ではないかと思われる。





2014/05/29

VSAN で使ったディスクを再利用して VMFS を構成する

先日のことだが、vExpert 2014受賞者向けに VSANを含む各種製品の評価ライセンス(365日有効)が配布された。
例年、vExpert にはだいた1年のほぼ全製品の評価版が渡されており、自由に検証に使うことができる。あくまで個人への割り当てのため家の私物 ESXi 環境などに入れても問題がないため、これは結構重宝する。


さて、そのVSANの検証をしていて、VSANの構成にHDDやSSDを使おうとした際、あるいはその逆でVSANで使ってたディスクを VMFSで利用しようとすると、構成時にそのディスクが選択肢に表示されず、利用できないことがあった。

どうやら以前に一方で使っていたディスクは、もう一方に使えないようになっているようだ。これはフェイルセーフとしても納得がいく。何らかの理由で孤立してしまい、単体では VSANの一部として見なされないディスクをうっかりVMFSで上書きしてしまっては困るからだ。

とはいえ、検証でディスクを使い回しているとそうも言ってられない。
ので、少々乱暴だが認識できるようにしたので、メモをしておく。


● なぜ認識されないか

VMFSを削除したり VSANを解放しても、SSD/HDD上にはその時に作成されたパーティション情報が残っている。ESXi はこのパーティション情報を見て VSAN/VMFSで使っていたことを検知する。VMFSで使ってた領域を VMFSで使う分には問題ないのだが、タイプを変えようとするとお互いの選択肢から除外されてしまう訳だ。
(なお、これに限らず、ESXi はなんらかのパーティション情報があると選択肢から除外する傾向がある。Linux 等で使ってたディスクを追加のVMFSとして使う際はこれが問題になる事がある。 )
このため、パーティションテーブルをクリアすれば新しいSSD/HDDのように素直に認識してくれる。


● パーティションの削除(失敗編)

さて、パーティションテーブルを飛ばすとなると、普通 dd コマンドだろう。
(大事なことなので強調してみました)

しかし、なんとも嘆かわしいことに ESXi Shell では dd コマンドは使えない。
存在はするのだが、ディスクドライバ側に必要なAPIが備わってないため、書き込みができないのだ。

# dd if=/dev/zero of=/dev/disks/naa.600508b1001cccc92c42c05aa821872a count=1 bs=1M
dd: can't open '/dev/disks/naa.600508b1001cccc92c42c05aa821872a': Function not implemented

嘆かわしい、実に嘆かわしいっ。

仕方が無いので、前時代的で格好の悪いパーティション操作系のコマンドを使うことになる。もういつから使ってるか分からない、あの fdisk だ。

ただ、ESXi の作者はすこしは正気が残ってたようで、fdisk コマンドは動きはするが非推奨となっている。MBRパーティションではなく GPT を使ってるからだ。

# fdisk -l /dev/disks/naa.600508b1001cccc92c42c05aa821872a

***
*** The fdisk command is deprecated: fdisk does not handle GPT partitions.  Please use partedUtil
***

Found valid GPT with protective MBR; using GPT

Disk /dev/disks/naa.600508b1001cccc92c42c05aa821872a: 390651840 sectors,  372M
Logical sector size: 512
Disk identifier (GUID): b380795f-8cc1-4991-b911-aed80429cf48
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 390651806

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048            6143        4096   0700
   2            6144       390651806        372M   0700

上記のように、fdisk を実行すると推奨されるのが partedUtil というコマンドだ。


● partedUtil で情報を取得する

partedUtil でのパーティション情報の取得には get/set とgetptbl/setptbl という2つの系統がある。どっちも fdisk にくらべればシンプルだが、より細かい情報が出るのは getptbl の方だ。

# partedUtil get  /dev/disks/naa.600508b1001cccc92c42c05aa821872a
24316 255 63 390651840
1 2048 6143 0 0
2 6144 390651806 0 0
# partedUtil getptbl  /dev/disks/naa.600508b1001cccc92c42c05aa821872a
gpt
24316 255 63 390651840
1 2048 6143 381CFCCC728811E092EE000C2911D0B2 vsan 0
2 6144 390651806 AA31E02A400F11DB9590000C2911D1B8 vmfs 0

get/set では「パーティション番号」「開始ブロック」「終了ブロック」「タイプ」「属性」の順で、getptbl/setptbl では「パーティション番号」「開始ブロック」「終了ブロック」「UUID」「属性」となっている。実際には上記のように、UUIDのあと、そのUUIDの意味がテキストで表示されている。どの用途(ファイルシステムなど)でどのUUIDを使うかは、showGuids オプションで確認できる

# partedUtil showGuids 
Partition Type       GUID 
vmfs                 AA31E02A400F11DB9590000C2911D1B8
vmkDiagnostic        9D27538040AD11DBBF97000C2911D1B8
vsan                 381CFCCC728811E092EE000C2911D0B2
VMware Reserved      9198EFFC31C011DB8F78000C2911D1B8
Basic Data           EBD0A0A2B9E5443387C068B6B72699C
Linux Swap           0657FD6DA4AB43C484E50933C84B4F4F
Linux Lvm            E6D6D379F50744C2A23C238F2A3DF928
Linux Raid           A19D880F05FC4D3BA006743F0F84911E
Efi System           C12A7328F81F11D2BA4B00A0C93EC93B
Microsoft Reserved   E3C9E3160B5C4DB8817DF92DF00215AE
Unused Entry         00000000000000000000000000000000

Linux のパーティションが何故、と思われるかも知れないが、これらは ESXi のブートディスクで利用される。
実際にブートドライブを partedUtil で見たのが、以下だ。

# partedUtil getptbl /dev/disks/naa.600508b1001c7b1101f3c08c5b2c5784
gpt8920 255 63 143305920
1 64 8191 C12A7328F81F11D2BA4B00A0C93EC93B systemPartition 128
5 8224 520191 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
6 520224 1032191 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
7 1032224 1257471 9D27538040AD11DBBF97000C2911D1B8 vmkDiagnostic 0
8 1257504 1843199 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
9 1843200 7086079 9D27538040AD11DBBF97000C2911D1B8 vmkDiagnostic 0
2 7086080 15472639 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
3 15472640 143305886 AA31E02A400F11DB9590000C2911D1B8 vmfs 0

EFI準拠のため、先頭に EFI パーティションが存在する。LinuxNative の部分がブート用に使用され、vmkDiagnostic がカーネルだんぶ領域だ。最後のVMFSは datastore1 に相当する部分にあたる。パーティションの物理的な所在と、パーティション番号が異なるのも注意を要する。

どのドライブがどのデバイス名を持っているかは、色々調べる方法がある。
こちらのブログのように esxcfg-scsidevs コマンドを使っても良いし、以下のように esxcli でも同じ結果を得られる。

# esxcli storage core  device list
naa.600508b1001c36b38da960b49ca5fbed
   Display Name: HP Serial Attached SCSI Disk (naa.600508b1001c36b38da960b49ca5fbed)
   Has Settable Display Name: true
   Size: 3815350
   Device Type: Direct-Access
   Multipath Plugin: NMP
   Devfs Path: /vmfs/devices/disks/naa.600508b1001c36b38da960b49ca5fbed
   Vendor: HP
   Model: LOGICAL VOLUME
   Revision: 1.28
   SCSI Level: 5
   Is Pseudo: false
   Status: degraded
   Is RDM Capable: true
   Is Local: false
   Is Removable: false
   Is SSD: false
   Is Offline: false
   Is Perennially Reserved: false
   Queue Full Sample Size: 0
   Queue Full Threshold: 0
   Thin Provisioning Status: unknown
   Attached Filters:
   VAAI Status: unknown
   Other UIDs: vml.0200030000600508b1001c36b38da960b49ca5fbed4c4f47494341
   Is Local SAS Device: false
   Is Boot USB Device: false
   No of outstanding IOs with competing worlds: 32

naa.600508b1001c7b1101f3c08c5b2c5784
   Display Name: HP Serial Attached SCSI Disk (naa.600508b1001c7b1101f3c08c5b2c5784)
   Has Settable Display Name: true
   Size: 69973
(後略)

iSCSI/FibreChannel での共有ディストレージやRAIDカード経由の接続の場合はだいたい naa. から始まる名称に、オンボードのSATA/SAS インターフェイスの場合は mpx. から始まる名称になる。

非常に多くの情報が出るので適宜 grep で削ってもいい。お目当てがどのデバイスかは、サイズとやベンダー名、Display Name あたりがヒントになるだろう。

なお、partedUtil について記載している VMware 社のKB1036609 では、ディスクを見つけるのに /dev/disks 以下を調べろ、というなかなか素敵なことが書いてある。

余談だが、VSANで使ってた、個別にマウントされていたHDDを HP社の SmartArray でRAID5で束ねた場合、partedUtil で見るとこんなことになる。

# partedUtil getptbl /dev/disks/naa.600508b1001c36b38da960b49ca5fbed
Error: The backup GPT table is not at the end of the disk, as it should be.  This might mean that another operating system believes the disk is smaller.  Fix, by moving the backup to the end (and removing the old backup)? This will also fix the last usable sector as per the new size. diskSize (7813837232) AlternateLBA (1953459631) LastUsableLBA (1953459598)
Error: The primary GPT table on '/dev/disks/naa.600508b1001c36b38da960b49ca5fbed' is OK, but secondary is corrupt. Fix secondary table? This will move secondary at the end in case it is not at the end already. It will also set LastUsableLBA to use all the space at the end. diskSize (7813837232) AlternateLBA (1953459631) LastUsableLBA (1953459598)
Warning: Not all of the space available to /dev/disks/naa.600508b1001c36b38da960b49ca5fbed appears to be used, you can fix the GPT to use all of the space (an extra 5860377600 blocks) or continue with the current setting? This will also move the backup table at the end if is is not at the end already. diskSize (7813837232) AlternateLBA (1953459631) LastUsableLBA (1953459598) NewLastUsableLBA (7813837198)
gpt
486388 255 63 7813837232
1 2048 6143 381CFCCC728811E092EE000C2911D0B2 vsan 0
2 6144 1953459598 AA31E02A400F11DB9590000C2911D1B8 vmfs 0

間にすごく長いエラーメッセージが表示されるが、要は、先頭のGPTパーティションテーブルと、末尾にあるはずのバックアップテーブルが一致しない、というエラーになる。

すくなくとも SmartArray では、RAIDを組んだだけでは内容がクリアされない、以前の単一ディスクだったときのどれかのパーティションテーブルが見えてしまうことがあるようだ。
こういう場合は、partedUtil fixGpt <デバイス名> コマンドを実行することで、パーティションテーブルの復元が行われる。


● partedUtil でパーティションを削除する

ここまで分かれば、後は簡単だ。パーティションを削除すれば良い。
ブートドライブや共有ディスクを誤って殺ってしまわないよう、またパーティション番号にも注意して、以下のように partedUtil delete コマンドを実行する

# partedUtil getptbl /dev/disks/naa.600508b1001cb619f764cc6d47de5db0
gpt486388 255 63 7813837232
1 2048 6143 381CFCCC728811E092EE000C2911D0B2 vsan 0
2 6144 1953459598 AA31E02A400F11DB9590000C2911D1B8 vmfs 0
# partedUtil delete /dev/disks/naa.600508b1001cb619f764cc6d47de5db0 2
# partedUtil delete /dev/disks/naa.600508b1001cb619f764cc6d47de5db0 1
#

delete のあとに、デバイス名とパーティション番号を指定し、うまくいけば、何のエラーも表示せずに消えてくれる。あとは、vSphereClient / WebClient よりストレージの再スキャンを行い、デバイスを再認識させる。


再認識後は、VMFSの作成などで再び選択肢に表示されるようになる。


● VSAN で使っていたSSDの場合

ただ、VSANで使われていた SSD の場合、2つできているパーティションの後者が削除されないという問題が生じた。

# partedUtil getptbl /dev/disks/naa.600508b1001cccc92c42c05aa821872a
gpt
24316 255 63 390651840
1 2048 6143 381CFCCC728811E092EE000C2911D0B2 vsan 0
2 6144 390651806 AA31E02A400F11DB9590000C2911D1B8 vmfs 0
# partedUtil delete /dev/disks/naa.600508b1001cccc92c42c05aa821872a 1
# partedUtil delete /dev/disks/naa.600508b1001cccc92c42c05aa821872a 2
Error: Read-only file system during write on /dev/disks/naa.600508b1001cccc92c42c05aa821872a

Unable to delete partition 2 from device /dev/disks/naa.600508b1001cccc92c42c05aa821872a

どうやら、SSDについては ESXi の VSAN モジュールが握っており、簡単には解放させてくれないようだ。
これについては、こちらのブログに記載がある。手段としては以下の2つがある。

  1. esxcli vsan cluster leave コマンドで VSANを終わらせる
  2. 下記の vmkload_mod コマンドで VSAN関連のモジュールを排除し、解除させる
    • vmkload_mod -u vsan
    • vmkload_mod -u plog
    • vmkload_mod -u lsocommon

ただ、ブログにも記載があるが、1. ではうまくいかないことが多いようだ。私の場合、先に1つパーティションを消して情報を欠損させているせいか、やはりうまくいかなかった。
ので 2. にある3つの vmkload_mod を実行した。すると、上記にある Read-only のエラーが出なくなり、パーティションが削除された。

なお、別解としては以下がある
  1. SSDの2つあるパーティションのうち一方を削除後、ESXi を再起動
最初の VSANパーティションを削除することで、VSAN関連のモジュールがSSDを見つけ出す標を失ってしまう。それから ESXi もろとも再起動、再初期化することで VSANモジュールが握れなくしてしまうと言う訳だ。

再起動が一回かかるので面倒で時間はかかるが、強制的なモジュール排除などを必要としないのでまだ安全かと思われる。


2014/04/17

ESXi をクローンした場合、互いに通信できなくなる

● 職場で同僚が悩んでた件

ESXi on ESXi で仮想環境上に ESXi を実行しているのだが、どうも vMotion がうまくいかないとの事。vMotion 用の VMkernel Port はもちろん作ってるし、設定を見る限りでは疎通してもおかしくない。

とりあえずと調べているうちに(まあ色々妙な設定は見つかったのでなおしたのだがそれは略して根本だけを見ると)、どうも互いの ESXi 同士の ping / vmkping がいずれも通らないのが原因のようだ。

そして、よくよく見ると気がついたのが、ARPテーブルがうまく作れていない。
ESXi のARPテーブルは「esxcli network ip neighbor list」で確認できるが、相手の項目が作成されないのだ。
で、「esxcfg-vmknic -l」を見てみたら、双方の vmknic が同じMACアドレスを持っている。どうもこれが原因だと判明。

聞いたところ、どうも1台目の ESXi を構成した後、シャットダウンして、クローンを作って2台目を構成したとのこと。どうやら、それが悪かったようだ。

● vmknic のMACアドレス

VMkernel Port のMACアドレスだが、これは以下に見受けられる

・インストール時に指定した管理ポートは、管理用NICのMACアドレスがつく
・後で追加したものは「00:50:56」等から始まるVMwareの仮想用のMACアドレスがつく

ここでうっかりしてしまうのだが、上記の、最初の VMkernel Port (Management Network) のMACアドレスも「仮想」である。つまり、すべての VMkernel Port の MACアドレスは、仮想マシンの仮想NICと同じで仮想MACアドレスである。

VMkernel Port にどの仮想MACアドレスがつくかは、ESXi の管理領域の /etc/vmware/esx.conf に記載されている。つまり、この esx.conf の値を書き換えない限り、同じMACアドレスが割り当てられる。

先の問題は、クローンをしてしまった事から生じる。クローンを実施した折に ESXi を実行する仮想マシンのMACアドレスはもちろん差し替えられる。しかし、さすがに /etc/vmware/esx.conf を書き換えることはないので、起動すると、クローンされた ESXi は、クローン元の ESXi と同じMACアドレスを VMkernel Port に設定してしまう。

クローン元のESXi
vmnic0 (ESXiに繋がってるNIC)のMACアドレスと、
vmk0 のMACアドレスが同じであることが分かる

クローン先の ESXi
vmnic0 は 00:50:56:35:53:52 であるのに対し、
vmk0 は 00:0c:29:2a:a3:cf とクローン元のままだ

冒頭の症状、vMotion 用の VMkernel Port がお互いに通信できなかったのは、同じMACアドレスを持っているため、たとえ異なるIPアドレスを設定しててもL2的には相手が見つけられなかったからだ。

● 修正方法
最も手っ取り早いのは、ESXi はクローンしない、クローンした ESXi 同士をクラスタ挿せるなど連携で使わない、って事だろう。別々のネットワーク、異なる vCenterServer の配下であればまあ問題はないが、同じネットワーク、同じ vCenterServer でクラスタを組むときは個別にインストールする必要がある。ESXi のインストール時間などたかがしてれるので、それぐらいは毎度やってしまえと言うことだ。

クローンしてしまってこの問題に遭遇した場合は、クローン先の ESXi で以下のコマンドを実行するのが手っ取り早い




1. 「esxcfg-vmknic -l」で、VMkernel Port ポートグループと vmknic の対応を確認する
2. 「esxcfg-vmknic -d "<ポートグループ名>"」で、そのポートグループの vmknic を削除

esxcfg-vmknic -d で vmknic を削除
"Management Network" というポートグループが残留しているのがポイント
vSphereClient では分かりにくいが、VMKernel Port も仮想マシン用と同じ
ポートグループがあり、vmknic が一つだけ入っているというだけだ 
3. 「esxcfg-vmknic -a -i <IPアドレス>  -n >>」で、そのポートグループのvmknic を作成
残留している "Management Network" に vmk0 を作成
この時、新しいMACアドレスが裁判されているのが分かる
4. 「esxcfg-vmknic -l」で、設定を確認する(上図)



そもそも、vSphereClient では VMkernel Port が、ポートグループと vmknic でできていることが隠蔽されており、一つのポートのように見えている。このため、VMKernel Port を削除すると、vmknic とポートグループが一気に削除されてしまう。
WebClient ではこの二つが明確に別れて表示されるようになり、どちらを選択して設定ボタンを押したかで設定できる項目に違いが出てくる。
WebClient での表示
Management Network を選択するとこの通りポートグループ全体が選択される

WebClient での表示
ポートグループの仲の vmk0 を選択すると、vmknic だけが選択される

上記のコマンドは、この事を利用して VMKernel Port に設定されたチーミングやセキュリティ設定などを保存しつつ、また管理用の VMKernel Port がなくなって混乱する時間を最低限にしつつ、vmknic を作り直してMACアドレスを再生成させるという手順なわけだ。


※ 2014/5/28 付記

クローンを行う前に仮想環境上の ESXi で以下のコマンドを実行する事でも、回避はできる。

esxcfg-advcfg -s 1 /Net/FollowHardwareMac

察せられるように、NICのMACアドレスが変わったら取りなおすというものだ。
...今思いついたが、クローンした後でも、クローン先のESXiで個別に実行してから再起動しても何とかなりそうだな。