grubで止まったEFI機のLinuxを起動させる

Oracle Cloud上のCentOS 7インスタンスをOracle Linux 7にコンバートさせたら、一部のパッケージがうまくインストールできず、centos2ol.sh が途中で失敗した。

yum distro-syncを実行したらうまくいったので、大丈夫かな?と思ったら、grub関連が更新できずに起動に失敗した模様。

Oracle Cloudの場合、Web管理コンソールから該当インスタンスのディスプレイをVNC接続で表示するための設定ができるので、それでつなげてみたところ下記の様にgrubで停止していた。

まず、ディスクとパーテーションがどう認識されているが分からないので「ls」を実行します。

そうすると、「(ディスク名)」と「(ディスク名),(パーテーション名)」の一覧が表示されます。

grub> ls
(hd0)  (hd0,gpt3)  (hd0,gpt2)  (hd0,gpt1)  (fd0)  (fd1)
grub> 

上記の場合、hd0の中にパーテーションが3つある、ということになります。

各パーテーションのファイルシステムがなんなのかを「ls (hd0,gpt0)」と実行すると表示されます。

grub> ls (hd0,gpt2)
(hd0,gpt2): Filesystem is unknown.
grub> ls (hd0,gpt3)
(hd0,gpt3): Filesystem is xfs.
grub> ls (hd0,gpt1)
(hd0,gpt1): Filesystem is fat.
grub>

上記の結果により、パーテーション1:FAT、パーテーション3:XFS、パーテーション2:不明となります。

「ls (hd0,gpt1)/」と最後に/をつけると中にどんなファイル/ディレクトリがあるかを確認出来ます。

grub> ls (hd0,gpt1)/
efi/
grub> ls (hd0,gpt3)/
./ ../ boot/ dev/ proc/ run/ sys/ etc/ var/ root/ tmp/ usr/ bin sbin lib lib64
home/ media/ mnt/ opt/ srv/
grub>

上記により efi/があるパーテーション1は、/boot/efi があるパーテーション
パーテーション3は / があるパーテーションとなり
消去法的にパーテーション2は、ファイルシステムがないのでswapパーテーションとなる。

起動するにあたっては、linuxefi でvmlinuzファイルと、root=で/パーテーション指定を行い、initrdedi でinitramfsファイルを指定する形となる。

下記の様に入力して起動を行う。

grub> linuxefi (hd0,gpt3)/boot/vmlinuz-5.4.17-2102.202.5.el7uek.x86_64 root=/dev/sda3
grub> initrdefi (hd0,gpt3)/boot/initramfs-5.4.17-2102.202.5.el7uek.x86_64.img
grub> boot

なお、vzlinuzやinitramfsのファイル名は分からないと思うが、その場合は下記の様に「initrdefi (hd0,gpt3)/boot/initra」まで入力してからタブキーを押すと候補が表示されるので、それを利用すると良い。

bootが開始されると、クラウド上でも普通のLinux環境と同じように起動表示がある。

で、ログインが出来るようになった。

Oracle Cloud上のインスタンスは、ssh keyでログインしているのでパスワードがわからないので、ssh経由で接続して続きを行う。

まず、起動できなかった原因は /etc/grub2-efi.cfg (/boot/efi/EFI/redhat/grub.cfg)が存在しないということだった。

「sudo grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg」を実行して、grub.cfgを再作成することで対応できる。

参照:CentOS8からOracle Linux 8への移行1

再作成して再起動するときちんと下記の様にkernel選択画面が表示され、自動起動することが確認出来た。

Oracle Cloud上の古いOracle Linux 7インスタンスのyum設定を更新する

「Notices: General Notices for Oracle Linux Images」というページに「2021.03 – Yum Update for Oracle Linux 7 and Oracle Linux 8 Instances」というのを発見した。

たしかに2021年3月より前に作成したインスタンス Oracle-Linux-7.7-2019.08.28-0, Oracle-Autonomous-Linux-7.8-2020.05-0 には oci-linux-config というパッケージはインストールされていなかった。

