Proxmox経験者のためのOpenNebulaストレージ解説〜Persistent/Non-Persistentイメージとクローン処理の仕組み〜

Posted at 2025-12-15

はじめに

ProxmoxからOpenNebulaへ移行する際、ストレージ周りの概念で混乱することがあります。特に以下の点でつまづきやすいです:

「Linked Clone」に相当する機能はどこ？
「Storage」が2種類（IMAGE/SYSTEM）に分かれているのはなぜ？
デフォルトがLinked Clone相当なのに、なぜ明示的に設定しなくていい？

本記事では、Proxmoxの知識を前提に、OpenNebulaのストレージ概念を解説します。実測データや推奨構成は次回の記事で扱い、今回は概念の理解に焦点を当てます。

検証環境

OpenNebula: 7.0.1
共有ストレージ: iSCSI (multipath) + OCFS2
ベースイメージ: Alpine Linux 3.17 (256MB, qcow2形式)

Proxmox vs OpenNebula 用語対応表

Proxmox概念	OpenNebula概念	説明
Linked Clone	Non-Persistent Image	backing fileで差分管理、ディスク効率的
Full Clone	Persistent Image	完全独立コピー、永続化
Storage	IMAGE Datastore	VMテンプレートの保管場所
(概念なし)	SYSTEM Datastore	VM起動時のディスク配置場所
デフォルト: Full Clone	デフォルト: Non-Persistent	設計思想の違い

重要なポイント: OpenNebulaはデフォルトでLinked Clone相当の動作をします。Proxmoxとは逆です。

IMAGE Datastore と SYSTEM Datastoreの2階層構造

OpenNebulaの最大の特徴は、ストレージが2階層に分かれていることです。

[IMAGE Datastore]              [SYSTEM Datastore]
  ベースイメージ保管     →     VM起動時のディスク配置
  (テンプレート庫)              (実行環境)

IMAGE Datastore（イメージデータストア）

役割: VMテンプレート（ベースイメージ）の保管場所
Proxmoxとの対応: Storageに相当
特徴: 複数VMで共有されるマスターイメージ

SYSTEM Datastore（システムデータストア）

役割: VM起動時に実際のディスクが配置される場所
Proxmoxとの対応: 明示的な対応概念なし
特徴: VMごとの実行ディスク（差分またはコピー）

なぜ2階層に分けるのか？

Proxmoxでは「どのStorageから起動するか」を選びますが、OpenNebulaでは「どこにテンプレートがあり（IMAGE DS）、どこで実行するか（SYSTEM DS）」を分離できます。これにより:

IMAGE DS: 高速なSANストレージ（共有）
SYSTEM DS: ローカルSSD（高速I/O）

といった柔軟な構成が可能になります。

Datastoreタイプ（qcow2/shared/ssh）のクローン処理の違い

OpenNebulaには3つの主要なDatastoreタイプがあり、それぞれクローン処理が異なります。

前提: すべて共有ストレージ（iSCSI + OCFS2）上に配置

今回の検証環境では、qcow2とshared DatastoreはiSCSI LUN上のOCFS2ファイルシステムに配置されています。sshのみローカルディスクです。

Datastoreタイプ	配置場所	フォーマット	主な用途
qcow2	共有ストレージ (OCFS2)	qcow2	backing file活用、ディスク効率重視
shared	共有ストレージ (OCFS2)	raw	I/O性能重視
ssh	ローカルディスク	qcow2またはraw	共有ストレージなし環境

各タイプのクローン処理

1. qcow2 Datastore（Proxmox Linked Clone相当）

VM起動時の動作:

[IMAGE DS: qcow2]                    [SYSTEM DS: qcow2]
alpine.qcow2 (256MB)    →    VM起動    →    disk.0 (backing file利用)
                                            ↓
                                      差分のみ保存（数MB〜数十MB）

IMAGE DS内のベースイメージをbacking fileとして参照
SYSTEM DSには差分ファイルのみ作成
qemu-img infoで確認すると: backing file: ../../108/9/disk.0

特徴:

ディスク使用量: 最小（ベースイメージ + 各VM差分）
VM起動速度: 超高速（ファイル参照のみ）
I/O性能: 中程度（Copy-on-Writeオーバーヘッド）

2. shared Datastore（設定により異なる）

VM起動時の動作:

[IMAGE DS: shared]                   [SYSTEM DS: shared]
alpine.raw (256MB)     →    VM起動    →    disk.0 (完全コピーまたはリンク)
                                            ↓
                                      完全独立ファイル（256MB）

IMAGE DSからSYSTEM DSへ完全コピー（デフォルト設定）
raw形式のため、thin provisioningなし
各VMが独立した完全サイズのディスクを持つ

特徴:

