virtualization

Name: virtualization
Author: iuliandita

github.com/iulianditaクラウド・DevOps1066 回インストール今日更新

リポジトリ

virtualization について

複数のハイパーバイザーで仮想マシンを作成、設定、運用するためのスキルです。Proxmox、libvirt/KVM、XCP-ng、VMware を扱い、ストレージ、デバイスパススルー、クラスター、復旧を支援します。

主な機能

01仮想マシンの作成と設定
02Terraform と Packer によるプロビジョニング
03ストレージと性能の指針
04GPU と PCI のパススルー
05クラスター、移行、バックアップ

活用シーン

01Proxmox 仮想マシンのプロビジョニング
02cloud-init による VM テンプレート作成
03GPU パススルーの計画
04移行と復旧手順のテスト

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/iuliandita/skills --skill virtualization

インストール後、Claude Code で/virtualizationを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/

agent-hygiene.md

gotchas.md

image-building.md

libvirt-qemu-kvm.md

output-contract.md

proxmox.md

詳細

仮想化：ハイパーバイザー、VM、インフラストラクチャ

単一ノードの Proxmox 構成から、HA、ライブマイグレーション、GPU パススルーに対応したマルチノードクラスターまで、ハイパーバイザー全体で仮想マシンを作成、設定、管理します。目標は、ストレージ、メモリ、CPU を正しく設定し、午前3時に問題を引き起こさない、本番環境に対応した VM インフラストラクチャです。

対象バージョン（2026年10月）：

ツール	バージョン	リリース日	備考
Proxmox VE	9.2	2026年5月	現行の本番向け系列。9.1 からのアップグレードに関する注意事項を確認してください
Proxmox Backup Server	4.2	2026年4月	重複排除、増分バックアップ、プルーニングポリシー
bpg/proxmox (Terraform)	0.115.0	2026年10月	Proxmox 用の主要な IaC プロバイダー
QEMU	11.1.2	2026年9月	安定版 11.1 のメンテナンスリリース
libvirt	12.8.0	2026年10月	ハイパーバイザー抽象化レイヤー
XCP-ng	8.3 LTS	2024年10月	Xen ベース。2025年6月から LTS、EOL は2028年11月
VMware ESXi	8.0 U3k (25595708)	2026年7月	8.0 U3 系列でセキュリティ上最低限必要なバージョン（ビルド番号は2026年10月時点で未確認）。アプライアンス系列を確認してください
VirtualBox	7.2.20	2026年9月	現行の 7.2 メンテナンスリリース
Packer	1.16.1	2026年9月	複数プラットフォーム対応のイメージビルダー
cloud-init	26.2	2026年7月	インスタンス初期化の標準

セキュリティの再確認（2026-09-10）：VMSA-2026-0006 では、重大な CVE-2026-47876（ESX VMXNET3 VM エスケープ、CVSS 9.3）に対処しています。8.0 の修正済みビルドは ESXi80U3k-25595708 または ESXi80U2f-25626445 です（Broadcom のアドバイザリを取得できないため、ビルド番号は2026年10月時点で未確認）。該当するアップデート系列を選択してください。このアドバイザリでは、重大な vCenter CVE-2026-59309/CVE-2026-59310 についても扱っています。 vCenter は、対応する応答マトリックスに従って別途パッチを適用してください。ESX/vCenter 7.0 については、8.0 のパッチが適用できると想定せず、Broadcom の拡張サポートに関するガイダンスに従ってください。

使用する場面

Proxmox、libvirt/KVM、XCP-ng、または VMware 上で VM を作成、設定する
Terraform（bpg/proxmox プロバイダー）で Proxmox VM をプロビジョニングする
Packer と cloud-init で VM テンプレートを構築する
コンピューティング用またはディスプレイ用 GPU の PCI/GPU パススルーを設定する
ストレージバックエンド（LVM-thin、ZFS、Ceph、NFS）を管理する
Proxmox クラスター、HA、ライブマイグレーションを設定する
VM のパフォーマンス（ディスク I/O、メモリ、CPU）の問題をトラブルシューティングする
バックアップ戦略（Proxmox Backup Server、スナップショット）を計画する
ディスクパフォーマンス（virtio-scsi、iothread、discard/fstrim）を調整する
メモリ管理（バルーニング、NUMA トポロジー、hugepages）