$ rpm -qa|grep oci-linux-config
$

とりあえず、ここに書いてある手順通りに進めていく

$ curl -H "Authorization:Bearer Oracle" -sfm 25 http://169.254.169.254/opc/v2/instance/ 2>/dev/null | jq -r '.regionInfo.realmKey'
oc1
$

上記では「oc1」という結果が出力されているが、「oc1」~「oc4」ならOKとのこと。

oci-linux-config パッケージをインストール

$ sudo yum -y install oci-linux-config
読み込んだプラグイン:langpacks, ulninfo
依存性の解決をしています
--> トランザクションの確認を実行しています。
---> パッケージ oci-linux-config.noarch 0:1.0-3.el7 を インストール
--> 依存性解決を終了しました。

依存性を解決しました

================================================================================
 Package               アーキテクチャー
                                   バージョン      リポジトリー            容量
================================================================================
インストール中:
 oci-linux-config      noarch      1.0-3.el7       ol7_ociyum_config       13 k

トランザクションの要約
================================================================================
インストール  1 パッケージ

総ダウンロード容量: 13 k
インストール容量: 29 k
Downloading packages:
oci-linux-config-1.0-3.el7.noarch.rpm                      |  13 kB   00:00
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  インストール中          : oci-linux-config-1.0-3.el7.noarch               1/1
IMPORTANT: PLEASE NOTE!!  Oracle Linux yum repository configurations have been updated. New repository configuration files have been installed but are disabled.  To complete the transition, run this script as root user:

/usr/lib/oci-linux-config/oci_yum_configure.sh

  検証中                  : oci-linux-config-1.0-3.el7.noarch               1/1

インストール:
  oci-linux-config.noarch 0:1.0-3.el7

完了しました!
$

/usr/lib/oci-linux-config/oci_yum_configure.sh を実行して /etc/yum.repos.d/ のレポジトリファイルを作成

