ESXi 7.0 ディスク換装

正確には、換装ではなく追加。

現在、HDD(4TB)が付いていて、ここにインストールしたESXiが稼働中。このHDDはデータストアでもある。
ここにSSD(1TB)を追加し、ESXiをここから起動するようにしたい。

今のHDDにあるデータストアはそのまま利用する。
速度を求める仮想マシン・ディスクはHDD→SSDに移動させ、ネットワークストレージ的なディスクはそのままHDDに置いておく。

作戦

環境

サーバーとして稼働しているのは、以下の若干無理した環境。

とはいえ、できあがってみると実によくできたPCだと実感するし、使用感も快適といえる。
UEFIにも対応しているから、2TB越えのディスクもGPTパーティションにして起動できる。SATAのコネクタも6つ用意されており、拡張性もある。電源が逝っちゃったので、まぁまぁの容量のものに交換しているから、SATAのディスクを何個か追加しても問題なく動くだろう。古いPCだけれども、メインPC時代から本当によく頑張ってくれている。

項目	値
型番	Gateway DX4840
CPU	Intel core i5 750 (Lynnfield)
Memory	20GB (2GBx2+8GBx2)
HDD	HDD (4TB)
LAN	Intel 82574L (内蔵のRealtek RTL8111はドライバがないため動かない)
ESXi	7.0U2a (allowLegacyCPU=true指定で動いている)

換装の手順

換装のやり方は色々とあるだろうけれども、サーバーの停止時間を短くすることを目的として、以下とした。

VMware Workstation Player使って、SSDにESXiをインストール。
VMware Workstation Playerにテスト用のESXiをインストールし、SSDを繋げてリハーサルを実施。
本番環境のサーバーを停止し、SSDを取り付ける。
BIOSで CD/DVD Drive → SSD → HDD の優先度で起動ができるようにする。
SSDで起動後に、以下を修正する。
- IPアドレスを本番環境のものに変える。
- ネットワークに割り当てられたMACアドレスを、本番環境のものに変える。
- SSDとHDDにあるデーターストアを恒久的にマウントして使えるようにする。
- サーバーをSSDに移動させる。
  ただし、ネットワークストレージ的なディスクはHDDに残す。

リハーサルをやっても、たいがい本番環境で何かが起こるもの…今回も例外ではなかった。

それと、今回の換装では VFFS というボリュームについて全く知らない状態で進めている。最後の状態を見ると、大勢に影響はないといえそうだけれども、これもちゃんとコントロールしたい方には情報が不足しているかもしれない。

インストールするESXi

ESXi 7.0U2a をインストールする。

環境のところで書いた通り、かなり無理した環境。
ESXi6.5であれば問題なく動くが、ある日どうしてもアップグレードしたくなり、無理矢理ESXi7.0を動かしている。

過去に調べたところによれば、6.5では問題なく動作、6.7ではインストーラーをバイナリレベルで修正する必要がある。
7.0ではパラメーター設定(allowLegacyCPU=true)でどうにかインストールができ、インストール後も同じパラメーターを設定すれば、起動することが分かっている。

インストールそのものは7.0が動作可能なPCで行う計画だけれども、動作実績があり、インストーラー起動時にallowLegacyCPU=trueを指定するこのISOを使用する。

換装が終わった今となってみれば、インストーラー起動時と、ESXi起動時に[Shift]+[o]でこのオプションを入力すればいいし、起動さえできればどうにかなりそうな気もするけれど、この時には過去の実績を最優先していた。

仮想マシンを使ってSSDにESXiをインストール

「やること」と「やり方」がちゃんと分かっていれば、昔からできたんじゃないかなぁ、これ。
でも知識が足らなくて、仮想ディスクのイメージをddコマンドでコピーする的なことばっかりやっていた。

メインで使っているのはホームラボ最速のPCで、仮想マシンもサクサク動く。
仮想マシンで構築できるところをやりきって、作った物理ディスクを持っていけば、コピーは要らないから、本番環境での作業時間を短縮できる。
全体の作業時間はあまり変わらないかもしれないが、サービスの停止時間は小さくできる。

仮想マシンの作成

VMware Workstation Playerで仮想マシンを作成する。

物理ディスク・物理パーティションをマウントするために、VMware Workstation Playerを「管理者として実行」する。

仮想マシン作成する時、ESXiインストーラーを指定しておく。
これにより、仮想マシン設定のゲストOSが「VMware ESXi 7 以降」に設定される。
他の方法で仮想マシンを作成すると、「VMware ESXi 7 以降」は選択肢として現れない。

