【vSphere】RHEL9のテンプレート仮想マシンを作成してみた（仮想マシンのカスタマイズ仕様使う前提）

どうも、Tです。

vSphere環境でRHEL9のテンプレート用仮想マシンを作っており、難儀したので忘れないように備忘録です。

これっ！という確実な設定はありませんので、本番環境作るときの参考情報程度にみてください。

本手順は、テンプレート仮想マシンからのクローン時にvSphereの仮想マシンのカスタマイズ仕様とカスタマイズスクリプトを使うことを前提にしています。
カスタマイズスクリプトについては、記事にしていますのでご参考ください。

環境

今回検証した環境です。

vSphere環境

VMware vCenter Server:8.0.1.00000(21560480)
VMware vSphere ESXi：8.0.1, 21495797

RHEL環境（テンプレート仮想マシン）

Red Hat Enterprise Linux release 9.2 (Plow)
open-vm-tools：12.1.5.39265 (build-20735119)

テンプレート仮想マシンは、ISOメディアから手動でインストールしたものを利用しています。

やりたいこと

概要

本手順では、テンプレートとして用したRHEL9の仮想マシンを仮想マシンのカスタマイズ仕様を使って簡単にクローンを作成しようという思いからはじまりました。

カスタマイズ仕様の設定は後ほど記載します。

内容

実施内容	実施タイミング	実施方法
RHNの削除	テンプレート作成時	手動
hostsファイルの確認	テンプレート作成時	手動
MACアドレスエントリ削除	テンプレート作成時	手動
マシンID削除	クローン時	カスタマイズ仕様で自動的に処理
SSHキー削除	クローン時（Pre処理）	カスタマイズ仕様のスクリプト
MAC・インターフェース関連削除	クローン時（Pre処理)	カスタマイズ仕様のスクリプト
ifcfg-rh 形式ファイルの削除	クローン時（Pre処理）	カスタマイズ仕様のスクリプト
keyfile形式ファイルの削除	クローン時（Pre処理）	カスタマイズ仕様のスクリプト
ifcfg-rh 形式と keyfile 形式変換	クローン時（Post処理）	カスタマイズ仕様のスクリプト

テンプレート仮想マシンを作成する（およびクローンするとき）に必要な項目をまとめました。

カスタマイズスクリプトが使えるようにしておく必要があります。

本記事では、上から順番に記載していきますが、RHEL9で重要となったkeyfileについて先に説明していきます。

ifcfg-rh 形式と keyfile 形式変換とは

RHEL9からネットワークファイル（接続プロファイル）の保存方法が大きく変わりました。

形式	ファイル場所	ファイル名	操作
【推奨】keyfile	/etc/NetworkManager/system-connections	<インターフェース名>.nmconnection	ツールベース
【非推奨】ifcfg-rh	/etc/sysconfig/network-scripts	ifcfg-<インターフェース名>	ファイルベース

RHEL9からは、ネットワークインターフェースの設定が従来のifcfg-rh形式が非推奨となり、NetworkManagerで管理し設定はnmcli・nmtuiなどのツールを使って管理をするkeyfileベースが推奨になりました。

どちらかしか使えないわけではなく、ISOから手動でインストールした場合は、keyfileになる設定ファイルが使用され、手動で追加・変更したなどでifcfgがあればifcfgが使われる（どちらを優先するかは優先度の設定による）という結構モヤモヤする状況になっています。

「/etc/sysconfig/network-scripts/readme-ifcfg-rh.txt」には下記のように記載されています。（一部抜粋）

Previously, NetworkManager stored network profiles in ifcfg format
in this directory (/etc/sysconfig/network-scripts/). However, the ifcfg
format is deprecated. By default, NetworkManager no longer creates
new profiles in this format.

Connection profiles in keyfile format have many benefits. For example,
this format is INI file-based and can easily be parsed and generated.

vSphereのカスタマイズ仕様で内部的に処理されるのは、ifcfgファイルです。カスタマイズ仕様のネットワーク設定値をデフォルト値としてもifcfgファイルが生成されて、keyfileは扱ってもらえません。2023年7月現在は、keyfileよりifcfgを優先する処理も行ってくれるようで、通常使う分には問題にならないのですが、ifcfgファイルが使われる状況は避けられない感じになっています。

個人的にカスタマイズ仕様は便利なので使いたけど、非推奨のifcfgファイルは使いたくないという思いから、テンプレート仮想マシンからクローンした後にカスタマイズ仕様の中のカスタムスクリプトでifcfg-rh形式からkeyfile形式に変換する方法にしました。

この前提のもと本記事を読み進めていただけると幸いです。

テンプレート仮想マシンの手動設定

RHNの削除

テンプレート仮想マシンがRHNに登録しているようであれば、下記のコマンドで登録を削除しておきます。

# subscription-manager unregister
# subscription-manager remove --all
# subscription-manager clean

unregister：RHNからシステムの登録を削除
remove –all：システムに登録しているサブスクリプションをすべて削除
clean：サーバーに影響を及ぼさずシステムとサブスクリプションデータをすべて削除

hostsファイルの確認

hostsファイルに不要な登録を削除しておきます。（下記参照）

# cat /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6

インストール直後は上記のように何も登録されていません。

MACアドレスエントリ削除

nmconnectionファイルにMACアドレスが登録されている場合は手動で削除しておきます。

# cat /etc/NetworkManager/system-connections/ens33.nmconnection
--割愛--
[ethernet]
mac-address=00:50:56:82:6C:25
--割愛--

RHEL9ではインストール直後のようなMACアドレスは登録されていませんでした。

また、MACアドレスを削除しておく必要はありますが、この後の手順で「ens33.nmconnection」ファイル自体を削除するため本記事に限っては本手順は不要です。

