追記: 2026年6月13日の最新情報
2026年6月11日のVMware Cloud Foundation Blogで、SDDC Manager UIの自動化から一歩進み、VCF APIsを使うInfrastructure as Codeの考え方が紹介されました。cloud-initはゲストOSの初回構成を渡す層なので、VMを作る前後の組織、プロジェクト、リソース制限、ネットワーク、ライフサイクル処理とは役割を分けて考える必要があります。
- cloud-init/GuestInfoは、OS初回起動時にmeta-data、user-data、vendor-dataを渡すための仕組みです。cloud-initのVMware datasource docsでは、
guestinfo.*.encodingにbase64またはgzip+base64を使えると説明されています。 - VCF 9.1側では、SDKs、APIs、CLI、PowerCLIでprivate cloudを構築、運用、管理する導線がTechDocsにまとまっています。VMデプロイの再現性は、GuestInfoだけでなく、API権限、組織/プロジェクト、リソース上限までセットで確認します。
- TerraformやPowerCLIを使う場合も、user-dataに秘密情報を直書きせず、テンプレート、APIトークン、監査ログ、再実行時の差分管理を分ける設計が必要です。
この記事のcloud-init手順は、IaC全体のうち「ゲスト初期化」の部品として位置づけると判断しやすくなります。
一次情報: Modern Automation with VMware Cloud Foundation Part 2、Administration SDKs, APIs, and CLI、cloud-init VMware datasource docs
このテーマをもう少し広げて見るなら、VCF 9.1でIaCを始める前に確認する：SDDC Manager API、Terraform、組織/プロジェクトの実務ポイント と VCF 9.1のAPI-first自動化を導入前に確認する：Real-Time Metrics、vCenter Utilization、SDK/PowerCLIの実務ポイント も合わせて確認してください。cloud-initをVM初期化の部品として扱い、VCF APIやTerraformで全体の再現性を確認できるため。
3行まとめ
- 1OVF/テンプレート
cloud-initとopen-vm-toolsを含むベースイメージを用意します。
- 2vSphere UIまたはPowerCLI
meta-dataとuser-dataをVMの設定として渡す準備をします。
- 3GuestInfo extraConfig
guestinfo.metadata、guestinfo.userdataと各encodingキーを設定します。
- 4open-vm-tools
ゲストOS内でGuestInfoの値を読み取れる状態にします。
- 5cloud-init初回起動
ホスト名、ネットワーク、SSH、パッケージなどの初期構成を反映します。
見るべき点は作成速度だけでなく、VMの初期状態をテキストで表し、同じ流れで再現できるかです。
BroadcomはVMware Cloud Foundation Blogで、2026年6月8日にcloud-initを使ったVMデプロイ標準化の記事を公開しました。読むべき中心は、VCF/vSphere上でLinux VMを初回起動時にどう安全かつ再現可能に構成するかです。
導入前の確認点は、GuestInfoでmeta-dataとuser-dataを渡せるベースイメージ、base64の意味、OVF/Content LibraryとPowerCLIの順序、機密情報の扱い、ISOインストールとの違いです。
この記事は2026年6月9日 JST時点の公式情報に基づく非提携の確認メモです。BroadcomおよびVMware by Broadcomとは関係なく、投資助言ではありません。
VCF Blogのcloud-init記事をどう読むか
VMware Cloud Foundation Blogがcloud-initを使ったVMデプロイ標準化を扱っています。
meta-data.yamlとuser-data.yamlをGuestInfo設定として渡し、初回起動時に読み取る流れです。
作成後スクリプト、用途別テンプレート、初回起動のcloud-initのどれに寄せるかを考えます。
ネットワーク、秘密情報、ログ、失敗時の切り分けまで含めて判断します。
需要シグナルは公式ブログのテーマから読み取り、導入判断は自社のベースイメージと運用手順で確認します。
VMware Cloud Foundation Blogの2026年6月8日記事は、cloud-initを「VMを速く作る小技」としてではなく、VCF/vSphere環境でVMの初期状態を宣言的にそろえる方法として扱っています。ここが今回の需要シグナルです。
直近のBroadcom Watch Japanでは、KubeCon India 2026、VKS、VCF 9.1移行、ライセンス、VCF Operationsなどを扱ってきました。今回の焦点はそこから少し下がり、実際にゲストOSを展開する現場の話です。VMを作った後にスクリプトを流すのか、用途別の重いテンプレートを増やすのか、それとも初回起動のcloud-initで構成を流し込むのか。読者が判断すべき問いはここにあります。
公式ブログで確認できること
公式ブログは、vSphere上のVMへcloud-init構成を注入する方法として、VMware GuestInfo datasourceを使う流れを説明しています。meta-data.yamlとuser-data.yamlを用意し、それらをVMのGuestInfo設定として渡し、ゲスト内のopen-vm-toolsとcloud-initが初回起動時に読み取るという流れです。
サンプルでは、ホスト名、静的IP、DNS、NTP、SSH、開発ツール、パッケージ、Gitリポジトリ取得などが扱われています。ただし、これは考え方を示す例です。日本の導入担当者が本番へ持ち込むなら、サンプルをコピーする前に、自社のネットワーク、秘密情報、監査ログ、テンプレート管理、権限分離へ落とし込む必要があります。
読み替えるポイント
サンプルの価値は、個々のパッケージ名やIPアドレスではなく、VMの初期状態をYAMLで表し、起動前にGuestInfoへ渡す流れにあります。自社版を作るときは、まず小さなmeta-dataとuser-dataで成功条件を固めるのが近道です。
ニュースではなく採用判断として読む
この記事を「cloud-initが便利らしい」で終わらせると、導入判断には足りません。見るべき点は、次の四つです。
- 既存のLinuxイメージがcloud-initとopen-vm-toolsを含んでいるか。
- VM起動前にGuestInfoキーを安全に入れられるか。
- 初回起動だけで完了させる処理と、継続的な構成管理へ任せる処理を分けられるか。
- 失敗したときに、YAML、イメージ、vSphere設定、ネットワーク、認証情報のどこが原因か切り分けられるか。
VCF全体のAPI-firstな方向性を追うなら、既存記事の<a href="https://avgo-watch.blog.mo-gmo.com/avgo-19-vcf-91-api-first-automation-check/">VCF 9.1のAPI-first自動化チェック</a>も合わせて見ると、基盤側の自動化とゲスト初期化の役割を分けやすくなります。
cloud-init VMware datasourceの前提を確認する
GuestInfoの値を入れるだけでは不十分で、ゲスト側に読む主体があることが前提です。
cloud-initの公式ドキュメントでは、VMware datasourceがGuestInfo keysを使ってmeta-data、user-data、vendor-dataを受け取れることが説明されています。VCF/vSphere側で見ると、これはVMのextraConfigにGuestInfoキーを置く形です。
最小構成としてまず確認するのは、次の4キーです。
| キー | 役割 | 導入前の確認 |
|---|---|---|
guestinfo.metadata | VMの識別、ホスト名、ネットワークなど | YAMLまたはJSONとして読める形か |
guestinfo.metadata.encoding | metadataのエンコード指定 | まずはbase64を想定する |
guestinfo.userdata | #cloud-configから始まる初期構成 | ユーザー、SSH、パッケージ、ファイル作成などを分ける |
guestinfo.userdata.encoding | userdataのエンコード指定 | base64または必要に応じてgzip+base64 |
vendordataも使えますが、最初のPoCでは無理に広げない方がよいです。まずはmetadataとuserdataの2本で、何をどちらに置くかをチームで説明できる状態にします。
ゲスト側に必要なもの
GuestInfo方式は、vSphere側でキーを入れれば必ず動くというものではありません。ゲストOSの中でcloud-initが動き、VMware Toolsまたはopen-vm-toolsがGuestInfoを読める状態であることが前提です。
まず見たいログ
PoC前には、ベースイメージごとに次を確認します。
cloud-initが入っている。open-vm-toolsまたはVMware Toolsが入っていて起動する。- cloud-initがVMware datasourceを認識できる。
- 初回起動のログを
/var/log/cloud-init.logと/var/log/cloud-init-output.logで確認できる。 - テンプレート化や複製時に、
instance-idやmachine-idの扱いを説明できる。
ここを飛ばすと、YAMLが正しいのに反映されない、逆にdatasource設定が違うのにYAMLだけを直し続ける、という遠回りが起きます。
初回起動と再実行を分ける
cloud-initは名前どおり、初期化時の仕組みです。再起動するたびに同じ処理が何度でも走る前提で設計すると、期待と違う動きになります。
1台目のPoCでは、まず初回起動で成功することを見ます。2台目以降では、instance-id、ホスト名、IPアドレス、SSHキー、CI/CD変数が重複しないかを見ます。失敗時には、VMを作り直すのか、cloud-initをcleanして再実行するのか、あるいはテンプレート側を直すのかを決めておく必要があります。
GuestInfoで渡すデータとbase64の扱い
meta-dataはVMの前提情報、user-dataはゲスト内の初期構成として分けて考えると運用しやすくなります。
cloud-initのVMware datasourceでは、GuestInfoキーへ入れる値にbase64またはgzip+base64を指定できます。ここで大事なのは、base64を暗号化と誤解しないことです。
base64は、改行やインデントを含むYAMLをVMの設定値として扱いやすくするためのエンコードです。秘密情報を読めない形に守るための仕組みではありません。復号できる人には読めます。
meta-dataとuser-dataを分ける
meta-dataには、VMの識別やネットワークに関わる情報を置きます。たとえばinstance-id、local-hostname、静的IP、ゲートウェイ、DNSなどです。
user-dataには、ゲスト内で実行したい初期構成を置きます。#cloud-configから始め、ユーザー、SSH設定、パッケージ導入、ファイル作成、runcmdなどを扱います。
分け方の目安はシンプルです。
| 項目 | 置き場所 | 理由 |
|---|---|---|
| ホスト名 | meta-data | VMの識別情報として扱う |
| 固定IPやDNS | meta-data | ネットワーク初期化に関わる |
| Linuxユーザー | user-data | OS内の構成だから |
| パッケージ導入 | user-data | 初回起動後の処理だから |
| SSH公開鍵 | user-data | ログイン制御の初期構成だから |
| APIトークン | 原則は別管理 | GuestInfoやログに残るリスクがある |
YAML例を長く貼るより、まずこの責務分担を固定した方が安全です。長いuser-dataは読みにくく、失敗時の切り分けも難しくなります。
base64は暗号化ではない
vSphere UIやPowerCLIでGuestInfoキーへ複数行YAMLを入れる場合、改行、インデント、コロン、引用符の扱いが壊れることがあります。base64はその破損を避けるために使います。
復号確認を手順に入れる
確認の流れは次のようにしておくと安心です。
1. meta-data.yaml と user-data.yaml を作る
2. UTF-8で保存する
3. base64文字列へ変換する
4. 変換後の文字列を復号し、元のYAMLと一致するか確認する
5. VM起動前にGuestInfo 4キーを入れる
6. 初回起動後にcloud-initログで適用結果を見るPowerShellで扱う場合は、BOMや改行の扱いにも注意します。公式ブログは、PowerCLIでGet-Content -Raw -Encoding UTF8を使って内容を読み、base64化する考え方を示しています。CI/CDに載せるなら、base64文字列そのものをジョブログへ出さない設計も必要です。
gzip+base64を使う前に決めること
user-dataが大きくなる場合、gzip+base64を検討できます。ただし、最初から圧縮すると中身の確認が面倒になります。PoC段階では、短いuser-dataをbase64で動かし、復号確認とログ確認の手順を固めてから圧縮を考える方がよいです。
user-dataが大きくなりすぎるなら、それ自体が設計のサインです。初回起動で入れるべき最低限の設定と、Ansible、Salt、Puppet、GitOps、社内の構成管理基盤へ任せる処理を分けましょう。
OVF/PowerCLI自動化で先に詰めること
- 1Content Library Item
OVF/OVAまたは同等のテンプレート管理を出発点にします。
- 2Get-OvfConfiguration
EULAやネットワークなど、展開時に必要なOVF構成を取得します。
- 3New-VM
Content Library ItemとOvfConfigurationを組み合わせてVMを作成します。
- 4New-AdvancedSetting
guestinfo.metadata、guestinfo.userdataと各encodingキーを設定します。
- 5Start-VM
GuestInfoキーを入れた後に起動し、初回起動でcloud-initに読ませます。
- 6ログ確認
cloud-init statusとログで、datasource検出とYAML処理を確認します。
運用標準にする前に、EULA、ネットワーク、GuestInfo、起動順序を手順として固定します。
公式ブログは、vSphere UIでの手順とPowerCLIでの自動化の両方を示しています。運用標準にするなら、最終的にはPowerCLIやCI/CDに寄せたくなりますが、最初の1台はUIで確認しても構いません。重要なのは、UIで見える4キーとPowerCLIで入れる4キーが同じ意味を持つことを理解することです。
PowerCLIの公式リファレンスでは、Get-OvfConfigurationがOVF、OVA、Content Library Itemからユーザー設定可能なOVF構成オブジェクトを取得するcmdletとして説明されています。New-VMには、Content Library ItemとOvfConfigurationを組み合わせてVMを作る例があります。New-AdvancedSettingは、指定したエンティティにadvanced settingを作るcmdletです。
OVF/Content Library Itemを前提にする
GuestInfo cloud-initは、ISOブート中のOSインストールではなく、cloud-initとopen-vm-toolsを含む起動可能なゲスト環境を前提にします。そのため、実務ではOVF/OVA、Content Library Item、または同等のテンプレート管理が出発点になります。
PowerCLI化する前に、次を決めます。
- どのContent Library ItemまたはOVF/OVAを標準にするか。
- EULA承認が必要か。
- OVF内のネットワーク名を、実際のポートグループへどう対応させるか。
- データストア、フォルダ、VMHostまたはClusterをどう選ぶか。
- VMを起動する前にGuestInfoキーを確実に入れる順序にできるか。
この順序が曖昧なままスクリプト化すると、VMは作れたがcloud-initが読めない、ネットワークが違う、EULAで止まる、という失敗が起きます。
New-AdvancedSettingで入れる4キー
PowerCLIでGuestInfoを入れる場合、考え方は単純です。VM作成後、起動前に次のようなadvanced settingを入れます。
起動前に入れる理由
guestinfo.userdata = <base64化したuser-data.yaml>
guestinfo.userdata.encoding = base64
guestinfo.metadata = <base64化したmeta-data.yaml>
guestinfo.metadata.encoding = base64New-AdvancedSettingで-Forceを使う場合は、同名設定を上書きする意図をチーム内で明確にしておきます。既存VMに再投入する運用と、新規VMに初回投入する運用は別物です。
PowerCLIを本格的にCI/CDへ載せるなら、認証も合わせて見直します。APIトークンやSSO連携の観点は、<a href="https://avgo-watch.blog.mo-gmo.com/avgo-16-vcf-powercli-91-oauth-token-check/">VCF PowerCLI 9.1のOAuth 2.0認証チェック</a>で整理しています。
UI手順と自動化手順を対応させる
PoCでは、手作業で1台、PowerCLIで2台目を作り、同じ結果になるかを見ます。合格条件は、VMが起動することだけではありません。
- 起動前にGuestInfo 4キーが入っている。
- cloud-initがVMware datasourceを読んでいる。
- ホスト名、IP、ユーザー、SSH、パッケージが意図どおり。
- 初回起動ログで成功と失敗を説明できる。
- 2台目で
instance-idやホスト名が重複しない。
この対応表を作っておくと、UI担当、PowerCLI担当、ゲストOS担当の会話がそろいます。
機密情報と運用後の消し方
秘密情報の扱いは勝敗ではなく、権限、ログ、バックアップ、監査記録へ残る範囲で判断します。
GuestInfo方式は、ネットワーク上のHTTPメタデータサーバーへ設定を取りに行く方式とは違います。公式ブログも、GuestInfoがネットワークを経由しない点をセキュリティ上の利点として説明しています。
ただし、GuestInfoは秘密情報の保管庫ではありません。VMの設定を見られる権限、PowerCLIの実行ログ、CI/CDのジョブログ、バックアップ、監査記録、手順書に値が残る可能性があります。
user-dataへ秘密情報を入れる前に考える
user-dataに置きたくなる情報には、次のようなものがあります。
| 情報 | 入れる前の確認 | 望ましい扱い |
|---|---|---|
| rootパスワード | 初回ログイン後も必要か | できればSSH鍵や一時認証へ寄せる |
| SSH秘密鍵 | VM内へ本当に置く必要があるか | デプロイ専用鍵、短寿命、権限限定にする |
| npmやMavenのトークン | ログに出ないか | Secrets基盤や短寿命トークンを検討する |
| Git認証情報 | 取得後に残す必要があるか | deploy keyや権限限定の認証へ寄せる |
| 社内証明書 | 配布経路と失効手順があるか | 証明書管理の標準に合わせる |
サンプルに秘密情報が見えると、社内テンプレートへそのまま広がりがちです。記事や手順書では必ずダミー値にし、本物の値はSecrets基盤やCI/CDの保護された変数で扱う方針を明記しておきます。
redactは軽減策であって万能ではない
cloud-initの公式ドキュメントには、GuestInfo transportでredactを使い、読み取り後にuserdataやvendordataをクリアする方法が説明されています。これは重要な機能です。
一方で、redactだけで秘密情報の管理が完了するわけではありません。公式資料では、既存キーを完全に削除するのではなく、値を空のYAML相当へ置き換える挙動が説明されています。さらに、cloud-initが読み取る前に誰が見られるか、CI/CDログに出ていないか、ゲスト内ログに秘密情報が出ていないかは別の確認です。
消えたとみなす前の確認
PoCの合格条件には、次を入れてください。
- GuestInfo投入直後に値がどう見えるか。
- cloud-init読み取り後に
redact対象がどう変わるか。 /var/log/cloud-init.logや/var/log/cloud-init-output.logへ秘密情報が出ないか。- PowerCLIやCI/CDのログへbase64文字列を出していないか。
- 失敗時に、秘密情報入りのVMスナップショットやスクリーンショットを残さない運用になっているか。
ISOインストールや厚いゴールデンイメージと切り分ける
方式ごとに前提が違うため、単純な優劣ではなく、起動可能なイメージを前提にできるかで判断します。
公式ブログは、同じGuestInfo方式をISOベースのOSインストールへそのまま使えるわけではないと説明しています。理由は明確です。ISOでOSをインストールしている段階では、まだゲストOS内でopen-vm-toolsやcloud-initが動いていません。GuestInfoを読む主体がいないため、同じ流れにはなりません。
ISOではなく起動可能なイメージが前提
GuestInfo cloud-initの出発点は、cloud-init対応のLinuxイメージです。Ubuntu、Rocky Linux、Debian、Photon OSなど、利用するディストリビューションごとに、VMware datasourceが有効に使えるかを確認します。
ISOインストール自動化が不要になる、という話ではありません。Kickstart、autoinstall、PXE、ISOカスタムイメージなどが向く場面はあります。今回の論点は、すでに起動可能なイメージをVCF/vSphere上で標準化して展開するとき、初回構成をGuestInfoとcloud-initへ寄せられるかです。
厚いゴールデンイメージを減らせる範囲
cloud-initを使うと、用途別に何種類もの厚いゴールデンイメージを持つ必要を減らせます。OS共通部分を薄いイメージとして保ち、ユーザー、パッケージ、アプリの初期設定をuser-dataへ寄せる設計が取りやすくなるからです。
ただし、すべてをcloud-initへ寄せるのも危険です。OSパッチ、ドライバ、セキュリティベースライン、EDR、監査エージェント、組織標準のCA証明書など、イメージ側で管理すべきものは残ります。
切り分けの目安は次のとおりです。
| 方式 | 向く用途 | 注意点 |
|---|---|---|
| GuestInfo + cloud-init | 初回起動時のVM個別設定 | 秘密情報、再実行、ログを確認する |
| ISO自動インストール | OS導入そのものの標準化 | GuestInfo方式とは前提が違う |
| 薄いゴールデンイメージ | OS共通部分の維持 | イメージ更新手順が必要 |
| 厚いゴールデンイメージ | 変更頻度が低い標準環境 | 用途別に増えすぎると管理が重い |
| post-boot script | 一時的な補完や移行 | 冪等性と失敗時の切り戻しが課題 |
post-boot scriptとの境界
post-boot scriptを完全に否定する必要はありません。ただし、VMがネットワークへ出てから複数の外部スクリプトを順番に取りに行く設計は、失敗点が増えます。初回起動で必ず必要なホスト名、ユーザー、SSH、最低限のパッケージ、ログ出力はcloud-initへ寄せ、継続的に収束させる設定は構成管理へ任せる。こう分けると、責任範囲が見えやすくなります。
VCF基盤そのものの移行順序をまだ整理していない場合は、先に<a href="https://avgo-watch.blog.mo-gmo.com/avgo-28-vcf-52x-to-91-upgrade-planner-check/">VCF 5.2.xから9.1への移行前チェック</a>へ戻るのも自然です。ゲスト展開の自動化だけを先行させると、Management Services、NSX経路、ライセンス、Operations側の前提とずれることがあります。
PoCで確認するチェックリスト
起動前にGuestInfo 4キーが入り、復号したYAMLが元の内容と一致するかを見ます。
cloud-init status、cloud-init.log、cloud-init-output.logで完了状態を確認します。
instance-id、IP、ホスト名、SSHキー、CI/CD変数が重複しないかを見ます。
datasource検出、YAMLパース、ネットワーク待ち、パッケージ取得、runcmd失敗を分けます。
秘密情報がログ、ジョブ履歴、手順書に残っていないかを確認します。
PoCの目的は起動確認だけでなく、再現性と失敗時の説明可能性を確認することです。
cloud-initのPoCは、1台のVMが起動しただけでは終わりません。標準化したいなら、同じ手順で複数台を作り、失敗時に原因を説明できるところまで見る必要があります。
1台目で見ること
1台目は、仕組みの確認です。
- 起動前にGuestInfo 4キーが入っている。
metadataとuserdataを復号すると、元のYAMLと一致する。cloud-init statusが完了する。- ホスト名、IP、DNS、ユーザー、SSH、パッケージが想定どおり。
/var/log/cloud-init.logと/var/log/cloud-init-output.logで処理の流れを説明できる。- コンソールへ手作業で入らず、ログだけで成功理由を追える。
ここで失敗した場合、まずdatasource検出を見ます。次にYAMLのパース、ネットワーク、パッケージ取得、runcmdの順に切り分けます。
2台目以降で見ること
2台目以降は、再現性の確認です。
量産前の合格ライン
instance-idが重複していない。- IP、ホスト名、DNS名が重複していない。
- SSH鍵やAPIトークンがVMごとに適切に扱われている。
- PowerCLIを繰り返してもvCenterセッションが残り続けない。
- 同じテンプレートから作ったVMで、cloud-initが期待通り初回起動として動く。
- CI/CDログに秘密情報やbase64文字列が出ない。
1台だけ成功した状態を標準化完了とすると、あとで量産時に崩れます。テンプレート、GuestInfo、PowerCLI、ゲストログをセットで確認しましょう。
失敗時に決めること
失敗時の手順もPoCに含めます。特に次の判断を決めておくと、本番導入後の混乱が減ります。
| 失敗の種類 | まず見る場所 | 直し方の候補 |
|---|---|---|
| datasourceを読まない | cloud-initログ、VMware Tools状態 | イメージ修正、datasource設定確認 |
| YAMLエラー | cloud-initログ、復号後YAML | インデント、BOM、#cloud-config確認 |
| ネットワークが上がらない | meta-data、ゲスト内NIC名 | ネットワーク設定、Port Group、NIC名修正 |
| パッケージ導入失敗 | cloud-init-output.log | リポジトリ、DNS、プロキシ、時刻同期確認 |
| 秘密情報が残る | GuestInfo、ログ、CI/CD | redact、ログ抑制、Secrets設計見直し |
本番運用では、失敗したVMを直して使い続けるのか、破棄して作り直すのかも決めておきます。初期化の標準化では、作り直せること自体が運用の強みになります。
導入判断のまとめ
cloud-initとopen-vm-tools入りのベースイメージを持てます。
テンプレート管理を出発点にして、展開手順をそろえられます。
EULA、ネットワーク、GuestInfo、起動順序をスクリプトで管理できます。
metadataとuserdataを分け、base64を暗号化と誤解せずに扱えます。
ログ、監査、秘密情報の残り方までPoCで確認できます。
作成速度よりも、再現性、ログでの切り分け、秘密情報の扱いを説明できるかが導入判断の軸です。
VCF/vSphere環境でcloud-initを使う価値は、VMを作る速度だけではありません。VMの初期状態をテキストで表し、同じ流れで再現でき、失敗時にログから切り分けられることです。
採用しやすいのは、次の条件がそろう環境です。
- cloud-initとopen-vm-tools入りの標準Linuxイメージを持てる。
- OVF/OVAまたはContent Library Itemを運用できる。
- PowerCLIでEULA、ネットワーク、GuestInfo、起動順序を管理できる。
- 秘密情報をGuestInfoへ入れすぎない設計にできる。
- 1台目の成功だけでなく、複数台の再現性を検証できる。
逆に、OSインストールそのものをISOから自動化したい場合、秘密情報を長くuser-dataへ置きたい場合、cloud-initログを読めないまま量産したい場合は、いったん止まった方がよいです。GuestInfo cloud-initは便利な初期化経路ですが、秘密情報管理や構成管理の代替ではありません。
Broadcomの2026年6月関連トピック全体を追う場合は、<a href="https://avgo-watch.blog.mo-gmo.com/monthly-topics-2026-06/">2026年6月の重要トピックまとめ</a>に戻ると、VCF 9.1、VKS、Operations、セキュリティ、AIインフラ関連の流れを並べて確認できます。
次に読むなら
参照した主な情報源
- VMware Cloud Foundation Blog, "Achieve Speed, Scale, and Reliability of Virtual Machine Deployments with cloud-init", 2026年6月8日確認: https://blogs.vmware.com/cloud-foundation/2026/06/08/achieve-speed-scale-and-reliability-of-virtual-machine-deployments-with-cloud-init/
- cloud-init 25.3 documentation, "VMware", 2026年6月9日確認: https://docs.cloud-init.io/en/25.3/reference/datasources/vmware.html
- Broadcom Developer, "New-AdvancedSetting Command | VMware PowerCLI Reference", 2026年6月9日確認: https://developer.broadcom.com/powercli/latest/vmware.vimautomation.core/commands/new-advancedsetting
- Broadcom Developer, "Get-OvfConfiguration Command | VMware PowerCLI Reference", 2026年6月9日確認: https://developer.broadcom.com/powercli/latest/vmware.vimautomation.core/commands/get-ovfconfiguration
- Broadcom Developer, "New-VM Command | VMware PowerCLI Reference", 2026年6月9日確認: https://developer.broadcom.com/powercli/latest/vmware.vimautomation.core/commands/new-vm