仮想ディスクの作成では、物理ディスクをマウントする。
どのディスクをマウントするのか指定する際、選択肢がPhysicalDrive0, PhysicalDrive1…となっていて、どれが狙ったディスクなのかが分かりづらかったが、どうやらWindowsの「ディスクの管理」アプリで表示される順序であって、かつ、DISKPARTコマンドで…

DISKPART> list disk

  ディスク      状態           サイズ   空き   ダイナ GPT
  ###                                          ミック
  ------------  -------------  -------  -------  ---  ---
  ディスク 0    オンライン           953 GB   953 GB        *
  ディスク 1    オンライン          7452 GB  1024 KB        *
  ディスク 2    オンライン          1907 GB      0 B        *

と表示されたこのディスク番号らしい。
今回は、PhysicalDrive0が対象のSSDだった(仮想マシンができた後、ISOからUbuntuを起動して確認し、狙い通りと安心した…)。

という感じで進めていくと、以下の特徴の仮想マシンが作られる。

ファームウェアが”efi”になる。(firmware = “efi”)
ディスクはSCSI”pvscsi”になる。(scsi0.virtualDev = “pvscsi”)
イーサーネットデバイスが”vmxnet3″になる。(ethernet0.virtualDev = “vmxnet3”)

特徴はこれくらいだと思うので、例えばゲストをUbuntuで作成してしまってESXiがインストールできない時には、このあたりを修正すれば多分行ける。

ESXiのインストール

仮想マシンを起動すると、Grubが表示される。

そこで[Enter]を押すと、boot.cfgが読み込まれ、5秒間だけ起動が停止する。
この間に[Shift]+[o]を押して、オプション入力ができる状態にして、以下を追加した。

<ENTER: Apply options and boot>
> runweasel cdromBoot allowLegacyCPU=true systemMediaSize=min

※allowLegacyCPU=trueは古いCPUでも使えるようにするオプションで、インストーラーをカスタマイズして追記している。普通は要らないオプション。

このオプションを付けておかないと、インストーラーによりVMFSLというパーティションが最大138GBも取られてしまう。
ここを見る限り、うちの環境ならmin指定(33GB)もあれば十分だろう。
VMware docs / ESXi のシステムストレージの概要

このオプションでインストールしてみた結果、VMFSLは24GBとなった。
換装完了後も元気に動いているので、まぁ、大丈夫だろう。

インストール完了後、ブラウザーでhttps://<IP Address>にアクセスしたところ、Web UIを使用することができた。

本番環境の設定を写す

この環境においてもっとも大事なのは、allowLegacyCPU=true の設定。
(普通は要らないのだけれども、DX4840の場合にはこれがないと動かない)

SSH、あるいは、コンソールでログインして追記。

/bootbank/boot.cfg

kernelopt=autoPartition=FALSE allowLegacyCPU=true

/altbootbank/boot.cfg

kernelopt=weaselInstalled allowLegacyCPU=true

※こちらの設定が必要かどうかはよく分かっていないが、立ち上がらないとまずいので、とりあえず設定。

本番環境に入れた細々した設定をコピーしておく。

アプリケーションのタイムアウトオフ(自動でログアウトしない)
自動起動の設定(基本設定をコピーし、各ホストの起動順序はスクリーンショットでメモ)
NTPの設定
ESXiのライセンス情報の投入
ホスト名・IPアドレスの設定
ネットワーク → TCP/IPスタック → デフォルトのTCP/IPスタックで設定できる。
SSL証明書
ホスト名を設定後、証明書署名要求を表示させ、それに署名してオレオレSSL証明書を作成して設定。

今できるのは、だいたいこんなところ。

仮想マシンを使ってリハーサル

過去に、HDD→HDD(ちょっと大きいヤツ)へのコピーをしたところ、データーストアを認識しなかった。
その時には、結局本番環境でESXiをインストールし、HDD→HDDに仮想マシンをコピーして問題を回避した。

そうやって動かしたHDDを、DX4840(本番環境)に差し替えて稼働させていたある日、思い立って古いPCを起動したら、MACアドレスがバッティングする問題が発生した。

これら発生することが分かっている問題について、対処方法を整理しておく。
それでも本番環境では色々起こるもの…。準備ができるなら、できるだけ準備しておかないと。

仮想マシン(リハーサル用)の作成

SSDにインストールする時とほぼ同じ手順。
違いは以下。

一般ユーザーでVMware Workstation Playerを起動。
ハードディスクは、仮想ディスク(デフォルトの142GB)とした。