使用しない場面

Kubernetes マニフェスト、Helm チャート、コンテナーオーケストレーション（kubernetes を使用）
一般的な Terraform/OpenTofu の HCL パターン、状態、モジュール（terraform を使用）
ハイパーバイザー固有ではないネットワーク設定：DNS、VPN、リバースプロキシ（networking を使用）
Ansible プレイブックと構成管理（ansible を使用）
Docker/コンテナーイメージの最適化（docker を使用）
OPNsense/pfSense ファイアウォールの管理（opnsense-pfsense を使用）
Synology DSM の管理（synology-dsm を使用）
NixOS の設定とイメージ生成（nixos を使用）

AI によるセルフチェック

AI ツールは、同じ VM 設定ミスを繰り返し生成します。生成した VM 設定、Terraform HCL、または Packer テンプレートを返す前に、次のリストに照らして確認してください。

ベストプラクティス

ゲストエージェント、ディスク、起動、パススルー、ハイパーバイザーをアップグレードする前にスナップショットを作成してください。ただし、スナップショットをバックアップとして扱わないでください。
ホスト、ゲスト、ストレージのバックアップは、それぞれ独立して復元できるようにしてください。
カーネルの更新でホストが利用不能にならないよう、PCI／GPU パススルーのバインド設定を文書化してください。

復元訓練

本番環境と IP アドレスや ID が重複しない隔離ネットワークに、代表的なゲストを復元してください。起動、アプリケーションデータ、依存サービス、暗号化キーの利用可能性を確認し、RTO／RPO に対する復旧時間とデータ損失を測定してください。選択したバックアップ、確認事項、クリーンアップを記録してください。バックアップジョブやスナップショットが成功しても、復元可能であることの証明にはなりません。

ワークフロー

既存の VM またはホストに変更を加える場合は、このチェックリストをコピーし、進捗を記録してください。

- [ ] Step 1: Task identified and matching reference read (plus `references/gotchas.md`)
- [ ] Step 2: Hypervisor, guest OS, storage, and backup state recorded
- [ ] Step 3: Change applied on a non-critical VM first
- [ ] Step 4: Validation passed (fix and return to Step 3 on any failure)

ステップ 1：タスクを特定する

タスク	まず確認するもの	参照先
Proxmox VM の作成	CLI（qm）または API（pvesh）、cloud-init	`references/proxmox.md`
Terraform によるプロビジョニング	bpg/proxmox プロバイダー、ライフサイクルルール	`references/proxmox.md`（Terraform セクション）
イメージのビルド	Packer + cloud-init テンプレート	`references/image-building.md`
libvirt/KVM の管理	virsh、XML ドメイン定義	`references/libvirt-qemu-kvm.md`（セクション 8：クイックスタート）
GPU/PCI パススルー	IOMMU グループ、vfio-pci	`references/proxmox.md`（セクション 7。Windows 11 + NVIDIA のクイックパスを含む）
パフォーマンスのチューニング	ディスク、メモリ、CPU の設定	このファイル + 参照資料
Proxmox への移行	VMware、XCP-ng、またはベアメタルから	`references/proxmox.md`

ステップ 2：要件を収集する

VM の作成または変更を行う前に、以下を確認します。

ハイパーバイザーとバージョン - Proxmox VE 9.x？ libvirt？ VMware からの移行？
ゲスト OS - Linux ディストリビューション、Windows、BSD？（virtio ドライバー、バルーニング、エージェントに影響します）
CPU - コア数、タイプ（host またはエミュレート）、ピン留めの要否、NUMA トポロジー
メモリ - 専用の割り当て量、バルーニング（通常は使用しません）、データベース向けの HugePages
ストレージ - バックエンド（LVM-thin、ZFS、Ceph、NFS）、ディスクサイズ、形式（raw または qcow2）
ネットワーク - ブリッジ、VLAN タグ、virtio、ファイアウォール
パススルー - GPU/PCI デバイス、USB、シリアルポート
プロビジョニング方法 - 手動、Terraform、Packer テンプレート + cloud-init
HA 要件 - クラスター化されているか？ライブマイグレーションは必要か？フェンシングは必要か？
バックアップ戦略 - PBS、スナップショット、vzdump、頻度

ステップ 3：構築する

ドメイン固有の参照ファイルに従います。主な原則は次のとおりです。

