０．前書き
久しぶりの更新です。
先日、仮想基盤をESXi HypervisorからProxmox VE(以下PVE)に変更しました。
今回はPVE上で仮想マシンデプロイを自動化するスクリプトを書いたので、共有と使い方の説明を行う回です。
AlmalinuxとUbuntu用で２つ作成しましたが、今回はAlmalinux版で説明しようと思います。
大まかな処理の流れは以下です。
①PVE上からBashスクリプトを実行
②Bashスクリプトにより、YAMLの書き換え
③BashスクリプトからYAMLの内容が読みこまれた上でVMの起動
④VM起動後にCloud-initの処理開始
⑤IP設定やパッケージインストール、ClamavとPostfixの設定が完了
すべて完了すると、毎日ランダムな時間(Ubuntuは朝6時ごろ)にウイルススキャンが行われて、不審なシグネチャを持つファイルがあると、一時退避用のフォルダに移動させた上で指定のGmailアドレスにメールを飛ばします。
Gmailではアプリパスワードが必要ですので事前に用意してください。
参考サイト様：https://jpn.faq.panasonic.com/app/answers/detail/a_id/2155/~/google%E3%82%A2%E3%82%AB%E3%82%A6%E3%83%B3%E3%83%88%E3%81%AE%E3%82%A2%E3%83%97%E3%83%AA%E3%83%91%E3%82%B9%E3%83%AF%E3%83%BC%E3%83%89%E8%A8%AD%E5%AE%9A%E6%89%8B%E9%A0%86%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6
１．環境説明
では環境説明からです。
①仮想基盤
ハイパーバイザ：PVE8.1.4
ホスト名：proxmox
IPアドレス：IPアドレス：172.16.0.1
【事前にインストールが必要なもの】
yq：YAMLファイルの編集に必要
②ファイルサーバ
ホスト名：fileserver
IPアドレス：IPアドレス：172.16.1.1
※今回のツールに必要というわけではなく、あくまで私の環境ではVMのイメージファイルや今回のツールをここに置いているため記載。イメージファイルもツールもPVEからアクセスできればどこでもよいです。
③VMのイメージファイル
Almalinux：AlmaLinux-9-GenericCloud-9.3-20231113.x86_64.qcow2
公式リポジトリ：https://repo.almalinux.org/almalinux/9/cloud/x86_64/images/AlmaLinux-9-GenericCloud-9.3-20231113.x86_64.qcow2
※Ubuntu版にするなら（今回は説明しません）
Ubuntu：noble-server-cloudimg-amd64.img
公式リポジトリ：https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img
２．ツールの構成
ツールのフォーマットはGitlabに上げていますので、ローカルに落として煮るなり焼くなりしてください。
■ツールの構成
①Bashスクリプト
PVE上で実行するので、アクセスできる場所に実行可能な権限で格納してください。
とりあえずディストリビューション別で２つ分作成しています。
・alma_auto.sh
・ubuntu_auto.sh
②YAMLファイル
Cloud-init用の構成定義ファイルです。
シェルスクリプトを実行した後、一度このファイルの中身の書き換えを行いますので、PVE上からアクセスできる場所に読み書き可能な権限で格納してください。
シェルスクリプトとセットで使うことになるのでこちらも２つ分作成しています。
・alma_user.yaml
・ubuntu_user.yaml
Ubuntu版は気まぐれで作りましたが、たぶん私は使いません。
え？なんで作ったのか？ それは自分でもわかりません…
大幅にYAMLの書き換えが必要でしたが、動作検証はしているので使えると思います。
３．Bashスクリプトの詳細説明
まずはBashスクリプトの説明です。
#!/bin/bash#変数
##VMID取得
###START_NUM変数<=VMID<END_NUM変数となる最大のVM_IDを求めて、それに1を足したVM_IDでデプロイするための処理
START_NUM=200
END_NUM=300
VM_ID=`qm list | awk ‘($1 >= ‘$START_NUM’ && $1 < ‘$END_NUM’ ) {print}’ | awk ‘{if(m<$1) m=$1} END{print m}’`
if [ -z “${VM_ID}” ];then
VM_ID=${START_NUM}
else
VM_ID=`expr ${VM_ID} + 1`
fi
PVE上に存在するVMIDのn+1で自動的にデプロイするようになっています。
フォーマットではVMIDが200～299までで一番高いVMIDのn+1でデプロイし、200番台が一台もなければ200番でデプロイします。
この辺りは変数で変更可能なので、自由にチューニングしてください。
##そのほかの変数
VM_NAME=”alma-VM${VM_ID}”
VM_DISKIMAGE=”/mnt/pve/FileServer/template/iso/AlmaLinux-9-GenericCloud-9.3-20231113.x86_64.qcow2″
VM_CPUTYPE=x86-64-v2-AES
VM_CORES=2
VM_MEM=4096
VM_IPCONF=”ip=172.16.1.${VM_ID}/24,gw=172.16.1.254″
VM_DISKSIZE=50G
VM_POOL=InsideServer
VM_YAMLFILE=”FileServer:snippets/alma_user.yaml”
VM_YAMLPATH=”/mnt/pve/FileServer/snippets/alma_user.yaml”
VM_EXPIREDATE=`date ‘+%Y-%m-%d’ -d ‘7 days’`
その他の変数を定義しています。
こちらで設定した変数が後々VMのパラメータになるので、こちらも自由にチューニングしてください。
VM_NAME：PVE上の仮想マシン名です、ホスト名とは別です。フォーマットはVMIDを入れた汎用な名前にしていますが、固定にする場合は変更してください。
VM_DISKIMAGE：イメージファイルです。isoは試せていませんが少なくともimgとqcow2はデプロイできています。（isoはformatタイプの変更がいる？）
VM_MEM：多分1024の倍数の方が良いかと思います。単位はMBです。
VM_TYPE：すみません、よくわかりません。デフォルトにしています。ちなみにCMLをデプロイした際はデフォルトではNGでhostで動きました。
VM_CORE：CPUのコア数です。ESXiのvCPUとほぼ同義です。
VM_IPCONF：VMのインターフェースに割り当てるIPとゲートウェイIPです。フォーマットでは172.16.1.xでVMIDと同じ数字が入ります。お気づきかと思いますが、VMIDは200～299で採番していますが、IPの制約によりGW含めずに254までしか使用できません。自由にチューニングしてください。
VM_DISKSIZE：「/」のディスクサイズです。以下を参考にしてください。
[root@alma-VM203 user203]#df -lh
Filesystem Size Used Avail Use% Mounted on
devtmpfs 4.0M 0 4.0M 0% /dev
tmpfs 1.8G 0 1.8G 0% /dev/shm
tmpfs 729M 8.6M 720M 2% /run
/dev/sda4 50G 1.8G 48G 4% /
/dev/sda3 448M 202M 247M 46% /boot
/dev/sda2 200M 7.1M 193M 4% /boot/efi
tmpfs 365M 0 365M 0% /run/user/1000
VM_POOL：PVE上のプール名です。私はプール名にInsideServerとDMZServerを作成し、タグはAlmalinux9.3などとつけています。仮想マシンの検索の際にタグをつけていると検索に引っ掛かり、同じOSでまとめることができます。
VM_YAMLFILE：PVEから見た論理的なパスです。Windowsでいうドライブ割り当てパスに近いイメージでしょうか。絶対パスではうまく設定できない項目があるので使用しています。
VM_YAMLPATH：PVEから見た絶対パスです。
私はYAMLはPVE内のVMであるファイルサーバに保存しているだけなので、いずれの値も自由にチューニングしてください。例えば、PVEにデフォルトで存在する「local」のスニペットに保存するのであれば、以下のようになるかと思います。
VM_YAMLFILE=”local:snippets/alma_user.yaml”
VM_YAMLPATH=”/mnt/pve/local/snippets/alma_user.yaml”
VM_EXPIREDATE：Cloud-initで作成するユーザの有効期限を一週間に設定しています。フォーマットの場合、VMIDから推測できる簡易なものになっているため、初回ログインユーザという扱いです。
#yamlファイルの書き換え
yq -iy ‘.fqdn = “alma-VM’$VM_ID’.home.miyamo83.com“‘ ${VM_YAMLPATH}
yq -iy ‘.users[0].name = “user’$VM_ID’“‘ ${VM_YAMLPATH}
yq -iy ‘.users[0].plain_text_passwd = “pass’$VM_ID’“‘ ${VM_YAMLPATH}
yq -iy ‘.users[0].expiredate = “‘$VM_EXPIREDATE'”‘ ${VM_YAMLPATH}
sed -i ‘1s/^/#cloud-config\n/’ ${VM_YAMLPATH}
Cloud-initの構成定義ファイルであるYAMLの書き換えです。
赤字の部分は書き換えてください。パスワードはランダム生成して設定後、自分充てにメールで送るとかにするとセキュリティ的に良くなる気がしますね。
フォーマットのIDとパスワードでデプロイするのなら、初回ログイン後に手動で別のユーザを作成してください。
VMIDをPVE上の仮想マシン名だけでなくホスト名にも反映させる上で、YAMLファイルへの更新をどのように行うかが鬼門でした。環境変数で指定できればよかったのですが…
今回はyq -iyコマンドによるオブジェクトの置き換えを行っています。
これには１つ困ったことがあります。
YAMLファイルに記載されたフォーマット自体が崩されてしまうことです。具体的には以下
・「#」から始まるコメント行の削除
・改行の削除
・「”」や「’」が削除されたりされなかったりよくわからない挙動
Cloud-initの構成ファイルとして宣言している「#cloud-config」がないとそもそも処理されないので、yqコマンドの後にsedコマンドでファイルの先頭行に挿入し直しています。
#VMのパラメータ設定
qm create ${VM_ID} \
–name ${VM_NAME} \
–bios ovmf \
–efidisk0 local-lvm:1,efitype=4m,pre-enrolled-keys=1 \
–cpu ${VM_CPUTYPE} \
–sockets 1 \
–cores ${VM_CORES} \
–memory ${VM_MEM} \
–scsihw virtio-scsi-pci virtio-scsi-single \
–boot order=scsi0 \
–agent enabled=1 \
–scsi0 local-lvm:0,import-from=${VM_DISKIMAGE},format=qcow2 raw \
–sata0 local-lvm:cloudinit \
–net0 vmxnet3 virtio,bridge=vmbr1,tag=10 \
–pool ${VM_POOL} \
–ipconfig0 ${VM_IPCONF} \
–cicustom user=${VM_YAMLFILE}
#scsi0の拡張
qm resize ${VM_ID} scsi0 ${VM_DISKSIZE}
#VM起動
qm start ${VM_ID}
最後にVMのパラメータ設定とデプロイです。
追記（2024/9/5）
最適化されていなかったので、修正しました。
virtio-scsi-singleの方がvirtio-scsi-pciよりもパフォーマンスが良いようです。
参考：https://172.16.0.1:8006/pve-docs/chapter-qm.html#qm_system_settings:~:text=A%20SCSI%20controller%20of%20type%20VirtIO%20SCSI%20single%20and%20enabling%20the%20IO%20Thread%20setting%20for%20the%20attached%20disks%20is%20recommended%20if%20you%20aim%20for%20performance.
LVM-Thinストレージではqcow2イメージでの保存はできなく、rawファイルでの指定のみのようです。
参考：https://172.16.0.1:8006/pve-docs/chapter-pvesm.html#:~:text=Table%2010.%20Storage%20features%20for%20backend%20lvmthin
ESXiではvmxnetが最適だった認識ですが、KVMベースではVirtIOが最適のようです。
参考：https://172.16.0.1:8006/pve-docs/chapter-qm.html#qm_network_device:~:text=the%20VirtIO%20paravirtualized%20NIC%20should%20be%20used%20if%20you%20aim%20for%20maximum%20performance.
この辺りを変更する際は公式ドキュメントを見てもらうのが良いと思います。
今回のフォーマットはisoイメージから手動で構築した際の値を参考にしています。
ちなみにDNSサーバは何も指定しないとホストと同じ宛先を参照しますが、変更したい場合は「–nameserver <string>」で変更できるようです。
注意点としてCloud-initでの初期設定はYAMLファイルを参照させずに直接指定させることもできますが、一度「–cicustom user」でYAMLファイルを参照させると直接設定した値が無視されるようです。
また、最初からVM_DISKSIZE変数で指定した値でscsi0を設定せずに後からディスクサイズをリサイズしているのは理由があり、イメージファイルをインポートする際にサイズを指定するとエラーになるからです。
４．YAMLファイルの詳細説明
次にYAMLファイルについてです。
#cloud-config
fqdn: alma-VM200.home.miyamo83.com
manage_etc_hosts: true
locale: ja_JP.UTF-8
timezone: Asia/Tokyo
users:
– name: user200
sudo: ALL=(ALL) ALL
lock_passwd: false
plain_text_passwd: pass200
expiredate: ‘xxxx-xx-xx’
ssh_pwauth: false
ssh_authorized_keys:
– ssh-ed25519 yoursshkey
先ほども記載したようにCloud-initの構成定義ファイルとして認識させるには「#cloud-config」が必須になっています。
「fqdn」,「name」,「plain_text_passwd」,「expiredate」はBashスクリプトから書き換えられます。
「manage_etc_hosts」はCloud-initによって「/etc/hosts」が書き換えられないようにするためにtrueにしています。どんな値になるか確認できていませんが、起動するたびに書き換えられてしまうようです。
「users」セクションでユーザの定義を行わずに「user: hoge」と「password: fuga」のように設定することもできます。その場合、Cloud-initのデフォルトユーザという扱いで、sudoコマンドを実行した際にパスワード入力が不要になります。それを避けるために今回は「users」セクションを利用していますが、公式ドキュメントをしっかり見れていないだけでデフォルトユーザにもsudoの設定をいじるモジュールがあるかもしれません。
ちなみにデフォルトユーザと「users」セクションを同居させるには必ず「users」セクションに「- default」という記載が必要です。
「users」セクションを使う際の注意点として、「lock_passwd」をfalseにする必要があります。指定しなければtrueとなり、そのユーザでログインできません。
今回は平文パスワードなので、「plane_text_passwd」を使いましたが「passwd」でハッシュ値で指定することもできます。
「expiredate」はそのユーザの有効期限です。
今回はSSH時のパスワードログインを無効化し、公開鍵認証を行っていますので、鍵ペアを作成し、公開鍵を「ssh_authrized」に入力してください。公開鍵の使いまわしはよくないと考える方は毎回鍵ペアを生成してから入力するようにしてもいいかもしれませんが、秘密鍵をクライアントに送るのが手間そうですね…
個人的には公開鍵って名前なんだし使いまわしてよくない？派で、もし秘密鍵が漏れてもパスフレーズを厳重に設定していれば破られる可能性は低いと思います。
「ssh_import_id」でgithubやlaunchpadから公開鍵を複製して持ってくることもできるみたいです。
bootcmd:
– grubby –update-kernel ALL –args selinux=0
起動時に毎回行われるコマンドを記載するセクションです。
grubbyコマンドでSELinuxを無効化しています。
完全にオーバーキルですね…。SELinuxに親でもころされたのでしょうか。
今回ベースにさせていただいたサイト様では毎回行なっていますが、毎回行う必要はないと思います。ただ、面白いので採用しました。面白くねーよ！という方や親SELinux派の方はruncmdにでもぶち込んでください。
package_upgrade: true
packages:
– cyrus-sasl
– cyrus-sasl-plain
– tree
– langpacks-ja
– glibc-langpack-ja
– wget
– bind-utils
– vim-enhanced
– bash-completion
– epel-release
– s-nail
– postfix
– firewalld
パッケージの更新とインストールを行うセクションです。
今回のイメージファイルがどうやらminimumインストールレベルで何も入っていないので、結構困りました。
cyrus-sasl：PostfixのSASL認証に使います。
cyrus-sasl-plain：同上
tree：便利だから入れました。とは言うもののあまり使ったことはありません。
langpack-ja：YAMLファイルのはじめの方でロケールの設定をしましたが、これがないと反映されません。
glibc-langpack-ja：同上
wget：「wgetすらないのかよ」って叫びながら入れました。
bind-utils：これがないとnslookupもdigできません。
vim-enhanced：なんだかviの挙動がおかしいと思ったので/etc/vimrcを見ようとしたら、そもそもありませんでした。
bash-completion：タブ補完ができないなんて初めて経験しました。今まで甘やかされて生きてきたんだと実感しました。
epel-release：後ほど出てくるclamavのインストールをepelリポジトリからインストールするので必要です。
s-nail：mailコマンドでメール送信するので必要です。昔はmalixパッケージだったのがパッケージ名が変わったようです。
postfix：bind-utilsすらないのにpostfixがあるわけ…
firewalld：最低限のセキュリティ対策はしましょうというはなし
write_files:
– content: “set encoding=utf-8\nset fileencodings=iso-2022-jp,euc-jp,sjis,utf-8\
\ \nset fileformats=unix,dos,mac \n set backspace=indent,eol,start\n”
path: /etc/vimrc
– content: “#!/bin/bash\n# 設定ファイル\nCONFIG=/etc/clamd.d/scan.conf\n# スキャン実行\n# ※ウイルス検知時は隔離 ディレクトリへ隔離\n\
CLAMSCANLOG=`mktemp`\nQUARANTINEDIR=/tmp/clamdscan-quarantinedir-$(date +%Y%m%d)\n\
mkdir -p ${QUARANTINEDIR}\nclamdscan -c ${CONFIG} –move=${QUARANTINEDIR} /\
\ > ${CLAMSCANLOG} 2>&1\n# ウイルス検知時のみメール通知\nif [ -z \”$(grep FOUND$
${CLAMSCANLOG})\”\
\ ]; then\n rm -rf ${QUARANTINEDIR}\nelse\n grep -A 1 FOUND$ ${CLAMSCANLOG}\
\ | mail -s \”Virus Found in `hostname` => ${QUARANTINEDIR}\” yourmail@gmail.com\n\
fi\n# スキャンログをシスログに出力\ncat ${CLAMSCANLOG} | logger -t $(basename {$0} ‘$0’)\nrm -f\
\ ${CLAMSCANLOG}\n”
path: /etc/cron.daily/clamdscan
– content: yourmail@gmail.com [smtp.gmail.com]:587
path: /etc/postfix/sender_relayhost.hash
– content: “yourmail@gmail.com yourmail@gmail.com:your gmail app pass\n # default\n\
[smtp.gmail.com]:587 yourmail@gmail.com:your gmail app pass\n”
path: /etc/postfix/sasl_auth.hash
ファイルを新規作成したり追記したりするセクションです。
追記（2024/9/5）
動かなくなっていたので、basenameの引数部分を修正しました。
yqコマンドでフォーマットが崩れて一番困ったのがこの部分です。
yqコマンドのご機嫌を取りながらCloud-initから思った通りのファイルを作成してもらわなければなりません。具体的には改行を「\n」で記載するなどです。この部分ほんとにシビアなので、思った通りファイルへの記載がされていなければチューニングしてください。
では各ファイルの説明です。
「/etc/vimrc」：vim-enhancedを入れても日本語が文字化けしたり、バックスペースが使えなかったりするので、追記しました。即時反映です。
「/etc/cron.daily/clamdscan」：clamavのウイルススキャンを定期実行するためのスクリプトです。参考サイト様からほぼ丸パクリさせていただきました。ウイルススキャン後のメール通報先としてGmailのアドレスを記載するところがあるので、赤字の部分は必ず書き換えてください。
「/etc/postfix/sender_relayhost.hash」：postfixを使ったGmailアドレスへのメール送信方法が記載されたサイト様の丸パクリです。赤字の部分は必ず書き換えてください。
「/etc/postfix/sasl_auth.hash」：こちらもpostfixを使ったGmailアドレスへのメール送信方法が記載されたサイト様の丸パクリです。昔はサブミッションポートへのメール中継にGmailのサーバを使用する際はGmailのログインパスワードでよかったみたいですが、今はセキュリティの観点から２要素認証を有効にした上で発行できるアプリパスワードというものを使う必要があります。アプリパスワードは「xxxx xxxx xxxx xxxx」のように4文字区切りごとに4セクションで構成されていますので、空白を入れたまま記載する必要があります。赤字の部分は必ず書き換えてください。
runcmd:
– dnf install -y clamav clamav-server-systemd clamav-update clamav-scanner-systemd
– sed -i ‘s@#NotifyClamd /path/to/clamd.conf@NotifyClamd /etc/clamd.d/scan.conf@’
/etc/freshclam.conf
– freshclam
– sed -i ‘s/User clamscan/#User clamscan/’ /etc/clamd.d/scan.conf
– sed -i ‘s@#LocalSocket /run/clamd.scan/clamd.sock@LocalSocket /run/clamd.scan/clamd.sock@’
/etc/clamd.d/scan.conf
– echo ExcludePath ^/sys/ >> /etc/clamd.d/scan.conf
– echo ExcludePath ^/tmp/clamdscan-quarantinedir-.*/ >> /etc/clamd.d/scan.conf
– echo ExcludePath ^/proc/ >> /etc/clamd.d/scan.conf
– sed -i ‘s/TimeoutStartSec=420/TimeoutStartSec=600/’ /lib/systemd/system/clamd@.service
– systemctl daemon-reload
– systemctl enable clamd@scan –now
– systemctl enable clamav-freshclam –now
– chmod +x /etc/cron.daily/clamdscan
– systemctl enable postfix –now
– echo -e “#cloud-init追記\nappend_dot_mydomain = no\nrelayhost = [smtp.gmail.com]:587\nmynetworks
= 127.0.0.0/8\nrecipient_delimiter = +\nsmtp_sender_dependent_authentication =
yes\nsender_dependent_relayhost_maps = hash:/etc/postfix/sender_relayhost.hash\nsmtp_sasl_auth_enable
= yes\nsmtp_sasl_password_maps = hash:/etc/postfix/sasl_auth.hash\nsmtp_sasl_security_options
= noanonymous” >> /etc/postfix/main.cf
– postmap /etc/postfix/sasl_auth.hash
– postmap /etc/postfix/sender_relayhost.hash
– chmod u=rw,g=,o= /etc/postfix/sasl_auth.hash
– chmod u=rw,g=,o= /etc/postfix/sasl_auth.hash.db
– postfix reload
– systemctl enable firewalld –now
– firewall-cmd –add-service=smtp –permanent
– firewall-cmd –reload
power_state:
mode: reboot
最後に初回起動時にのみ実行されるコマンドを記載するセクションです。
最初はClamavの設定です。ほとんど参考サイト様の手順準拠なので、詳しい説明はそちらを見てもらえればと思います。
参考サイト様：https://centossrv.com/almalinux/clamav.shtml
ただ一点だけ補足するとClamavのウイルスデータベースを更新する「freshclam」はCDNへアクセスするのですが、アクセス回数が多すぎると拒否されてしまいます。
おそらく送信元のグローバルIPで回数をカウントしているのでしょうが、10台以上のPCで「clamav-freshclam」を動かしている場合は自前のミラーサーバを置くように推奨されているみたいです。
ちなみに制限に引っ掛かり、拒否されるとこんな感じで出ます。24時間ほど更新できなくなるみたいですね。（確認する前の時点ですでに制限されていました。制限されたのではおそらく2024-02-17 23:11:31だと思います。）
[root@alma-VM203 user203]# freshclam
ClamAV update process started at Sun Feb 18 14:13:41 2024
WARNING: FreshClam previously received error code 429 or 403 from the ClamAV Content Delivery Network (CDN).
This means that you have been rate limited or blocked by the CDN.
1. Verify that you’re running a supported ClamAV version.
See https://docs.clamav.net/faq/faq-eol.html for details.
2. Run FreshClam no more than once an hour to check for updates.
FreshClam should check DNS first to see if an update is needed.
3. If you have more than 10 hosts on your network attempting to download,
it is recommended that you set up a private mirror on your network using
cvdupdate (https://pypi.org/project/cvdupdate/) to save bandwidth on the
CDN and your own network.
4. Please do not open a ticket asking for an exemption from the rate limit,
it will not be granted.
WARNING: You are still on cool-down until after: 2024-02-18 23:11:31
自前サーバの構築に関して、今回は省きますが詳しい参考サイト様を紹介します。
参考サイト様：https://www.fumibu.com/use_clam-anti-virus_debian-package/#toc9
次に、中断あたりからPostfixの設定です。こちらも同上です。
参考サイト様：https://qiita.com/hydratlas/items/a2e5aaba0858731ccc17
気づかれた方もいるかと思いますが、main.cfの追記をwrite_filesセクションで行わずruncmdセクションで行っているのには理由があります。
Cloud-initの処理の順番はYAMLファイルの記載順で決まるのではなくあらかじめ決められており、write_filesセクションよりもpackagesセクションで記載されたパッケージのインストールの方が遅いからです。
write_filesで記載してしまうと、パッケージインストール時の初期コンフィグを反映できないため、あえてパッケージインストール後に行われるrumcmdセクションで追記しています。
packagesの順番は記載がないですが、それ以外の順序に関しての参考サイトは以下です。
参考サイト様：https://github.com/ukayani/cloud-init-example/blob/master/README.md
main.cfの追記部分もシビアなので、思った通りファイルへの記載がされていなければチューニングしてください。
そして、最後はSELinuxの反映に必要な再起動を行う記載で終了です。
チューニングすることなく無事動いてくれることを祈っておきます…
あと、いくつか検証用のコマンドを記載しておきます。
メール送信テストのコマンド
# echo "test from `hostname`" | mail -s "test mail" yourmail@gmail.com
無害なテスト用ウイルスファイルのダウンロードコマンド
# wget https://secure.eicar.org/eicar.com
ウイルススキャンスクリプトの手動実行
# . /etc/cron.daily/clamdscan
説明は以上で終わりになりますが、もしyqコマンドを使用する以外でVMIDをYAMLファイルに渡す方法があれば、ぜひぜひ教えてください！
追記（2024/9/5）
Ansibleを勉強し始めたところですが、YAMLに変数性を持たせるためにJinja2を使っているので、もしかすると自分のやりたかったことはこれで実現できるのでは？と思い始めています。
もう少し勉強して追記しようと思います。
５．後書き
余談ですが、無償版であるESXi Hypervisorが廃止されることになったなので、PVEに乗り換える人は多いと思います。
これめっちゃ良くないですか？
まだ使って半月ほどですが、ESXiより断然使いやすいですし、できることも多い気がします。
最初はPVEのタグVLAN構成で戸惑いましたが、
ESXi：VM-ポートグループ(ここにVLAN設定)-vSwitch-ホストの物理ポート-対向のSWのトランクポート
PVE：VM(ここにVLAN設定)-Linux Bridge(VLAN Aware有効)-ホストの物理ポート-対向のSWのトランクポート
こんな構成なのかなと大雑把に理解しています。
一つ文句があるとするならホストの物理ポートの判別が煩わしいくらいでしょうか。
自分の場合、帯域速度が書かれてさえいればすぐわかるのに、GUI上ではインターフェース名しか出ません。
仕方ないのでSSHログインして、以下のコマンドで判別した後、コメント欄に書き込んで対応しています。
# ethtool <インターフェース名>
とはいえ、正直かなり使いやすい仮想基盤なので移行して満足してます。
６．参考サイト
コメント