インストール時に、オプション systemMediaSize=min を設定する。
VMFSLは24GBになった。
データストアは110GBあり、テスト用のOSをインストールするのには十分すぎる容量となっている。

仮想マシン(リハーサル用)の中にテスト用の仮想マシンを作成

本番環境にSSDを持って行ったら、まずは元々ある仮想マシンを起動して、その後に仮想マシンを1つ1つSSDに持って行くつもり。
そこで、仮想マシン(リハーサル用)にOSを2つばかりインストールして、それがそのまま起動できるか、SSDに持って行って起動できるか、といったあたりを確認したい。

テスト用には、Ubuntu 20.04 Server、22.04 Serverを使うことにした。

無理矢理動かす環境の練習として、以下の設定も入れておく(本番環境では欠かせない設定)。

ファームウェアをEFIにする。
設定パラメーターに以下を追加する。
- monitor.allowLegacyCPU=TRUE
- disk.EnableUUID=TRUE

メインPCはLegacyCPUではないので、この設定をせずとも動くはずだが、練習だからやっておいた。

ディスクの付け替え

仮想マシン(リハーサル用)でSSDをマウントする。

一旦、仮想マシン(リハーサル用)をシャットダウンし、改めてVMware Workstation Playerを管理者として実行する。

元々付いていたハードディスクをSCSI 0:0からSCSI 0:1に付け替える。
次に、ハードディスクを追加 → 物理ディスクを使用 → SSDの番号のディスクを選択する。
これで、SCSI 0:0に接続されたことを確認する。

これで、マウントするにはするのだけれど、ファームウェア設定で起動時の優先度をSSDに設定する必要もある。
(ファームウェアはどのディスクから起動するのかを覚えていて、付け替えてもそれを優先させるため)

ファームウェア設定画面に入るために、vmxファイルに以下の1行を追加する。

仮想マシン(リハーサル用).vmx

bios.forceSetupOnce = "TRUE"

ファームウェア設定画面に入ったら、SCSI 0:0を最優先にして保存。

ファームウェアを抜ければ、SSDからESXiが起動する。

MACアドレスの更新

SSDから起動したところ、DHCPが払い出したIPアドレスは、仮想マシン(SSDへのESXiインストールに使用)に払い出されていたものだった。
本来は、仮想マシン(リハーサル用)のIPアドレスが払い出されるべきところだが…

SSDに入っているESXiは、インストール時に物理NICのMACアドレスを仮想NICに割り付けていた。
そして、その時に割り付けたMACアドレスを覚えているので、他の仮想マシンから起動しても、覚えたMACアドレスを仮想NICに割り付ける。
DHCPの要求は仮想NICから出されるので、DHCPサーバーはMACアドレスを見て、仮想マシン(SSDへのESXiインストールに使用)に払い出したのと同じIPアドレスを払い出す。

過去に調べた手順で確認してみると…

[root@ESXi:~] esxcfg-vmknic -l
Interface  Port Group/DVPort/Opaque Network        IP Family IP Address                              Netmask         Broadcast       MAC Address       MTU     TSO MSS   Enabled Type                NetStack
vmk0       Management Network                      IPv4      192.168.110.107                         255.255.255.0   192.168.110.255 00:0c:29:d8:07:dc 1500    65535     true    DHCP                defaultTcpipStack
vmk0       Management Network                      IPv6      fe80::20c:29ff:fed8:7dc                 64                              00:0c:29:d8:07:dc 1500    65535     true    STATIC, PREFERRED   defaultTcpipStack

[root@ESXi:~] esxcfg-nics -l
Name    PCI          Driver      Link Speed      Duplex MAC Address       MTU    Description
vmnic0  0000:0b:00.0 nvmxnet3    Up   10000Mbps  Full   00:0c:29:18:2d:fb 1500   VMware Inc. vmxnet3 Virtual Ethernet Controller

といった具合に、仮想NICと物理NICでMACアドレスが違っている。

そこで、以下のコマンドで仮想NICのMACアドレス更新を指示する。

[root@ESXi:~] esxcfg-advcfg -s 1 /Net/FollowHardwareMac
Value of FollowHardwareMac is 1

ESXiを再起動するとこの設定が反映される(ネットワークだけ再起動させれば良かったかもしれないが、やり方は分からない)。

再起動後にログインして確認したところ、仮想NICのMACアドレスが書き換えられていた。