$ ls -l /etc/yum.repos.d/
合計 84
-rw-r--r--. 1 root root  488  2月 17 06:40 ksplice-ol7.repo
-rw-r--r--. 1 root root  273  5月 13 15:39 oracle-epel-ol7.repo
-rw-r--r--. 1 root root  242  8月 15  2019 oracle-epel-ol7.repo.20190815
-rw-r--r--. 1 root root  252  5月 13 15:38 oracle-epel-ol7.repo.20210217
-rw-r--r--. 1 root root 4322  6月 11 04:12 oracle-linux-ol7.repo
-rw-r--r--. 1 root root 3825  7月 10  2020 oracle-linux-ol7.repo.20200710
-rw-r--r--. 1 root root 4586  6月  9 12:57 oracle-linux-ol7.repo.rpmnew
-rw-r--r--. 1 root root 1067  2月 26 04:35 oracle-php-ol7.repo
-rw-r--r--. 1 root root  797  4月  6  2020 oracle-php-ol7.repo.20200406
-rw-r--r--. 1 root root  275  8月 15  2019 oracle-softwarecollection-ol7.repo
-rw-r--r--. 1 root root  276  2月 17 06:38 oracle-softwarecollection-ol7.repo.rpmnew
-rw-r--r--. 1 root root 1041  2月  5 04:15 oraclelinux-developer-ol7.repo
-rw-r--r--. 1 root root  802 12月 27  2019 oraclelinux-developer-ol7.repo.20200406
-rw-r--r--. 1 root root 3117  9月 30  2019 public-yum-ol7.repo.sav
-rw-r--r--. 1 root root 2577  5月 28  2020 uek-ol7.repo
-rw-r--r--. 1 root root 2108  4月  6  2020 uek-ol7.repo.20200406
-rw-r--r--. 1 root root 2587  2月 17 06:42 uek-ol7.repo.rpmnew
-rw-r--r--. 1 root root  225  5月 28  2020 virt-ol7.repo
-rw-r--r--. 1 root root  226  2月 17 06:42 virt-ol7.repo.rpmnew
$ sudo /usr/lib/oci-linux-config/oci_yum_configure.sh
読み込んだプラグイン:langpacks, ulninfo
No packages marked for update
Disabling Repository ol7_UEKR6
Repository ol7_developer already enabled
Repository ol7_developer_EPEL already enabled
Repository ol7_developer_php74 already enabled
Repository ol7_ksplice already enabled
Repository ol7_latest already enabled
Repository ol7_software_collections already enabled
Enabling Repository ol7_UEKR5
Enabling Repository ol7_addons
Repository ol7_developer already enabled
Repository ol7_developer_EPEL already enabled
Repository ol7_developer_php74 already enabled
Repository ol7_ksplice already enabled
Repository ol7_latest already enabled
Enabling Repository ol7_ociyum_config
Enabling Repository ol7_optional_latest
Repository ol7_software_collections already enabled
$ ls -l /etc/yum.repos.d/
合計 104
-rw-r--r--. 1 root root  488  2月 17 06:40 ksplice-ol7.repo
-rw-r--r--. 1 root root  273  5月 13 15:39 oracle-epel-ol7.repo
-rw-r--r--. 1 root root  242  8月 15  2019 oracle-epel-ol7.repo.20190815
-rw-r--r--. 1 root root  252  5月 13 15:38 oracle-epel-ol7.repo.20210217
-rw-r--r--. 1 root root 4586  6月 16 10:15 oracle-linux-ol7.repo
-rw-r--r--. 1 root root 3825  7月 10  2020 oracle-linux-ol7.repo.20200710
-rw-r--r--. 1 root root 4322  6月 11 04:12 oracle-linux-ol7.repo.bkp
-rw-r--r--. 1 root root 4586  6月  9 12:57 oracle-linux-ol7.repo.rpmnew.bkp
-rw-r--r--. 1 root root 1067  2月 26 04:35 oracle-php-ol7.repo
-rw-r--r--. 1 root root  797  4月  6  2020 oracle-php-ol7.repo.20200406
-rw-r--r--. 1 root root  276  2月 17 06:38 oracle-softwarecollection-ol7.repo
-rw-r--r--. 1 root root  275  8月 15  2019 oracle-softwarecollection-ol7.repo.bkp
-rw-r--r--. 1 root root  276  2月 17 06:38 oracle-softwarecollection-ol7.repo.rpmnew.bkp
-rw-r--r--. 1 root root 1041  2月  5 04:15 oraclelinux-developer-ol7.repo
-rw-r--r--. 1 root root  802 12月 27  2019 oraclelinux-developer-ol7.repo.20200406
-rw-r--r--. 1 root root 3117  9月 30  2019 public-yum-ol7.repo.sav
-rw-r--r--. 1 root root 2587  6月 16 10:15 uek-ol7.repo
-rw-r--r--. 1 root root 2108  4月  6  2020 uek-ol7.repo.20200406
-rw-r--r--. 1 root root 2577  5月 28  2020 uek-ol7.repo.bkp
-rw-r--r--. 1 root root 2587  2月 17 06:42 uek-ol7.repo.rpmnew.bkp
-rw-r--r--. 1 root root  226  2月 17 06:42 virt-ol7.repo
-rw-r--r--. 1 root root  225  5月 28  2020 virt-ol7.repo.bkp
-rw-r--r--. 1 root root  226  2月 17 06:42 virt-ol7.repo.rpmnew.bkp
$

以前のrepoファイルは全て bkpという名前にリネームされて置き換わった感じですね。

各レポジトリファイルの変更点は「baseurl=https://yum$ociregion.oracle.com/repo/OracleLinux/」という記載だったものが「baseurl=https://yum$ociregion.$ocidomain/repo/OracleLinux/」というように「oracle.com」以外のドメインが設定される可能性に配慮したものに変更されていた。

この$ociregionや$ocidomainはどこで設定されているかというと /etc/yum/vars/ にあるファイルで定義されています。