ディスク使用量: 大（VM数 × ベースイメージサイズ）
VM起動速度: 中程度（コピー時間が必要）
I/O性能: 最高（raw形式、オーバーヘッドなし）

3. ssh Datastore

VM起動時の動作:

[IMAGE DS: ssh]                      [SYSTEM DS: ssh (各ホストのローカル)]
alpine.qcow2 (256MB)   →    VM起動    →    ネットワーク転送
                                            ↓
                                      ローカルディスクにコピー（256MB）

IMAGE DSからネットワーク経由でホストのローカルディスクへ転送
共有ストレージがない環境向け

特徴:

ディスク使用量: 大（各ホストのローカル × VM数）
VM起動速度: 遅い（ネットワーク転送）
I/O性能: 高（ローカルディスク）
ライブマイグレーション: 不可

Non-Persistent Image の動作（デフォルト）

OpenNebulaで通常使用するのがNon-Persistent Imageです。ProxmoxのLinked Cloneに相当します。

基本動作

[IMAGE DS]
alpine.qcow2 (256MB, PERSISTENT=No)
    ↓ VM起動時
    ├─→ [SYSTEM DS] VM1/disk.0 (backing file, 差分52MB)
    ├─→ [SYSTEM DS] VM2/disk.0 (backing file, 差分48MB)
    └─→ [SYSTEM DS] VM3/disk.0 (backing file, 差分55MB)

特徴

項目	動作
複数VM起動	✅ 可能（1つのイメージから無制限）
ディスク使用量	最小（backing file効果）
VM削除時	SYSTEM DSの差分ファイルは削除される
変更の保存	❌ 保存されない（差分ファイル削除）
制御パラメータ	`CLONE_TARGET`

CLONE_TARGETの役割

Non-Persistent Imageのクローン動作はCLONE_TARGETで制御されます:

# 検証環境の設定例
$ onedatastore show 108 | grep CLONE_TARGET
CLONE_TARGET="SYSTEM"

CLONE_TARGET="SYSTEM": SYSTEM DSへクローン（標準）
CLONE_TARGET="SELF": IMAGE DS内でクローン（特殊用途）

qcow2 Datastoreでは、この「クローン」がbacking fileを使った差分ファイル作成を意味します。

Persistent Image の動作

データベースなど、変更を永続化したい場合に使用するのがPersistent Imageです。ProxmoxのFull Cloneに相当します。

基本動作

[IMAGE DS]
db-data.qcow2 (10GB, PERSISTENT=Yes)
    ↓ oneimage clone で複製
[IMAGE DS]
├─ db-vm1.qcow2 (10GB, PERSISTENT=Yes) → VM1専用
├─ db-vm2.qcow2 (10GB, PERSISTENT=Yes) → VM2専用
└─ db-vm3.qcow2 (10GB, PERSISTENT=Yes) → VM3専用
    ↓ VM起動時
[SYSTEM DS]
├─ VM1/disk.0 → シンボリックリンク → ../../108/db-vm1.qcow2
├─ VM2/disk.0 → シンボリックリンク → ../../108/db-vm2.qcow2
└─ VM3/disk.0 → シンボリックリンク → ../../108/db-vm3.qcow2

特徴

項目	動作
複数VM起動	❌ 不可（1イメージ = 1VM、排他ロック）
ディスク使用量	大（VM数 × イメージサイズ）
VM削除時	IMAGE DSのイメージは残る
変更の保存	✅ 保存される（IMAGE DSに直接書き込み）
制御パラメータ	`LN_TARGET`

LN_TARGETの役割

Persistent Imageのリンク動作はLN_TARGETで制御されます:

# 検証環境の設定例
$ onedatastore show 108 | grep LN_TARGET
LN_TARGET="NONE"

$ onedatastore show 1 | grep LN_TARGET
LN_TARGET="SYSTEM"

LN_TARGET="NONE": シンボリックリンク（qcow2/shared）
LN_TARGET="SYSTEM": 完全コピー（ssh）

Proxmoxとの重要な違い

	Proxmox Full Clone	OpenNebula Persistent Image
クローン作成	VM作成時に自動	`oneimage clone`で事前作成が必要
VM削除後	ディスク削除（オプションで保持）	IMAGE DSのイメージは常に残る
複数VM	各VMが独立したクローンを持つ	1イメージは1VMにしかアタッチできない

CLONE_TARGETとLN_TARGETの詳細

設定の全体像

Datastore	Image種別	使用パラメータ	動作
qcow2	Non-Persistent	`CLONE_TARGET="SYSTEM"`	SYSTEM DSに差分ファイル作成（backing file）
qcow2	Persistent	`LN_TARGET="NONE"`	SYSTEM DSにシンボリックリンク作成
shared	Non-Persistent	`CLONE_TARGET="SYSTEM"`	SYSTEM DSに完全コピー作成
shared	Persistent	`LN_TARGET="NONE"`	SYSTEM DSにシンボリックリンク作成
ssh	Non-Persistent	`CLONE_TARGET="SYSTEM"`	ローカルディスクに完全コピー
ssh	Persistent	`LN_TARGET="SYSTEM"`	ローカルディスクに完全コピー