プロビジョニングには cloud-init を使用します。 作成後に VM を手動で設定しないでください。SSH キー、ネットワーク設定、パッケージ、ユーザーアカウントを cloud-init で注入します。
すべてに virtio を使用します。 ディスク（virtio-scsi）、ネットワーク（virtio-net）、ディスプレイ（ヘッドレスの場合は virtio-gpu）に使用します。IDE と e1000 は、レガシー OS との互換性が必要な場合にのみ使用します。
CPU タイプは host に固定します。 エミュレートされた CPU タイプ（kvm64、qemu64）では、ゲストに必要な機能（AES-NI、AVX、SSE4）が隠されます。異種ハードウェア間でのライブマイグレーションが必要な場合を除き、host を使用します。
ディスク設定の変更は、再起動ではなくシャットダウンと起動でテストします。 qm shutdown で正常にシャットダウンし、qm status が停止状態を報告することを確認してから、新しい QEMU プロセスを起動します。

ステップ 4：検証する

検証項目	方法
VM が起動し、エージェントが応答する	`qm agent <vmid> ping`（Proxmox）
cloud-init が完了している	ゲスト内で `cloud-init status --wait` を実行
ディスクのパフォーマンス	`fio --name=test --rw=randread --bs=4k --direct=1 --numjobs=4 --runtime=30`
TRIM/discard が機能している	ゲスト内で `fstrim -v /` を実行し、ホストで thin pool の data_percent を確認
PCI パススルー	ゲスト内の `lspci` にパススルーしたデバイスが表示され、ドライバーが読み込まれている
ネットワーク接続	`ping gateway` を実行し、`ip addr` が cloud-init の設定と一致することを確認
メモリ	ゲスト内の `free -h` が想定どおりである（バルーニングで減らされていない）
ライブマイグレーション	まず重要でない VM で `qm migrate <vmid> <target> --online` をテスト

ゲストでは fio がインストールされていないことがよくあります：command -v fio >/dev/null || echo "fio missing: sudo apt install fio (Debian/Ubuntu)"。チェックに失敗した場合は設定を修正してステップ 3 に戻ります。ハードウェアレベルの修正を反映するには、ゲストの再起動ではなく QEMU の新規起動が必要です。

クイックタスク：クラウドイメージからの VM（Proxmox）

本番環境ですぐに使える VM を最速で作成する方法です。標準的なセットアップでは、Packer と ISO インストールを省略できます。

安定版のクラウドイメージを Proxmox ノードにダウンロードします（cloud-init に不備がある場合があるため、daily/ は使用しないでください）。 wget -P /var/lib/vz/template/iso/ https://cloud.debian.org/images/cloud/trixie/latest/debian-13-generic-amd64.qcow2
VM のベースを作成します。 qm create 100 --name myvm --memory 2048 --cores 2 --cpu host --net0 virtio,bridge=vmbr0 --agent enabled=1 --scsihw virtio-scsi-single
SSD 向けに最適化してディスクをインポートし、接続します。 qm importdisk 100 /var/lib/vz/template/iso/debian-13-generic-amd64.qcow2 local-lvm qm set 100 --scsi0 local-lvm:vm-100-disk-0,discard=on,iothread=1,ssd=1 --boot order=scsi0
cloud-init ドライブを追加して設定します。 qm set 100 --ide2 local-lvm:cloudinit qm set 100 --ciuser admin --sshkeys ~/.ssh/id_ed25519.pub --ipconfig0 ip=10.0.0.100/24,gw=10.0.0.1
起動します：qm start 100
検証します：qm agent 100 ping（初回起動時は cloud-init の実行中に 1～2 分かかる場合があります）

起動済みの VM から再利用可能なテンプレートを作成するには、まずゲスト内でインスタンスごとの状態をリセットします： sudo cloud-init clean --logs --machine-id && sudo rm -f /etc/ssh/ssh_host_* && sudo poweroff （クローンの初回起動時に、cloud-init がホストキーと machine-id を再生成します）。その後、qm template 100 を実行します。 qm clone 100 101 --name new-vm --full でクローンを作成します。

Proxmox VE クイックリファレンス

API、CLI、ストレージバックエンド、クラスタリング、HA、移行、PCI パススルー、バックアップ、Terraform のパターンについて詳しくは、references/proxmox.md を参照してください。

