インストール

Condensa は 単一の自己完結型バイナリ として配布されます。Web UI はバイナリに埋め込まれ、データベースは SQLite、設定は環境変数で行います。 Kubernetes は不要です（移行先が Awanio CEP の場合にのみ関係します）。

要件

Linux x86_64 サーバー（VM でも可）
Condensa サーバーから以下へのネットワークアクセス:
- VMware vCenter/ESXi（ポート 443）
- 移行先 — Awanio Cockpit または Vapor の API（統合を参照）
ステージング転送用のディスク容量（staged フォールバックと OVA/VHD アップロードのみが使用）: 移行する最大のディスクに合わせて確保してください

データ経路の依存関係

Condensa はディスクデータを 2 つの経路のいずれかで転送し、それぞれに前提条件があります。エンジンは移行ごとに自動選択されるため、大きな転送を始める前にどちらが使われるかを把握しておくと安全です。

データ経路	データの流れ	ウォーム移行	前提条件
VDDK 直接（推奨）	ESXi → 移行先ホスト	対応	移行先の Vapor ホスト: VDDK プラグイン付き nbdkit、VMware の VDDK ライブラリ、`qemu-nbd` と `nbdfuse`
ステージング（フォールバック、Cockpit のみ）	ESXi → Condensa → 移行先	非対応	Condensa ホスト: `qemu-img`（パッケージ `qemu-utils`）

移行先ホスト（Vapor）: VDDK

VDDK がないとウォーム移行は行えず、すべての移行がステージング経路にフォールバックします。Vapor の UI（System → Third-party libraries）または Ansible ロールで導入し、バッジが installed になることを確認してください。選択されたエンジンは移行ログに出力されます:

Target host supports VDDK; using direct VDDK pull

代わりに Target host has no VDDK (nbdkit not found) と表示された場合は、ステージング経路が使われています。

Condensa ホスト: qemu-img

ステージング経路では、エクスポートした各ディスクを Condensa 内部で qcow2 に変換するため、qemu-img が必要です:

bash

sudo apt-get install -y qemu-utils     # Debian/Ubuntu
sudo dnf install -y qemu-img           # RHEL/Rocky

これが無い場合、Condensa はエクスポートの途中で失敗するのではなく、ステージング移行の開始自体を拒否します。仮想アプライアンスには最初から含まれています。

移行先には VDDK を

ステージング経路は全バイトを 2 回コピーし（ソース → Condensa → 移行先）、最大ディスク分のステージング領域を必要とします。移行先に VDDK を導入すればどちらのコストも無くなり、ウォーム移行も可能になります。大きな VM を移行する前に導入する価値があります。

ステージング経路のネットワーク到達性

ステージング経路では、移行先 が CONDENSA_PUBLIC_URL を通じて Condensa から準備済みディスクをダウンロードします。この URL はブラウザからだけでなく 移行先ホストから 到達できる必要があります。移行先がルーティングできないプライベートネットワークや NAT 内のアドレスでは、ダウンロード段階で失敗します。

1. バイナリの配置

bash

sudo install -m 0755 condensa-server /usr/local/bin/condensa-server
sudo mkdir -p /var/lib/condensa/staging /var/log/condensa /etc/condensa

2. 暗号化キーの生成

プロバイダーの認証情報（vCenter パスワード、API トークン）は AES-256-GCM で暗号化 して保存されます。キーは一度だけ生成し、運用者が保管します — データベースが漏えいしても認証情報は漏れません。

bash

condensa-server -generate-key

認証トークン用の JWT 署名シークレット も必要です。これがないとサーバーは起動しません（安全でないデフォルトは持ちません）。後から変更すると既存のセッションは無効になります:

bash

openssl rand -base64 48

両方を /etc/condensa/condensa.env に保存します:

bash

sudo tee /etc/condensa/condensa.env <<'EOF'
CONDENSA_ENCRYPTION_KEY=<生成した暗号化キー>
JWT_SECRET=<生成した JWT シークレット>
EOF
sudo chmod 600 /etc/condensa/condensa.env

キーは厳重に保管

CONDENSA_ENCRYPTION_KEY を失うと、すべてのプロバイダー認証情報を再入力する必要があります。他のシークレットと同様にバックアップしてください。