一般的な考慮点として記載しています。

仮想マシンのカスタマイズ仕様

カスタマイズ仕様の内容

検証に使用したカスタマイズ仕様設定を記載しておきます。

以後は、主にカスタマイズスクリプトについての説明になります。

#!/bin/sh
if [ x$1 == x"precustomization" ]; then
echo Do Precustomization tasks
rm -rf /etc/ssh/ssh_host_*
rm -rf /etc/udev/rules.d/70-persistent-*
rm -rf /etc/sysconfig/network-scripts/ifcfg*
rm -rf /etc/NetworkManager/system-connections/*nmconnection*
elif [ x$1 == x"postcustomization" ]; then
echo Do Postcustomization tasks
nmcli connection migrate
fi

マシンID削除

いきなりカスタマイズスクリプトではない説明になります。

RHELでは永続的に変更されてない、一意に識別するためのmachine-idが生成されています。※後半はxで置き換えています。

# cat /etc/machine-id
a8dbad134c0c45bxxxxxxxxxxxxx

テンプレート仮想マシンでは以下のようにIDが状態にしておくのですが、machine-idはない場合に起動時に自動生成されます。

# echo "uninitialized" > /etc/machine-id

いれるとしたらカスタマイズスクリプトのpre処理のタイミングですが、vSphereのカスタマイズ仕様を使用する場合、machine-idを自動生成してくれているので明示的な処理は不要です。考慮点として覚えておく必要があるため備忘録として記載しました。

【pre処理】SSHキー削除

カスタムスクリプトの下記の部分になります。

rm -rf /etc/ssh/ssh_host_*

SSHで使用される秘密鍵と公開鍵をすべて削除しています。

秘密鍵と公開鍵は存在しない場合は、自動的に作成されます（これはRHELの動作仕様でありvSphereのクローン処理とは関係ありません。）

【pre処理】MAC・インターフェース関連削除

カスタムスクリプトの下記の部分になります。

rm -rf /etc/udev/rules.d/70-persistent-*

実際この処理はなくとも大丈夫です。

RHEL6では「70-persistent-net.rules」ファイルでMACアドレスとインターフェース名を紐づける処理を行っていました。この方法はRHEL7以降非推奨となり、RHEL7以降は「Predictable Network Interface 命名」が使用されています。

ただ、RHEL9でもnet.ifnames=0を使うことによりRHEL6のような挙動を行うことが可能です。そのため、ファイルがもし存在した場合は削除する処理を念のため入れています。

【pre処理】ifcfg-rh 形式ファイルの削除

カスタムスクリプトの下記の部分になります。

rm -rf /etc/sysconfig/network-scripts/ifcfg*

ifcfgファイルが存在していた場合、なにか不穏な動きをしないか確定できなかっためカスタマイズが始まる前に削除する処理を念のためいれています。「*ifcfg*」のようにしていないのは、「readme-ifcfg-rh.txt」を削除しないようにするためです。

【pre処理】keyfile形式ファイルの削除

カスタムスクリプトの下記の部分になります。

rm -rf /etc/NetworkManager/system-connections/*nmconnection*

post処理でカスタマイズ仕様により生成されたifcfgファイルをkeyfileに変換をしますが、元のkeyfile（ens33.nmconnectionなど）が残っている状態で変換を行うと元のkeyfile名の後ろに長い英数字を付けて新たなファイルを生成する動作を確認できたため事前にkeyfileを削除しています。

【post処理】ifcfg-rh 形式と keyfile 形式変換

カスタムスクリプトの下記の部分になります。

nmcli connection migrate

上記コマンドで、存在するすべてのifcfgファイルをもとに、keyfileを生成します。

なお、変換が成功した場合は元のifcfgは自動的に削除されますので変換コマンド1つで問題ありません。

クローン後の確認

あとは、テンプレートからクローンする際に「ゲストOSのカスタマイズ」で作成した仕様を指定すればネットワーク回りを考慮したクローンが行えます。

クローン後は各所カスタマイズした部分などを確認すると思いますので割愛しますが、ネットワーク部分は「nmcli -f NAME,DEVICE,FILENAME connection show」の結果を確認しておきましょう。

出力結果を見ると各インターフェースがどの構成ファイルを使用しているのかわかります。

# nmcli -f NAME,DEVICE,FILENAME connection show
NAME DEVICE FILENAME
ens33 ens33 /etc/NetworkManager/system-connections/ens33.nmconnection
lo lo /run/NetworkManager/system-connections/lo.nmconnection

処理がうまくいっていない場合、同じ名前のインターフェースが異なる設定ファイルで読み込まれ不要なはずのごみインターフェースが表示されたりします。

RHEL9のクローン処理に関する問題

その他、本記事の検証をしている際に見つけたRHEL9のクローンに関する情報をまとめてきます。

※vSphere環境が関係ないものもあります。

vSphere7環境でkeyfile絡みの問題でした。本記事と同じように回避可能かと思います。

vSphereでクローンしたときに、keyfile絡みでネットワークが正常に設定できない問題です。回避策もあり、新しいvSphereパッチでは解決になっていますが、どちらもifcfgを使うのが現在のvSphereのスタンダードな姿勢のようです。

virt-sysprepをRHELで使った場合のLVMのUUID絡みの問題です。vSphere環境では特に問題なさそうでした。

参考

まとめ

RHEL9でいよいよnetwork-scriptsパッケージが削除されてNetworkManagerに統一されてしまったため、推奨でkeyfileに乗り換えてみました。

カスタマイズ仕様自体は便利なので、VMware社さんも対応してくれると嬉しいなぁ。