[root@ESXi:~] esxcfg-vmknic -l
Interface  Port Group/DVPort/Opaque Network        IP Family IP Address                              Netmask         Broadcast       MAC Address       MTU     TSO MSS   Enabled Type                NetStack
vmk0       Management Network                      IPv4      192.168.110.108                         255.255.255.0   192.168.110.255 00:0c:29:18:2d:fb 1500    65535     true    DHCP                defaultTcpipStack
vmk0       Management Network                      IPv6      fe80::20c:29ff:fe18:2dfb                64                              00:0c:29:18:2d:fb 1500    65535     true    STATIC, PREFERRED   defaultTcpipStack

DHCPからも、仮想ホスト(リハーサル用)のIPアドレスが払い出されていた。

データストア

以前、本番環境でHDDを換装したときには、データストアが見つからなかった。
でも、今回はディスクを2つとも認識し、データストアもマウントされている。
※どういう理由で認識できているのかは分からない。後述するが、本番環境ではSSDのデータストアが見つからなかった。

認識することはするんだけれども、どちらもdatastore1という名前になっているため、データストアブラウザで中身を見ようとしたら、SSD側のdatastore1の中身が見られなかった。
「エラーが発生しました。再試行してください。」というメッセージが表示されている。

どうせ本番環境でも同じ問題が起きるわけだから、SSD側のデータストアの名前をdatastoressdに変更してみた。
すると、データストアブラウザで問題なく中身が見られるようになった。

テスト用の仮想マシンを起動

仮想マシン(リハーサル用)にインストールしたテスト用の仮想マシン(Ubuntu 22.04とUbuntu 20.04)を起動してみる。

仮想マシンの作成/登録で、テスト用の仮想マシンを登録し、起動するだけ。
問題なく起動した。

起動した仮想マシンをシャットダウンし、アクションメニューから登録を解除して、このテストは終了。

テスト用の仮想マシンをSSDに移動

データストアブラウザで、datastore1にある仮想マシンのフォルダをdatastoressdに移動する。
ハードディスクのサイズは16GBだったが、移動にはサイズ相応の時間が掛かった。

なお、移動の指示はキューに入れられる。
フォルダの複数指定ができないので、2回に分けて移動の指示を入れたところ、処理が並行して行われた。

同時に移動やコピーを行うことで、vmdkファイルは分割されてしまうかもしれないなーとボンヤリ考えた。
SSDは早いけれど、シーケンシャルなアクセスの方が圧倒的に早かった。
少なくとも過去のバージョンでは、データストアブラウザでのコピーはThinでもThickになってしまうようだった。だとすると、順番に1つずつ仮想マシンを移動したほうが良いのではないかと思ったり。そんなにでかいファイルを扱うわけでもないから、気にしなくても大丈夫かもしれないが…。

さて、移動した仮想マシンを登録し、起動しようとすると、以下の通り質問される。

この仮想マシンは移動またはコピーされている可能性があります。特定の管理機能やネットワーク機能を構成するために、VMware ESX ではこの仮想マシンが移動されたのか、またはコピーされたのかを認識する必要があります。不明な場合は、「コピーしました」を回答してください。

移動したので、移動しましたと回答したところ、問題なく起動した。

HDDからSSDになり、起動がとても速くなった。

起動した仮想マシンをシャットダウンし、アクションメニューから登録を解除して、このテストは終了。
そして、仮想マシンそのものもディレクトリごと削除して、リハーサル終了。

本番環境にSSDを設置

いよいよ、本番環境にSSDを取り付けるときがきた。

すべての仮想マシンをシャットダウンし、ESXiをシャットダウン。
本番環境のDX4840を居間に持ってきた。

しかし…なんでなんだろうな、リハーサルしたのに、かならず問題が発生するんだよなぁ。

SSDの取り付けから起動まで

DX4840は、もう10年近く前のものだから、接続順が関係するかも…と思い、SSDのコネクタ近辺に書いてある番号を確認。
1:SSD, 2:HDD, 3:CD/DVDドライブの順に差し込んだ。
結果からすると、設定だけでどうにでもなるようだった。

続いて、DX4840の電源を投入し、[Delete]を連打してBIOS設定画面に入る。
起動の優先順位を CD/DVDドライブ, SSD, HDD の順にした。

BIOSの設定を保存終了すると、ESXiが起動した。
すんなりと立ち上がってくれて良かった。

ネットワーク設定

本番環境では、ESXiに固定IPアドレスを設定している。
SSDにインストールしたESXiは、DHCPからIPアドレスを受け取る設定にしていたので、ESXiの設定画面でIPアドレス、DNS、デフォルトゲートウェイを設定した。
また、IPv6を無効化した。