3. systemd ユニットの作成

/etc/systemd/system/condensa.service:

ini

[Unit]
Description=Condensa VM migration server
After=network-online.target
Wants=network-online.target

[Service]
ExecStart=/usr/local/bin/condensa-server
Environment=PORT=8080
Environment=DB_PATH=/var/lib/condensa/condensa.db
Environment=CONDENSA_UPLOAD_DIR=/var/lib/condensa/staging
Environment=CONDENSA_LOG_FILE=/var/log/condensa/condensa.log
Environment=CONDENSA_PUBLIC_URL=http://condensa.example.com:8080
# condensa.env holds CONDENSA_ENCRYPTION_KEY and JWT_SECRET (chmod 600)
EnvironmentFile=/etc/condensa/condensa.env
Restart=on-failure

[Install]
WantedBy=multi-user.target

bash

sudo systemctl daemon-reload
sudo systemctl enable --now condensa

環境変数

変数	必須	用途
`CONDENSA_ENCRYPTION_KEY`	必須	プロバイダー認証情報の AES-256 暗号化キー（`-generate-key`）
`JWT_SECRET`	必須	認証トークンの署名キー（32 バイト以上、例: `openssl rand -base64 48`）。設定しないとサーバーは起動しません
`PORT`	任意（既定 8080）	HTTP リッスンポート
`DB_PATH`	任意	SQLite データベースファイルのパス
`CONDENSA_PUBLIC_URL`	staged 転送 / OVA 用	移行先が Condensa のディスク配信エンドポイントへ到達する URL
`CONDENSA_UPLOAD_DIR`	staged 転送 / OVA 用	ステージングディレクトリ — 最大ディスクに合わせる
`CONDENSA_LOG_FILE`	推奨	UI の Logs ページを有効化
`CONDENSA_ADMIN_USERNAME` / `CONDENSA_ADMIN_PASSWORD`	任意	最初の管理者を非対話で作成（自動化用）
`CONDENSA_TLS`	推奨	`off`、`self-signed`、`on` — HTTPS を参照
`CONDENSA_TLS_CERT` / `CONDENSA_TLS_KEY`	`CONDENSA_TLS=on` の場合	PEM 証明書チェーンと秘密鍵
`CONDENSA_TLS_HOSTS`	いいえ	自己署名証明書に含める追加の名前/アドレス
`CONDENSA_UPDATE_URL`	インプレース更新に必要	署名済み更新フィード — 更新を参照
`CONDENSA_UPDATE_PUBLIC_KEY`	`CONDENSA_UPDATE_URL` と併用	フィードを検証する Ed25519 鍵

HTTPS

ログインフォームはパスワードを送信し、以降のリクエストはすべてセッショントークンを含みます。ダッシュボードは TLS で提供してください。3 つのモードがあります:

`CONDENSA_TLS`	動作
`off`（既定）	平文 HTTP。前段のリバースプロキシが TLS を終端する場合のみ。
`self-signed`	Condensa が自己署名証明書を発行し、自動更新します。
`on`	`CONDENSA_TLS_CERT` と `CONDENSA_TLS_KEY` を使用します。

認識できない値は起動時エラーになります。黙って平文にフォールバックすることはありません。

自己署名証明書

多くの環境ではプライベートネットワーク上の IP アドレスでアクセスするため、証明書を発行してくれる認証局が存在しません:

bash

CONDENSA_TLS=self-signed

証明書はデータベースの隣に保存され、ループバック・ホスト名・全インターフェイスアドレスを含み、有効期限が近づいたときやホストが新しいアドレスを得たときに自動で再発行されます。信頼するまでブラウザは初回に警告しますが、毎リクエストで資格情報を平文送信するよりはるかに安全です。

インターフェイスから導出されない名前を追加する場合:

bash

CONDENSA_TLS_HOSTS=condensa.internal.example.com,10.20.0.5

自分で用意する証明書

bash

CONDENSA_TLS=on
CONDENSA_TLS_CERT=/etc/condensa/tls/fullchain.pem
CONDENSA_TLS_KEY=/etc/condensa/tls/privkey.pem

サービスユーザーが両方のファイルを読める必要があります。

Condensa から取得する転送経路