$ ls -l /etc/yum/vars/
合計 12
-rw-r--r--. 1 root root 11  6月 16 10:15 ocidomain
-rw-r--r--. 1 root root 14  6月 16 10:15 ociregion
-rw-r--r--. 1 root root 13  6月 16 10:15 region
$ cat /etc/yum/vars/ocidomain
oracle.com
$ cat /etc/yum/vars/ociregion
-us-phoenix-1
$ cat /etc/yum/vars/region
us-phoenix-1
$

Oracle Cloud上のLinuxインスタンスでiscsistartというサービスが起動失敗している

Oracle Cloud上Linuxインスタンスでol-consolebaud.serviceの起動に失敗している」の件で、これまでに作ったインスタンスの状態を確認していったところ、一番古いLinuxインスタンスでは「iscsistart_169.254.0.2:::1:iqn.2015\http://x2d02.oracle.boot:uefi.service」というサービスの起動に失敗していた。

ぐぐるとOracleサポートの「OCI: iscsistart attempts to connect iscsi target when the network link is not ready (Doc ID 2610486.1)」が出てくるがサポートがないので内容がわからない。

とりあえず、起動失敗しているものと起動成功しているものの/etc/default/grubを比較してみたところ、起動成功しているもののGRUB_CMDLINE_LINUX行には「rd.iscsi.bypass」が追加されていた。

GRUB_CMDLINE_LINUX行に追加して「grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg」を実行してgrub設定を更新、再起動して、問題無く起動するようになった。


確認したOracle Linuxインスタンスの /etc/default/grub設定の比較

Oracle-Linux-7.7-2019.08.28-0 の /etc/default/grub

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_DISABLE_RECOVERY="true"
GRUB_TERMINAL="console"
GRUB_CMDLINE_LINUX="crashkernel=auto LANG=en_US.UTF-8 console=tty0 console=ttyS0,9600 rd.luks=0 rd.lvm=0 rd.md=0 rd.dm=0 netroot=iscsi:169.254.0.2:::1:iqn.2015-02.oracle.boot:uefi iscsi_param=node.session.timeo.replacement_timeout=6000 net.ifnames=1 nvme_core.shutdown_timeout=10 ipmi_si.tryacpi=0 ipmi_si.trydmi=0 ipmi_si.trydefaults=0 libiscsi.debug_libiscsi_eh=1 loglevel=4"

CentOS-7-2020.06.16-0 の /etc/default/grub

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_DISABLE_RECOVERY="true"
GRUB_TERMINAL="console"
GRUB_CMDLINE_LINUX="crashkernel=auto LANG=en_US.UTF-8 transparent_hugepage=never console=tty0 console=ttyS0,9600 libiscsi.debug_libiscsi_eh=1 rd.luks=0 rd.lvm=0 rd.md=0 rd.dm=0 ip=dhcp netroot=iscsi:169.254.0.2::::iqn.2015-02.oracle.boot:uefi iscsi_param=node.session.timeo.replacement_timeout=6000 net.ifnames=1 rd.iscsi.bypass"

Oracle-Autonomous-Linux-7.8-2020.05-0 の /etc/default/grub

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_DISABLE_RECOVERY="true"
GRUB_TERMINAL="console"
GRUB_CMDLINE_LINUX="crashkernel=auto LANG=en_US.UTF-8 console=tty0 console=ttyS0,9600 rd.luks=0 rd.lvm=0 rd.md=0 rd.dm=0 rd.iscsi.bypass=1 netroot=iscsi:169.254.0.2:::1:iqn.2015-02.oracle.boot:uefi iscsi_param=node.session.timeo.replacement_timeout=6000 net.ifnames=1 nvme_core.shutdown_timeout=10 ipmi_si.tryacpi=0 ipmi_si.trydmi=0 ipmi_si.trydefaults=0 libiscsi.debug_libiscsi_eh=1 loglevel=4"