基本的な CLI

# VM management
qm list                              # List all VMs
qm create 100 --name test --memory 2048 --cores 2 --net0 virtio,bridge=vmbr0
qm start/stop/shutdown/reset 100     # Power operations
qm config 100                        # Show VM config
qm set 100 --memory 4096             # Modify config (some need stop/start)
qm resize 100 scsi0 +10G             # Extend disk (can't shrink)
qm agent 100 ping                    # Test QEMU agent
qm migrate 100 pve2 --online --with-local-disks  # Live migrate

# Container management
pct list                              # List LXC containers
pct create 200 local:vztmpl/debian-12-standard_12.7-1_amd64.tar.zst

# Storage
pvesm status                          # Storage pool overview
lvs -a -o+devices                     # LVM thin pool status (on LVM backend)

# Cluster
pvecm status                          # Cluster status
pvecm nodes                           # Node list
ha-manager status                     # HA status

重大な注意点（実環境で検証済み）

本番環境の Proxmox で得られた知見です。デバッグにかかる時間を大幅に短縮できます。

停止／起動と再起動の違い： ゲストの reboot では QEMU プロセスは再起動されません。ディスク設定の変更（discard、キャッシュモード、iothread、バスタイプ）は、QEMU を完全に停止して起動し直したときにのみ適用されます。ハードウェア設定を変更する場合は、qm shutdown を実行し、停止状態を確認してから qm start を実行してください。メモリバルーンデバイスの変更にも同じことが当てはまります。qm stop は、正常なシャットダウンに失敗した後の、明確な理由がある強制停止からの復旧時に限って使用してください。ゲストの電源が即座に切れます。

LVM シンプールの使用率が 100%： data_percent が 100% に達すると、そのプール上のすべての VM I/O が即座に失敗し、ゲストは応答しなくなります。段階的に悪化することはありません。復旧するには、シンプールに対して lvextend を実行するか、VM を別の場所へ移行する必要があります。シンプールの使用量を監視し、100% に達するかなり前にアラートを出してください（80% で警告、90% で重大）。data_percent は、シンプールのデータ領域のうち、現在シンプール内のシンボリュームに割り当てられている割合（lvmthin(7)）を示すもので、ゲスト内のファイルシステムの使用量ではありません。VM が 50GB を書き込んでから削除しても、discard がシンプールに届くまでは、その 50GB は割り当てられたままです。

SSH 経由のライブマイグレーション： qm migrate はフォアグラウンドで実行されます。SSH セッションが切断されると、マイグレーションは中止されます。大容量の VM（ディスク 32GB 以上）では、次を使用してください。

nohup qm migrate <vmid> <target> --online --with-local-disks \
  > /tmp/migrate-<vmid>.log 2>&1 &

マイグレーションは中止しても安全です。失敗時もソース VM は稼働したままで、移行先の LV はクリーンアップされます。

KVM のバルーニング： バルーンデバイスを使うと、設定された最小値と memory: の間で、ホストがゲストの未使用メモリを回収できます。これにはゲストの virtio_balloon ドライバーが必要です。最小構成の Alpine イメージや一部の BSD ではこのドライバーが読み込まれないため、ホストからの要求は単に無視されます。実行中の最大メモリを超えて memory: を増やすのは別の仕組みである DIMM ホットプラグであり、hotplug: memory と NUMA に加え、新しいブロックをオンラインにするゲスト、または完全な停止／起動が必要です。Debian であっても、メモリ不足時のバルーン動作は予測できません。推奨事項：bpg/proxmox Terraform の memory ブロックで floating = 0 を使用するか、ネイティブの Proxmox 設定で balloon: 0 を設定し、VM には実際に必要なメモリを割り当ててください。

Proxmox 上の fail2ban（Debian 13）： journald 環境では /var/log/daemon.log は存在しません。jail 設定で backend = systemd と journalmatch = _COMM=pvedaemon を使用してください。

IPMI 非対応ハードウェアでの openipmi： 起動時に失敗し、誤報のアラートが発生します。BMC／IPMI ハードウェアのないノードでは、systemctl mask openipmi を安全に実行できます。マスキングはパッケージの更新後も維持されますが、無効化は維持されません。

ストレージのパフォーマンス