3 つの移行経路では、ターゲットが CONDENSA_PUBLIC_URL 経由で Condensa からディスクデータをダウンロードします: VDDK のない VMware ソースのステージング経路、ノードがターゲットへ直接届かない Proxmox ソースのパイプ経路、そして Awanio CEP (CDI) です。これらは証明書を検証するため、自己署名証明書は 拒否されます — 転送はエクスポート完了の数分後にターゲット側で失敗し、ターゲットホストのログに x509: certificate signed by unknown authority が残ります。

影響を受けないもの: 直接 VDDK 移行（Cockpit / Vapor ターゲットの既定）、 Proxmox のノード側変換、およびすべてのウォーム移行 — いずれも Condensa から取得しません。

検証を満たす方法は 2 つあります:

CA 署名済みの証明書を使う（CONDENSA_TLS=on）。CEP ターゲットではこちらがサポートされる方法です。
各ターゲットホストで自己署名証明書を信頼する。 証明書はデータベースの隣、データディレクトリ内の tls/server.crt にあります。Vapor / Cockpit ホストでは:
bash
```
sudo cp server.crt /usr/local/share/ca-certificates/condensa.crt
sudo update-ca-certificates
sudo systemctl restart vapor
```
その後、そのホストから検証が通ることを確認します — -k なしで:
bash
```
curl https://<condensa>:8080/condensa/api/v1/health
```
証明書が再発行されたら繰り返してください（期限が近づくと自動更新され、 Condensa ホストに新しいアドレスが付くと再発行されます）。

TLS を有効にしたら CONDENSA_PUBLIC_URL も https:// にしてください。

4. 初回起動

http://<server>:8080 を開きます。新しいデータベースでは セットアップウィザード が表示され、最初の管理者アカウントを作成してそのままログインします。スクリプトによるデプロイでは CONDENSA_ADMIN_USERNAME と CONDENSA_ADMIN_PASSWORD を設定すると起動時に管理者が作成されます。

セットアップ後:

Users タブ（管理者専用）で追加アカウントを作成します。member ロールはオペレーター用で、プロバイダーの閲覧と移行の作成・開始・キャンセルができます。プロバイダー管理、削除、ユーザー管理、監査ログは管理者専用です。
セキュリティ上重要な操作（ログインとその失敗、ユーザー/プロバイダーの変更、移行のライフサイクル）はすべて Audit Log タブに記録されます。

5. プロバイダーの接続

統合に進み、VMware ソースと Awanio Cockpit / Vapor ターゲットを登録してください。

更新

更新は /var/lib/condensa にも /etc/condensa にも触れません。プロバイダー、暗号化された資格情報、移行履歴、ユーザー、2 つのシークレットはそのまま引き継がれます。再設定は不要です。

ダッシュボードから

新しいリリースが公開されると、管理者に Install update ボタン付きの通知が表示されます。Condensa はリリースをダウンロードし、検証し、インストールして再起動します（数秒間の停止）。移行の実行中は再起動が移行を破棄するため、ボタンは拒否します。

1.3.1〜1.5.1 のインストールは一度だけ手動で更新してください

バージョン 1.3.1 から 1.5.1 では、Install update ボタンが完了しません。ダイアログは待機したまま "the restart is taking longer than expected" と表示するか、ファイルシステムのエラーを示します。1.3.0 以前のインストールは影響を受けません。

該当するインストールは一度だけ手動で更新してください。サービスを停止し、バイナリを本リリースのものへ置き換え、再び起動します:

bash

sudo systemctl stop condensa
curl -fLo /tmp/condensa.tar.gz <ポータルのダウンロード URL>
sudo tar -xzf /tmp/condensa.tar.gz -C /usr/local/bin condensa
sudo systemctl start condensa

再設定は不要です。provider、認証情報、移行履歴、2 つの secret はいずれも変更されません。1.6.0 以降はボタンが再び機能し、以後のリリースは自動でインストールされます。

1.6.1 より前に install.sh で導入しましたか。もう一度実行してください

Install update ボタンは、インストーラーが設定する小さな特権コンポーネントに依存します。condensa install と仮想アプライアンスは以前からこれを導入していましたが、install.sh が導入するようになったのは 1.6.1 からです。それ以前に install.sh で構築した host では、ボタンはクリックを受け付け、dashboard は誰も実行しない再起動を待ち続けます。