設定を保存したところで、ネットワーク or ESXiそのもののいずれか(記憶が曖昧)の再起動を求められた。
まだ再起動しても全然問題ないタイミングなので、迷わず再起動を選択。

これにより、FQDN(ホームラボのDNSで名前解決が可能)、あるいは、IPアドレスでESXiにアクセスができるようになった。
SSL証明書をインストールしてあるので、ESXiのWeb UIにアクセスしても、警告は表示されない。

また、前述のMACアドレスの更新も必要なので実施(したと思うが記憶が薄い…)。
ESXiを再起動して、ネットワーク設定が完了した。

データストア設定

Web UIにアクセスしてストレージを確認してみたところ、datastoressdが見当たらない。
仮想マシンでは発生しなかった問題で、理由がよく分からない。

なんでこうやって本番環境だけで問題が発生するんだろう…

まず、ファイルシステムを表示させてみる。
Web UIでボリュームのUUIDを見る方法が分からないので、サイズで判断するしかないけれど…

SSDのVMFSはマウントされていない。
VMFSLは2つあるはずだが1つになっている。HDDのものがVMFSL、SSDのものはVFFSと認識されている。

[root@ESXi:~] esxcli storage filesystem list
Mount Point                                        Volume Name                                 UUID                                 Mounted  Type             Size           Free
-------------------------------------------------  ------------------------------------------  -----------------------------------  -------  ------  -------------  -------------
/vmfs/volumes/5a487973-1c6558b4-b6d7-90fba68685c9  datastore1                                  5a487973-1c6558b4-b6d7-90fba68685c9     true  VMFS-6  3992708972544  1782925230080
/vmfs/volumes/61189906-80b54b40-3a76-90fba68685c9  OSDATA-61189906-80b54b40-3a76-90fba68685c9  61189906-80b54b40-3a76-90fba68685c9     true  VMFS-L     6710886400     3539992576
/vmfs/volumes/648a31e5-0fa6c139-2768-000c29d807dc  OSDATA-648a31e5-0fa6c139-2768-000c29d807dc  648a31e5-0fa6c139-2768-000c29d807dc     true  VFFS      25501368320    22415409152
/vmfs/volumes/cfd8797d-46aad162-c41c-b015fcb222eb  BOOTBANK1                                   cfd8797d-46aad162-c41c-b015fcb222eb     true  vfat        524009472      320733184
/vmfs/volumes/a946a8a7-db460916-8db2-8c758069513b  BOOTBANK2                                   a946a8a7-db460916-8db2-8c758069513b     true  vfat        524009472      524009472
/vmfs/volumes/f7d3e99b-ce44901f-d39c-18cb1264ad75  BOOTBANK1                                   f7d3e99b-ce44901f-d39c-18cb1264ad75     true  vfat       4293591040     4084793344
/vmfs/volumes/28d3ecfd-684cb33b-b889-a1dcc8285ab9  BOOTBANK2                                   28d3ecfd-684cb33b-b889-a1dcc8285ab9     true  vfat       4293591040     4293197824

VMFSのマウント

SSDのVMFSが認識されない問題は、探してマウントすることで解決できた。

[root@ESXi:~] esxcfg-volume -l
Scanning for VMFS-6 host activity (4096 bytes/HB, 1024 HBs).
VMFS UUID/label: 648a31e5-410f8d81-2fdf-000c29d807dc/datastoressd
Can mount: Yes
Can resignature: Yes
Extent name: t10.ATA_____SPCC_Solid_State_Disk___________________AA000000000000000025:8	range: 0 - 943871 (MB)

[root@ESXi:~] esxcfg-volume -M 648a31e5-410f8d81-2fdf-000c29d807dc/datastoressd
Mounting volume 648a31e5-410f8d81-2fdf-000c29d807dc

2つ目のコマンドは、-mでもマウントできるんだけれど、再起動したときに自動マウントされない。
起動したら確実に自動マウントしてほしいので、-Mでマウントする。

これで、datastoressdがマウントできた。再起動してみたが、自動でマウントしていた。