Oracle-Linux-8.3-2021.05.12-0 の /etc/default/grub

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=true
GRUB_TERMINAL="console"
GRUB_CMDLINE_LINUX="crashkernel=auto LANG=en_US.UTF-8 console=tty0 console=ttyS0,9600 rd.luks=0 rd.md=0 rd.dm=0 rd.lvm.vg=ocivolume rd.lvm.lv=ocivolume/root rd.net.timeout.carrier=5 netroot=iscsi:169.254.0.2:::1:iqn.2015-02.oracle.boot:uefi rd.iscsi.param=node.session.timeo.replacement_timeout=6000 net.ifnames=1 nvme_core.shutdown_timeout=10 ipmi_si.tryacpi=0 ipmi_si.trydmi=0 libiscsi.debug_libiscsi_eh=1 loglevel=4 ip=single-dhcp crash_kexec_post_notifiers"

Oracle-Linux-8.3-aarch64-2021.05.12-0 の /etc/default/grub

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=true
GRUB_TERMINAL="console"
GRUB_CMDLINE_LINUX="crashkernel=auto LANG=en_US.UTF-8 console=ttyAMA1 console=ttyAMA0,115200 rd.luks=0 rd.md=0 rd.dm=0 rd.lvm.vg=ocivolume rd.lvm.lv=ocivolume/root rd.net.timeout.carrier=5 netroot=iscsi:169.254.0.2:::1:iqn.2015-02.oracle.boot:uefi rd.iscsi.param=node.session.timeo.replacement_timeout=6000 net.ifnames=1 nvme_core.shutdown_timeout=10 ipmi_si.tryacpi=0 ipmi_si.trydmi=0 libiscsi.debug_libiscsi_eh=1 loglevel=4 ip=single-dhcp crash_kexec_post_notifiers"

Oracle Cloud上Linuxインスタンスでol-consolebaud.serviceの起動に失敗している

2020年にOracle Cloud上に作ったLinuxインスタンスの状態を「systemctl status」で確認してみたら、ol-consolebaud.serviceの起動に失敗していた。

ol-consolebaud.service: main process exited, code=exited, status=1/FAILURE
Failed to start Check console baud rate.
Unit ol-consolebaud.service entered failed state.
ol-consolebaud.service failed.

検索してみるとRogerio Eguchi Blog の「OCI – ol-consolebaud.service」を発見。

/etc/default/grub に書かれているシリアルコンソール設定の速度が9600から115200に変更になったことが原因のようである。

Oracle Cloud Infrastructure ドキュメントを確認すると「インポートされたLinuxイメージでのシリアル・コンソール・アクセスの有効化」のブートローダの構成で設定している速度が115200になっている。そして、”シリアルコンソールアクセスの検証”では9600になっていてドキュメントの整合性がとれていない・・・というわけで、途中で変更されたようなのだが、All Oracle Linux 7.x Images の履歴をみたけど、それっぽい変更が見当たらない・・・うーん?

まあ、ともかく原因は判明したのでGRUB_CMDLINE_LINUX行の「console=ttyS0,9600」を「console=ttyS0,115200」に変更。

そして、 「grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg」でgrubブートローダに変更を反映して、再起動。

これでol-consolebaudが正常に起動するようになった。

ESXi 7.0 Update 1からSDカード/USBメモリ起動の場合に書き込み回数性能が重要になった件について

2023/05/15追記:「SD card/USB boot device revised guidance (85685)」の2023年2月更新版ではvSphere 8環境での取り扱いについて明記されている。

対処方法1: 普通のローカルディスク起動に変更
対処方法2: SD/USBからブートするが、別途データ保存用ローカルディスクを用意
対処方法3: ESXiをSANのディスクから直接ブートする
対処方法4: SD/USBからブートして、VMFS領域にデータを置く設定
対処方法5: SD/USBからブートして、RAMDISK上にデータを置く設定(再起動すると消える)

基本的にはローカルディスクを使え、という話のようです。


