はじめに

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