バックエンド	最適な用途	シンプロビジョニング	スナップショット	ライブマイグレーション
LVM-thin	ローカル SSD、本番環境	はい	はい（コピーオンライト）	--with-local-disks を指定
ZFS	データ整合性、圧縮	はい	はい（ネイティブ）	レプリケーションを使用
Ceph/RBD	マルチノードの共有ストレージ	はい	はい	ネイティブ（共有）
NFS	ISO、テンプレート、バックアップ	NAS に依存	場合による	はい（共有）
local (dir)	小規模／テスト	いいえ（ファイルベース）	qcow2 のみ	いいえ

ディスクインターフェースの優先順位（速い順）：

virtio-scsi-single + iothread - ディスクごとに 1 つのコントローラーを使用し、IOPS が最も優れています
virtio-scsi-pci（ディスクごとの iothread なし） - コントローラーを共有し、中程度の I/O に適しています
virtio-blk - 従来の virtio で、パフォーマンスは良好ですが、機能は少なめです
IDE - 古い OS のみ。古い OS の一部で必要です

SSD 最適化チェックリスト：

ディスク設定で ssd = 1 を指定する（ゲストに SSD 上にあることを伝え、ゲストで TRIM を有効にします）
QEMU ディスクで discard = on を指定する（TRIM／UNMAP をストレージバックエンドに渡します）
ゲストで fstrim.timer を有効にする（systemd ディストリビューションではデフォルトで週 1 回実行されます）
ゲストで fstrim -v / を実行して確認し、その後ホストで lvs -o data_percent を確認する

**ディスクのサイズ変更（Terraform の落とし穴）：**どちら側からでも拡張できますが、所有できるのは片方だけです。bpg/proxmox プロバイダーは、disk.size の増加時にディスクをインプレースで拡張します。disk が VM の hotplug リストにある場合は稼働中に拡張し、それ以外の場合はプロバイダーが再起動を開始して拡張します。縮小はどこでもサポートされていません。所有者は一方に決めてください：

Terraform が所有： disk ブロックの size を増やして apply を実行します。disk を ignore_changes に含めないでください。含めると、拡張が適用されません。
ホストが所有： Proxmox ホストで qm resize <vmid> scsi0 +10G を実行し、disk を ignore_changes に含めたままにして、プランに差分が残らないよう、その後 Terraform のサイズを更新します。

どちらの場合も、ゲスト内で次の手順を実行します：growpart /dev/sda 1（パーティションを拡張）、続いて resize2fs /dev/sda1 または xfs_growfs /（ファイルシステムを拡張）。両方を所有者にすると、ディスクを縮小または再作成するプランが生成されます。

メモリ管理

**バルーニングの概要：**実際のゲスト OS とワークロードでテストしていない限り、使用しないでください。VM 設定で balloon: 0 を指定して無効にします。

**NUMA：**4 コア以上、または RAM が 8GB 以上の VM で有効にします。Proxmox では、VM 設定で numa: 1 を指定します。QEMU はホストのトポロジーに合わせて NUMA ノードを自動作成します。

**ヒュージページ：**2MB または 1GB のページを使うと、TLB ミスが減少します。データベースやメモリを大量に使用するワークロードでは大きな効果があります。ホストで設定します：

# Reserve 1024 x 2MB hugepages (2GB total)
echo 1024 > /proc/sys/vm/nr_hugepages
# Persistent: add to /etc/sysctl.d/
vm.nr_hugepages = 1024

次に VM 設定で有効にします。注：ヒュージページのメモリは共有もバルーニングもできません。

**CPU のホットプラグとメモリのホットプラグ：**ほとんどの最新 Linux ゲストでは、CPU のホットプラグは稼働中に機能します。メモリのホットプラグ（実行時の DIMM 追加）には、hotplug: memory と VM の NUMA 有効化に加え、新しいブロックをオンラインにするゲストが必要です。通常は udev ルールを使用します。この 3 つがすべて揃っていない場合、変更は通知なく失敗します。これは、設定された最小値と memory: の間でメモリを移動するだけのバルーニングとは別の仕組みです。メモリは作成時に適切なサイズに設定してください。

ハイパーバイザーの選定