2022/08/05追記:「SD card/USB boot device revised guidance (85685)」にてvSphereの新バージョン(7.0の次)ではSDカード/USBメモリはブートの起点としてしか使えなくなり、別途何らかのストレージにOSDATAを配置する必要がある、ということになる。(新バージョンではRAMDISKは非推奨)


VMware vSphere / ESXi 7.0 から ESXiのブートディスクの構造が変更になった。

VMware vSphere Blog「vSphere 7 – ESXi System Storage Changes
「ESXi のシステム ストレージの概要」の「ESXi 7.0 のシステム ストレージの変更

ESXi 6.0時代 /scratch となっているパーテーションとかあるが、基本的に起動したあとデータ書き込みはあまりないかたちで運用されていた。

ところがESXi 7.0からは細かく分かれていたパーテーションがESX-OSDataパーテーションに統合されている。しかも、ここに書き込みが行われるようになった。

そして、ESXi 7.0 Update 1 / Update 2においてSDカード / USBメモリへの書き込み手法が変更され、起動ディスクに対して従来と比較すると多量の書き込み操作が実行されることになった。

これにより、ESXi 7.0 Update 1 / Update 2において、SDカード/USBメモリ起動にしている場合に、書き換え回数超過によるSDカード/USBメモリのアクセス不可事例が発生しやすくなっているようだ。

VMware KB VMFS-L Locker partition corruption on SD cards in ESXi 7.0 (83376)
VMware Technolopy Network「SD Boot issue Solution in 7.x

上記KB83376を見ると、ESXi 7.0(初期)ではI/O抑制機能があったが、ESXi 7.0 Update 1ではなくなったことが発生しやすくなった要因の1つであるようだ。

しかも、VMware的には「ESXi のシステム ストレージの概要」で、「ESX-OSData は 高耐久性ストレージ デバイス上に作成する必要があります。」と書いてあるから、書き換え回数上限が低いものを使わないのは当然でしょ、というスタンスな模様。

OEMメーカが選定したSDカードなどが死んだとしても、それはその部材を選んだOEMメーカ側の責任だということらしい。

実際、DELLの「VMware vSphere 7.x on Dell EMC PowerEdge Servers Getting Started Guide」の「Getting started with VMware vSphere」をみると、ESXi 7.0ではSDカードは推奨しない、と書いてある。

NOTE: If you had ordered VMware ESXi with your Dell EMC PowerEdge server, it is preinstalled on your server. The ESXi installer media is required for reinstallation. The Boot Optimized Storage Solution (BOSS) card is the preferred non-HDD or SSD device for VMware ESXi 7.0 installation. The Dell Internal Dual SD Module (IDSDM) install is no longer recommended due to write endurance issues with the SD flash media. For more information, see the Storage Requirements for ESXi 7.0 Installation or Upgrade section on the VMware ESXi Installation and Setup Guide or see VMware Knowledge Base article 2145210.

さて、この問題について、とることができる方策は下記の5つが考えられる。

その1) 高耐久性のものに変更する(USB接続のSSDや、MLCチップのSDカードなど)
その2) 普通のSSDやHDD起動に変更する
その3) ESXi 7.0 Update 2用の現象低減パッチが7月中にリリース予定(ただし、低減、である)
      → 2021/08/24リリースのESXi 7.0 U2cで提供開始
その4) メインメモリを消費してRamdiskを作成し、そこに書き込ませる
その5) あきらめて、壊れたら交換&ESXi再セットアップ

その4の手法はVMware KB83376 内にリンクがあり「High frequency of read operations on VMware Tools image may cause SD card corruption (2149257)」で説明されている。

ドキュメント的にはESXi 6.0 と ESXi 6.5用になっているが、ESXi 7.0でも適用できるようだ。

ESXi 7.0のshellに入って、現在の /UserVars/ToolsRamdisk の設定を確認

# esxcli system settings advanced list -o /UserVars/ToolsRamdisk
   Path: /UserVars/ToolsRamdisk
   Type: integer
   Int Value: 0
   Default Int Value: 0
   Min Value: 0
   Max Value: 1
   String Value:
   Default String Value:
   Valid Characters:
   Description: Use VMware Tools repository from /tools ramdisk.