最新リリースのインストーラーを一度実行し直せば追加されます。再設定は不要で、既存のインストールに対しても安全に実行できます:

bash

sudo ./install.sh ./condensa

その後はボタンが正常に機能し、以後のリリースは自動でインストールされます。

Condensa 1.1.8 以降でセットアップしたインストールは、エンタープライズポータルを確認するようあらかじめ設定されています — 鍵も設定も不要です。ソースは /etc/condensa/condensa.env の 1 行で、空にすると更新確認を無効化できます:

bash

CONDENSA_UPDATE_URL=https://enterprise.awan.io/api/v1/products/condensa/releases/latest

1.1.8 より前にセットアップしたインストールは、次回の手動アップグレード後に同じ動作になります。上の行を手で追加しても構いません。

コマンドラインから

bash

sudo condensa update --check    # 利用可能な更新を表示するだけ
sudo condensa update            # 最新リリースを導入して再起動
sudo condensa update --to 1.1.7 # 特定のリリースを導入

移行の実行中に更新するには --force を付けます — その移行は中断され失敗します。

更新時の検証

現在動作しているバイナリを置き換える前に:

リリースが信頼できる出所であること — 設定したポータルへの TLS、またはエアギャップ用フィードでは設定した鍵で検証できる Ed25519 署名;
ダウンロードしたファイルの SHA-256 がフィードの公開値と一致すること;
ダウンロードしたバイナリが実行でき、約束されたバージョンを報告すること — 切り詰められた、またはアーキテクチャの異なるダウンロードを検出します;
強制しない限り、実行中の移行がないこと。

置き換えられたバイナリは condensa.previous として残るため、ロールバックはコピーと再起動だけです。

手動でバイナリを差し替える

引き続きサポートされます — データベース移行は起動時に自動実行されます:

bash

sudo install -m 0755 condensa /usr/local/bin/condensa
sudo systemctl restart condensa

エアギャップ環境のインストール

エンタープライズポータルに到達できないホストも、2 つの方法でインプレース更新できます。

手動（最も簡単）: 管理された転送経路でリリース tarball を持ち込み、ポータルのリリースページに表示される SHA-256 と照合してから:

bash

tar -xzf condensa-<version>-linux-amd64.tar.gz
sudo ./condensa install

アップグレードはデータベース、プロバイダー、資格情報、設定を保持します。

内部ミラーからの自動更新: Awanio は納品物の一部として、署名済みフィード（updates.signed.json）とそれを検証する公開鍵を提供します。フィードとリリース tarball を内部の https サーバーに配置し、各インストールを設定します:

bash

CONDENSA_UPDATE_URL=https://releases.internal.example.com/condensa/updates.signed.json
CONDENSA_UPDATE_PUBLIC_KEY=<鍵A>,<鍵B>

ミラーの証明書が内部 CA のものである場合は、その CA を各 Condensa ホストの OS トラストストアに追加してください。フィードは Ed25519 署名されているため、ミラーが侵害されてもインストールが受け入れる内容は変えられません。その他の検証はすべてそのまま適用されます。

インストール ​

要件 ​

データ経路の依存関係 ​

移行先ホスト（Vapor）: VDDK ​

Condensa ホスト: qemu-img ​

ステージング経路のネットワーク到達性 ​

1. バイナリの配置 ​

2. 暗号化キーの生成 ​

3. systemd ユニットの作成 ​

環境変数 ​

HTTPS ​

自己署名証明書 ​

自分で用意する証明書 ​

4. 初回起動 ​

5. プロバイダーの接続 ​

更新 ​

ダッシュボードから ​

コマンドラインから ​

更新時の検証 ​

手動でバイナリを差し替える ​

エアギャップ環境のインストール ​

インストール

要件

データ経路の依存関係

移行先ホスト（Vapor）: VDDK

Condensa ホスト: qemu-img

ステージング経路のネットワーク到達性

1. バイナリの配置

2. 暗号化キーの生成

3. systemd ユニットの作成

環境変数

HTTPS

自己署名証明書

自分で用意する証明書

4. 初回起動

5. プロバイダーの接続

更新

ダッシュボードから

コマンドラインから

更新時の検証

手動でバイナリを差し替える

エアギャップ環境のインストール