ハイパーバイザー	種類	最適な用途	避けるべき場合
Proxmox VE	Type 1（KVM+LXC）	ホームラボ、中小企業、API 主導の自動化	VMware エコシステムのツールが必要な場合
libvirt/KVM	Type 1（ベアメタル）	カスタム構成、OpenStack、直接制御	GUI やクラスタリングをすぐに利用したい場合
XCP-ng	Type 1（Xen）	Xen ベースのインフラ、XenOrchestra UI	KVM 固有の機能（virtio-fs）が必要な場合
VMware ESXi	Type 1	VMware への既存投資があるエンタープライズ環境	Broadcom 買収後はライセンス費用が急騰しました
VirtualBox	Type 2	開発用ワークステーション、テスト	本番環境。どんな場合でも。

Broadcom 買収後の VMware（2026 年）： Broadcom は VMware を買収しました（2023 年 11 月に買収完了）。永続ライセンスは廃止され、サブスクリプションのみのモデルに移行しました。無償版 ESXi は提供終了となり、その後一部再開されました（「無償ハイパーバイザー」ESXi 8.0 U3e、2025 年 4 月）。多くの組織が Proxmox または XCP-ng に移行しています。VMware からの移行手順は十分に文書化されていますが、大規模環境では簡単ではありません。

参考ファイル

references/proxmox.md - Proxmox VE の詳細解説：API、CLI、ストレージ、クラスタリング、HA、ライブマイグレーション、PCI パススルー（Windows 11 + NVIDIA のクイック手順を含む）、Proxmox Backup Server、Terraform（bpg/proxmox プロバイダのパターン、ライフサイクルの注意点、cloud-init）
references/libvirt-qemu-kvm.md - libvirt/QEMU/KVM：virsh コマンド、XML ドメイン定義、 QEMU コマンドライン、KVM モジュール、ディスク形式、ネットワーク、および Proxmox を使わずに libvirt を始めるためのクラウドイメージのクイックスタート
references/image-building.md - Packer テンプレート、cloud-init の構成、クラウドイメージのワークフロー、テンプレート管理
references/gotchas.md - 本番環境の Proxmox/KVM 環境で実証された落とし穴と障害のパターン。重大な変更を行う前にお読みください。

出力要件

要件の全文は references/output-contract.md を参照してください。

スキル名： VIRTUALIZATION
成果物の分類： audits
モード： 条件付き。既存のリポジトリ内容の分析、レビュー、監査、改善を依頼された場合は、references/output-contract.md の報告量と証拠に関するルールを適用し、成果物を docs/local/audits/virtualization/<YYYY-MM-DD>-<slug>.md に書き込んでください。質問への回答、概念の解説、新しい成果物の作成、コンテンツの生成を依頼された場合は、要件に縛られず自由に回答してください。
重大度の尺度： P0 | P1 | P2 | P3 | info（共有要件を参照。監査／レビューのモードでのみ使用します）。

ルール

ハードウェア変更時は再起動ではなく、シャットダウンして起動します。 ゲストの再起動では QEMU は再起動されません。正常にシャットダウンし、停止状態を確認してから起動します。強制停止には別途理由が必要です。
ディスクサイズを管理するのは1つの方法だけにします。 bpg/proxmox の disk.size で拡張する場合は、disk を無視対象にしないでください。または、ホストで qm resize を使って拡張する場合は、disk を無視対象にします。両方を使ってはいけません。最後に、ゲストで growpart と resize2fs または xfs_growfs を実行します。
デフォルトでバルーニングを無効にします。 特定のゲスト OS でテストした後にのみ有効にしてください。
シンプールの data_percent を監視します。 80% でアラート、90% で重大アラートを発報してください。100% になると、すべての I/O が失敗します。
長時間の移行には nohup を使います。 SSH が切断されると、フォアグラウンドで実行中の qm migrate が終了します。
Terraform の VM では prevent_destroy と ignore_changes を設定します。 誤操作による破棄を防ぎ、ライブマイグレーションがドリフトとして検出されないように、node_name と生成された MAC を無視します。ホストがサイズ変更を管理する方法（ルール 2）の場合にのみ、disk を ignore_changes に追加します。
本番環境で使う前にテストします。 新しい VM 設定、パススルーの構成、ストレージバックエンドなどは、まず重要度の低い VM でテストしてください。

Markdown 対応

ログインしてコメント

基本情報

作者: iuliandita
リポジトリ: iuliandita/skills
カテゴリ: クラウド・DevOps
インストール数: 66
GitHub スター: 10

問題を報告