#

「Int Value: 0」ということなので、現在は「0」となっている。

これを1に変更するため、以下を実行する

# esxcli system settings advanced set -o /UserVars/ToolsRamdisk -i 1
#

変更が反映されたか確認

# esxcli system settings advanced list -o /UserVars/ToolsRamdisk
   Path: /UserVars/ToolsRamdisk
   Type: integer
   Int Value: 1
   Default Int Value: 0
   Min Value: 0
   Max Value: 1
   String Value:
   Default String Value:
   Valid Characters:
   Description: Use VMware Tools repository from /tools ramdisk.
#

「Int Value: 1」となっていたら変更されている。

この後、ESXi を再起動して、RAMディスクを実際に稼働させる。

ESXi設定のバックアップ&リストア

SDカード/USBメモリが壊れることを許容する場合、ESXiの設定ファイルをバックアップしておき、再セットアップ時にリストアする、という手法が考えられる。

手法はVMware KB「ESXi ホストの構成のバックアップ方法 (2042141)

リストアの際、ESXiにIPアドレスを割り当てておく必要がある。


具体的にどれくらいの書き込み要求があるんだろう?と調べて見た。

DELL PartnerSEつぶやきブログ「BOSSってなんだろう?」から、ESXiが要求するSSD/Flashデバイスに対する要求要件が書かれた「vSphere SSD and Flash Device Support (2145210)」を発見

それによると下記のようになっている。

Table 1: SSD/Flash Endurance Requirements 

SSD/Flash Device Use CaseJEDEC Endurance RequirementWorkload CharectizationNotes
Host Swap Cache365 TBW or betterRandom, infrequent writesHost memory rarely overcommitted
3650 TBW or betterRandom, frequent writesHost memory routinely overcommitted
Regular Datastore3650 TBW or better1Virtual Machine workload dependentSize >= 1TB needs more endurance
vSphere Flash Read Cache (VFlash)365 TBW or betterVirtual Machine workload dependentSize <= 4TB
ESXi Boot Device0.5 TBW minimum2
2 TBW recommended2,6
Sequential (WAF <10)Size >= 4GB3
ESXi Coredump Device0.1 TBW minimum2,4Extremely sequential (WAF ~1)Size >= 4GB3,4
ESXi Logging Device64 TBW (dedicated device)
128 TBW (colocated) 2,5
Sequential7
(WAF < 100 block mode, WAF < 10 page mode)
Size >= 4GB2,3

ESXi起動デバイスとしては2TBWぐらいだったものが、ログデバイスとしての128TBWぐらいが要求され、USBメモリ上を仮想マシンを置く用のVMFSデータストアとしての使うとなると3650TBWが要求される、などと、起動ディスクとして使うだけの場合より50倍以上の要求がある、ということがわかった。

そりゃ、あっさり死にますね


2022/05/06追記

ESXi 7.0U1 では /UserVars/ToolsRamdisk という変数自体がない。

ESXi 7.0U3 だと /UserVars/ToolsRamdisk はあり、システムのインストール先が HDD か SDカードかによって、「Default Int Value」の値が異なっていた。

HDDでは「0」で、SDカードだと「1」となっていた。

このため、手動で変更する必要性は薄いようだ。(SDカードなら必ず”1″となるかは、ドキュメント上に特に記載されていないため、確認を行うこと)


2022/07/21追記

VMware KBに「SD card/USB boot device revised guidance (85685)」という記事が登場

SDカードやUSBメモリからの起動は可能であるものの推奨しないこととなった。

NVMeやSSDから起動しろ、とのこと。

SDカードやUSBメモリから起動した場合でも、OSDATAパーテーションを別のHDDなどに設定する、ということが推奨される。

ESXi 7.xまではRAMDISKで回避することもできるが、次のESXiではその設定はなくなる、とのこと

モバイルバージョンを終了