[root@ESXi:~] esxcli storage filesystem list
Mount Point                                        Volume Name                                 UUID                                 Mounted  Type             Size           Free
-------------------------------------------------  ------------------------------------------  -----------------------------------  -------  ------  -------------  -------------
/vmfs/volumes/5a487973-1c6558b4-b6d7-90fba68685c9  datastore1                                  5a487973-1c6558b4-b6d7-90fba68685c9     true  VMFS-6  3992708972544  1782923132928
/vmfs/volumes/648a31e5-410f8d81-2fdf-000c29d807dc  datastoressd                                648a31e5-410f8d81-2fdf-000c29d807dc     true  VMFS-6   989721526272   985386713088
/vmfs/volumes/61189906-80b54b40-3a76-90fba68685c9  OSDATA-61189906-80b54b40-3a76-90fba68685c9  61189906-80b54b40-3a76-90fba68685c9     true  VMFS-L     6710886400     3539992576
/vmfs/volumes/648a31e5-0fa6c139-2768-000c29d807dc  OSDATA-648a31e5-0fa6c139-2768-000c29d807dc  648a31e5-0fa6c139-2768-000c29d807dc     true  VFFS      25501368320    22411214848
/vmfs/volumes/cfd8797d-46aad162-c41c-b015fcb222eb  BOOTBANK1                                   cfd8797d-46aad162-c41c-b015fcb222eb     true  vfat        524009472      320733184
/vmfs/volumes/a946a8a7-db460916-8db2-8c758069513b  BOOTBANK2                                   a946a8a7-db460916-8db2-8c758069513b     true  vfat        524009472      524009472
/vmfs/volumes/f7d3e99b-ce44901f-d39c-18cb1264ad75  BOOTBANK1                                   f7d3e99b-ce44901f-d39c-18cb1264ad75     true  vfat       4293591040     4084793344
/vmfs/volumes/28d3ecfd-684cb33b-b889-a1dcc8285ab9  BOOTBANK2                                   28d3ecfd-684cb33b-b889-a1dcc8285ab9     true  vfat       4293591040     4293197824

なお、自動で認識されるボリュームはアンマウントできない。
再作成した仮想マシンで試してみたところ、こんなメッセージが表示された。

[root@localhost:~] esxcfg-volume -u 648e3ef1-3f291586-e2f5-000c2933cd1f
Can't umount normal VMFS volumes. This option is only valid for snapshot/replica volumes which are manually mounted.

手動でマウントしたボリュームはアンマウントできるので、細かなところで違いがある。

思い通りに動作することはするんだけれど、ちょっとだけ違いがあって気持ち悪い。
でも、早く本番環境を動かしたいので、割り切りとした。

VFFSって何？

これは、実は本番環境が動き出して、最終的にメモを整理していたときに発見した問題。
(もう、早く本番環境を動かしたくて、全然見ていなかった…)

Web UIではVMFSLと表示されているが、esxcliではVFFSと表示されている。

探してみたらこのページが見つかったけれど、並んでいる単語の何一つ分からない。
vmware Docs / 仮想フラッシュリソースについて

Web UIを眺めていたら、ホストのハードウェアに「仮想フラッシュ」という項目があることに気付いた。
ここにVFFSとなったボリュームの容量と使用量が表示されている。

どうやら、SSDであることを条件にVMFSLの代わりにVFFSが作られるのだろう。
そして、Web UIでストレージをたどっていってパーティションの状態を見ると、VFFSはVMFSLと表示される仕様のようだ。
ややっこしいけれども、仕方がない。

VFFSをVMFSLに変更できないかどうかを試すために、もう一度仮想マシンを作成してみた。
仮想ディスクを作る時にNVMeに接続させると、ESXiのインストールでVFFSが作られることが分かった。
SCSIの仮想ディスクを作ってESXiをインストールし、ディスクを2つ繋げて仮想マシンを起動すると、同じような状況を作り出すことができた。

差しあたり、VMFSLをアンマウントしてみたが、動かしていたUbuntuで問題は発生しないし、VFFSの使用量も変化がなかった。
もっとたくさんのシステムを動かしたりすれば、VMFSLとVFFSの違いが分かってくるかもしれないが、VMFSLをアンマウントしても問題ないのだから、ESXiが上手いことやってくれているものと思うことにして、そのままにしておくことにした。

仮想マシンの起動

これは、HDDにある仮想マシンを登録すればすぐにできた。
特筆するところもない。

仮想マシンをHDDからSSDに移動

HDD→HDDよりは稼働中のシステムに与える影響は少ない。
Webページなんかは一応反応する。

それでも、相当遅くなるので、実行する時間帯には注意が必要。
サービスを止められるなら、止めておいた方が良さそうだ。

Thick Provision to Thick Provision

データストアブラウザで仮想マシン・ディスクをディレクトリごとコピーすればOK。
コピー中に何かが起きるかもしれないので、移動ではなくコピーした。

この方法でコピーした場合、少なくとも過去のバージョンではThin provisionのものもThick provisionになってしまうようだ。