検証環境の実際の設定

# qcow2 Datastore (ID: 108)
CLONE_TARGET="SYSTEM"    # Non-Persistent時: backing fileでSYSTEM DSへ
LN_TARGET="NONE"         # Persistent時: シンボリックリンク

# shared Datastore (ID: 104)
CLONE_TARGET="SYSTEM"    # Non-Persistent時: 完全コピーでSYSTEM DSへ
LN_TARGET="NONE"         # Persistent時: シンボリックリンク

# ssh Datastore (ID: 1)
CLONE_TARGET="SYSTEM"    # Non-Persistent時: ローカルへコピー
LN_TARGET="SYSTEM"       # Persistent時: ローカルへコピー（リンクしない）

重要な理解ポイント

OpenNebulaは自動的に適切なパラメータを選択する
- イメージのPERSISTENT属性を見て、CLONE_TARGETまたはLN_TARGETを使い分ける
- ユーザーが毎回指定する必要はない
qcow2でbacking fileが使われるのはCLONE_TARGET="SYSTEM"の結果
- qcow2 TransferManager (TM_MAD) がbacking file方式を実装している
- shared TM_MADは完全コピーを実装している
Persistent ImageでLN_TARGET="NONE"でもコピーされない理由
- シンボリックリンクで参照するため、実体はIMAGE DS内に1つだけ
- SYSTEM DSは実行場所を示すだけで、実際のストレージ消費はない

まとめ

OpenNebulaとProxmoxの3つの主要な違い

デフォルト動作が逆
- Proxmox: Full Clone（完全コピー）がデフォルト
- OpenNebula: Non-Persistent（Linked Clone相当）がデフォルト
- → OpenNebulaは最初からディスク効率を重視した設計
ストレージが2階層
- Proxmox: Storage（単一階層）
- OpenNebula: IMAGE DS（テンプレート） + SYSTEM DS（実行ディスク）
- → テンプレート保管と実行環境を柔軟に分離できる
Persistent Imageの扱い
- Proxmox: Full Clone作成は自動、削除時もディスク削除がデフォルト
- OpenNebula: oneimage cloneで事前作成、VM削除後もイメージ残存
- → データの永続性をより明示的に管理

Proxmox経験者が理解すべきポイント

概念	Proxmoxでの操作	OpenNebulaでの操作
Linked Clone作成	VM作成時に「Linked Clone」を選択	何もしない（デフォルト動作）
Full Clone作成	VM作成時に「Full Clone」を選択	`oneimage clone` + `oneimage persistent`
テンプレート管理	Storageに保存	IMAGE Datastoreに保存
実行ディスク配置	同じStorageまたは別Storage	SYSTEM Datastoreで明示的に管理

次回予告

次回の記事では、以下の6パターンで実際のディスク使用量を計測し、backing fileの効果を数値で確認します:

Image=qcow2, System=qcow2
Image=qcow2, System=ssh
Image=qcow2, System=shared
Image=shared, System=qcow2
Image=shared, System=ssh
Image=shared, System=shared

各パターンで3VMを起動し、ディスク使用量・起動速度・運用特性を比較します。

参考文献

OpenNebula Documentation - Storage System Overview

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

Proxmox経験者のためのOpenNebulaストレージ解説 〜Persistent/Non-Persistentイメージとクローン処理の仕組み〜

はじめに

検証環境

Proxmox vs OpenNebula 用語対応表

IMAGE Datastore と SYSTEM Datastoreの2階層構造

IMAGE Datastore（イメージデータストア）

SYSTEM Datastore（システムデータストア）

なぜ2階層に分けるのか？

Datastoreタイプ（qcow2/shared/ssh）のクローン処理の違い

前提: すべて共有ストレージ（iSCSI + OCFS2）上に配置

各タイプのクローン処理

1. qcow2 Datastore（Proxmox Linked Clone相当）

2. shared Datastore（設定により異なる）

3. ssh Datastore

Non-Persistent Image の動作（デフォルト）

基本動作

特徴

CLONE_TARGETの役割

Persistent Image の動作

基本動作

特徴

LN_TARGETの役割

Proxmoxとの重要な違い

CLONE_TARGETとLN_TARGETの詳細

設定の全体像

検証環境の実際の設定

重要な理解ポイント

まとめ

OpenNebulaとProxmoxの3つの主要な違い

Proxmox経験者が理解すべきポイント

次回予告

Proxmox経験者のためのOpenNebulaストレージ解説〜Persistent/Non-Persistentイメージとクローン処理の仕組み〜