コピーが完了したら、仮想マシンを登録して起動。
起動時の質問には「移動しました」と答えた。
(上手く動いたら、元の仮想マシン・ディスクを削除するつもりなので、問題はないだろう)

Thick provision to Thin provision

これは過去にやっていた。

今回は、仮想マシン・ディスクをHDDからSSDにコピーする。
仮想マシンは<guestname>という名前で作ったとして…

まず、SSD側にディレクトリを作成。

[root@ESXi:~] mkdir /vmfs/volumes/datastoressd/<guestname>

HDD側のファイルのうち、vmdk以外のものをコピーする。

[root@ESXi:~] cp -a /vmfs/volumes/datasotre1/<guestname>/<gurestname.* /vmfs/volumes/datastoressd/<guestname>
[root@ESXi:~] rm -f /vmfs/volumes/datastoressd/<guestname>/<guestname>.vmdk

※雑なコピー。vmdkごとコピーして、vmdkを削除している。
※<guestname>-flat.vmdkがディスクの中身のようで、これはでかいのでコピーしないようにする。

多分、logやvswpはコピーしなくても大丈夫だと思う。というか、大丈夫だった。

肝心のディスクだけれども、これは変換という形でコピーする。

[root@ESXi:~] vmkfstools -i /vmfs/volumes/datastore1/<guestname>/<guestname>.vmdk -d thin /vmfs/volumes/datastoressd/<guestname>/<guestname>.vmdk

使用領域の大きいディスクでは時間が掛かるが、小さいディスクは短い時間で終わる。
過去にパーティションテーブルを詰めて、空き領域を0埋めして…とやっていたが、どの程度の効果があるのか覚えていない。恐らく、当時はそんなに綿密にはやっていないことだろう…それはまたの機会に。

ディスクの変換が終わったら、仮想マシンを登録して起動。
起動時の質問には「移動しました」と答えた。
(上手く動いたら、元の仮想マシン・ディスクを削除するつもりなので、問題はないだろう)

Thin provision to Thin provision

Thick provision to Thin provision と同じ手順でコピーする。
データストアブラウザでコピーすると、Thick Provisionになってしまうらしいので、要注意。

ネットワークストレージ的なディスクはHDDに残す

この件は、差しあたりSamba共有のための仮想ディスクだけをHDDに残すことにした。
過去に何かを考えて、datastore1に別のディレクトリを作成し、そこに仮想ディスクを作成していた。

仮想マシンのディスク設定は、同じディレクトリにあるとディレクトリ指定がされないが、別のディレクトリにあるとdatastore1からのフルネームで記録がされている。
結果としてSSDに移動した仮想マシンも、datastore1にある仮想ディスクを指し示しているので、何もしなくても問題なくアクセスできるようになっていた。

以上で、本番環境にSSDを設置する作業は終了。
本番稼働開始！

しばらく様子を見て、問題なければ重複している仮想マシンを削除する。

Zabbixユーザーの追加(2023/06/20追記)

ESXiの中でにある仮想ホストでZabbix稼働させており、そのZabbixからESXiを監視していたのを忘れていた。

ユーザーの作成はすぐにできたのだけれど、ロールの割り当て方がなかなか分からなかった…
　ホスト → アクション → 権限
とすると、権限を割り当てる画面が表示された。

Zabbix監視用のユーザーは、読み取り専用で問題なく動くので、そうした。

調べたこと

カーネルパラメーター

カーネルパラメーターにどんなものがあるのか調べてみた。
GitHub / lamw / esxi-advanced-and-kernel-settings

やりたかったことは、ESXiの画面を640×480の解像度で表示させること。
だけど、そのようなカーネルオプションは見つからなかった。

ファームウェアのセットアップ画面に入る

起動を遅らせる方法と、セットアップ画面に入るようにセットする方法がある。
VMware / POST 画面がすぐにクリアされてしまう場合の BIOS へのアクセス (1004129)

いつも待たされる…というのはイマイチなので、1回だけファームウェアのセットアップに入る設定を追加しておく。

仮想マシン名.vmx

bios.forceSetupOnce = "TRUE"

これでファームウェアのセット画面に入るので、心ゆくまで設定をする。
次回起動時には、この行はなくなっている。

いつも待たされてOK！という場合には、ファームウェアにアクセスできる時間を長くしておく方法もある。

bios.bootDelay = "5000"

数字はミリ秒とのことなので、上記設定で5秒となる。

コンソールログイン

確か、コンソールでログインできたはずだけど…
VMware / ESXi 5.x, 6.x および 7.x での ESXi Shell の使い方 (2004746)

タイトル画面でF2を押して、System Customizationに入る。
Troubleshooting Options → Enable ESXi Shellで[Enter] とすると、右側が「ESXi Shell is Enabled」になる。

この状態で、[ALT]+[F1]を押すと、ログインプロンプトが表示される。
そこで、ユーザー・アカウントの情報を入力すれば、ログインすることができる。

起きたこと

ちょっとどうしようもない問題が発生していた。

DX4840に取り付けられたGPUがうなりを上げていて、どうやら最終的にはハングアップしているようだ。
今回久しぶりにDX4840を持ってきて操作をしていたので、

別にGPUを使うような処理をしているようなつもりはないが、段々とGPUが熱くなってくる。
更にしばらくすると、GPUに取り付けられたファンが全開で回り始める。
小さなファンなので高い音がする。
そのまましばらく操作をしていたら、モニターの信号が消えてしまった。
キーボードを押しても復帰しない、何も起きない。

という状態になっていたことに初めて気が付いた。

その昔、メインPCとしてDX4840を使っていた頃、コンソールっぽい画面で長時間放置すると、PCがうるさくなる記憶(確かBIOS設定画面でもそうなった記憶)。
その頃は気付いてなかったけれど、そうかあの高い音はGPUだったのか…どうやらこのGPUはコンソールの画面表示が苦手だったのかもしれない、知らんけど。

ということで、コンソール画面を薄暗い表示にするんじゃなく、消す設定はないのかと調べてみたが、
「GPUを仮想マシンにパススルーして、そのOSでモニターを切るしかないよね…」という情報しか見つからなかった。
vmware VMTN Communities / How can I turn off a Laptop Screen in ESXi 5?

DX4840にはその仮想化機能がないので無理…

もしかしたら、解像度の変更方法ってないかな。できるだけ頑張らない解像度を探せば良いかも、と思ったが、そんなことはできないというやりとりを発見。
vmware VMTN Communities / esxi host server screen resolution
カーネルパラメーターを見てみたけれど、1ピクセルを何ピクセルに引き延ばすか、という拡大表示の設定はあるけれど、解像度を変える設定は見つからなかった。

それなら、ビデオカードを外してしまえ！とやってみたが、BIOSがエラーを検知して先に進まない。
BIOS設定でエラーが発生しても止めないように設定してみたが、それでもエラーを検知して先に進まない。
ビデオカードは必須なのね…。

マザーボードにモニターのコネクターが付いているから、そちらが使えるんじゃ？なんか、チップセットもグラフィック機能を搭載しているようだし…と思ったけれども、BIOSにその設定がない。ダメ元でコネクターにケーブルを差し込んでみたけれど、信号が来ない。どうやら、コネクターはそこにあるだけで、実際には使えないようだ。

そうすると、ビデオカードは接続しておくより他はない。

だけど、ハングアップしちゃってるっぽいし、なんか放っておくと火事になるかもしれないと思ったので、ビデオカードを買うことにした。
幸い、PCI Express 2.0 x16というタイプらしいので、今売っているカードが使えそうだ。
なんか、あの黄色いコンソール画面を表示するために、GPUは凄く頑張らなきゃならないみたいだから、低電力タイプで程々にしか頑張れないタイプのものを選択した。

さいごに

土曜の午後にサービス停止、停止中はこのサイトにアクセスができなかった。
夕方にサービスを再開したが、仮想マシンをSSDへ移動していたため、ディスクアクセスが凄いことになっていたので、ページの表示に時間が掛かる状態になっていた。
アクセスしていただいた方には、タイムアウト・遅延を体験させることとなり、申し訳ない状態になったが、できあがった環境は実に快適だった。

このサイトについていえば、HTTP/2.0への対応でだいぶ反応が良くなっていたが、キャッシュできていないページへのアクセスも少し早くなったのではないかと思う。管理者用のダッシュボードへのアクセスも早くなった。

メンテナンスの面でいえば、仮想マシンの起動が速くなったし、各種アップデートも早くなった。各種コマンドへの反応も良くなったので、操作感が至極良くなった。

遠い昔に購入したPCだけれども、まだまだ現役。むしろCPU、ディスクアクセス共にスッカスカ、唯一不足しているのがメモリだけという状態。メモリーさえあれば、もっと活用のシーンが広げられるかもしれないと思っている。

中古のメモリーでも調達しようかな。え…新品 8GB x 2 = 16GBで2,600円？ポチッとな。
まだまだ頑張ってもらうよ、DX4840君。

作戦

環境