Condensa リリースノート
このログは Condensa の更新、新機能、バグ修正を記録します。
バージョン 1.6.2 (2026年 8月)
ウォームマイグレーションは、自分が作成していないスナップショットを削除しなくなりました。 これまでは移行元 VM の すべての スナップショットを、1 回の実行につき 2 度削除していました。しかも最初の削除はデータを 1 バイトも複製する前に行われます。移行前の安全策としてスナップショットを取った運用者は、最初の手順でそれを失い、複製はその後に始まっていました。
- 削除されるのは
condensa-warm-*という名前のチェックポイントだけです。それ以外は元のまま残ります。 - 移行ログは、自身のチェックポイントをいくつ整理したかを示し、他のスナップショットには触れていないことを明記します。境界が推測ではなく可視になります。
- 移行が成功しても失敗しても、あなたのスナップショットは残ります。
移行前のスナップショットを保持していたのに後から消えていた場合、原因はこれです。設定は不要です。以前の動作は、任意で無効化する類のものではありませんでした。
データを移す前に、すべての disk で変更トラッキングを確認します。 vSphere は変更トラッキングを 2 か所に記録します。VM に 1 つ、各 disk に 1 つで、その disk が変更ブロックを報告できるかを決めるのは per-disk の設定だけです。Condensa は VM 側しか読んでいなかったため、変更トラッキングは準備済みと報告し、数分間転送し、そのうえで最初から供給できない disk で失敗することがありました。
- 確認は最初の数秒で行われ、disk を内部のデバイス番号ではなくバスアドレス —
scsi0:0— で示します。 - disk が未準備の場合、通常の解決策を示します。設定を反映させるために VM を一度停止して起動するか、その VM はコールドで移行してください。
- すでに正常に動いていたウォームマイグレーションに影響はありません。
更新バナーがページを自動で再読み込みします。 ダッシュボードのバナーから更新をインストールすると、以前は数秒後に再読み込みするようお願いしていました。現在は About ダイアログと同様に再起動を待って自動で再読み込みし、再起動が想定より長い場合はその旨を明示します。
バージョン 1.6.1 (2026年 8月)
ウォームマイグレーションが、実際に達成した整合性を報告するようになりました。 vSphere に quiesced スナップショットを要求してエラーが返らないことは、スナップショットが quiesced であることと同じではありません。VMware Tools が動作していない guest でも要求は成功し、スナップショットは crash-consistent のままです。Condensa は hypervisor からフラグを読み戻し、見つかったとおりに報告します。
- vSphere がスナップショットを quiesced と示した場合にのみ、コピーを application-consistent と呼びます。
- crash-consistent は黙って通り過ぎるのではなく明示され、log には何がそれを変えるか — guest 内で動作する VMware Tools — が記されます。これまで沈黙は、より良い答えとして読まれていました。
- フラグをまったく読めない場合は、どちらかに決めるのではなく、その旨を log に記します。
これは database など、一貫した時点を前提とするものにとって最も重要です。crash-consistent なコピーはたいてい十分に使えます。管理者を最悪の瞬間に驚かせるのは、application-consistent ではなかったものをそうだと告げられることです。
更新ステータスは、host が提供できないことを約束しなくなりました。 updater コンポーネントを持たないインストールは、更新を確認したときにその旨を伝えます。要求を受け付けたうえで、誰も実行しない再起動を待つことはありません。
バージョン 1.6.0 (2026年 8月)
provider を pin できるようになりました。 素の IP アドレスに自己署名証明書という構成は、オンプレミスやエアギャップ環境では珍しくない正当な運用形態であり、ラボ限定の近道ではありません。それでもこれまでは、そこへ接続する唯一の方法がすべての証明書を受け入れることでした — 攻撃者の証明書も含めて。pin はその両極の間に欠けていた選択肢を与えます。certificate authority は不要で、しかも何も無条件には信用しません。
1.3.1〜1.5.1 のインストールは一度だけ手動で更新してください
バージョン 1.3.1 から 1.5.1 では、Install update ボタンが完了しません。ダイアログは待機したまま "the restart is taking longer than expected" と表示するか、ファイルシステムのエラーを示します。1.3.0 以前のインストールは影響を受けません。
該当するインストールは一度だけ手動で更新してください。サービスを停止し、バイナリを本リリースのものへ置き換え、再び起動します:
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 以降はボタンが再び機能し、以後のリリースは自動でインストールされます。詳細な手順は Updating を参照してください。
新機能
- 接続セキュリティの 3 段階を並べて表示。 各 provider のフォームは、単独の「allow insecure connection」チェックボックスを、certificate authority による検証・この endpoint を pin する・検証を省略する、の 3 択に置き換えました。並べて示すのは、この判断が比較そのものだからです — チェックボックス 1 つでは「検証を省略」が自己署名向けの選択肢に見えてしまい、その思い込みこそが接続を無防備にします。
- fingerprint は受け入れる前に表示されます。 この endpoint を pin する を選ぶと、サーバーが提示している内容を読み取り、fingerprint・subject・issuer・有効期限・名前を表示します。判断は実際にそこにあるものに基づいて下されます。受け入れる前にサーバー自身が報告する値と照合してください — pin しようとしている当の接続からのみ fingerprint を読むことは、その接続が既に傍受されている場合には何の証明にもなりません。
- 証明書の更新は pin を壊しません。 Condensa が pin するのは証明書ではなくサーバーの公開鍵です。したがって再発行 — 新しいシリアル、新しい有効期限、一覧に追加された別のアドレス — があっても同一の識別情報として扱われます。mismatch が生じるのは鍵が本当に変わったときだけで、そのときはメッセージが両方の fingerprint を並べて示すため、再構築されたサーバーと偽装者を人間が見分けられます。
- Proxmox の SSH host key は別途 pin します。 ディスクのデータは Proxmox API 経由ではなく node 上の SSH で読み取られるため、API の証明書はその接続について何も語りません。Proxmox のフォームには専用の SSH host key の項目があり、node 上で fingerprint を確認するための
ssh-keygen -lfコマンドも示されます。
修正
- ステージング容量の確認が、ボリュームの実際の使用量ではなく公称サイズから見積もっていたため、1 GB 未満しか入っていない 40 GiB のディスクが 80 GiB として計上され拒否されていました。実際のゲストで計測したところ、見積もりは 82.0 GiB から 3.9 GiB に下がります。
- 転送が停止した際、オペレーターが対処できる情報が何も報告されませんでした。失敗は移行が単に止まったという表示ではなく、ターゲットホストが返した理由を伴うようになりました。
- ステージングされた Proxmox のディスク名が移行ログに二重に記録されていました。
- アプライアンスは自身の証明書を再発行する際に鍵を保持するようになりました。従来は更新のたびにアプライアンスの識別情報が変わっており、それは pin が最も許容できない挙動でした。
- 移行ウィザードに残っていた 2 つの選択欄 — target organization と target project — は、他のすべての項目と異なる挙動でした。入力による絞り込みもキーボード操作もできませんでした。現在はフォームの他の部分と揃っています。
更新にあたって
- 既存の provider は変更されません。insecure な接続を許可していた provider はそのままです。これまで受け入れていた接続が突然拒否されることはありません。
- pin は provider ごとの任意設定であり、pin を消せば元に戻せます。
- Proxmox では、node の SSH host key を pin するまで、SSH 経由の移行に 検証を省略 が引き続き必要です。pin すればその条件はなくなります。
バージョン 1.5.1 (2026年 8月)
インストールが自身の更新の入手先を把握するようになりました。
修正
- 更新元が設定されていないインストールは、自動更新チェックが無効であると報告し、About ダイアログを開いた人に環境変数の名前を示していました。これは例外的な少数ではなく大半のインストールに当てはまりました。その設定は新規インストール作成時にのみ書き込まれていたため、その場で更新されたサイトは受け取っておらず、手動で起動されたサーバーも同様でした。リリースフィードはバイナリに同梱されるようになり、何も設定しなくても見つかります。ダイアログがチェックを無効と表示するのは、誰かが意図的に無効化した場合だけになりました。
更新にあたって
CONDENSA_UPDATE_URLは設定されていればこれまで通り優先され、空の値を設定すれば更新チェックは無効のままです。インターネットへ接続してはならないサイトは、更新前にその値が空であることを確認してください。何も設定されていなかったために静かだっただけのインストールは、1.5.1 になるとリリースの確認を始めます。
バージョン 1.5.0 (2026年 8月)
Awanio CEP が VMware と Proxmox VE に加わり、移行元として利用できます。 ゲストはある Awanio CEP サイトから別のサイトへ移動します — サイトの統合、自社クラスタへの移行、あるいは事業者からの離脱。移行元サイトには一切の変更が不要です。既にある endpoint だけで足りるため、自分が管理していないプラットフォームに対しても使えます。まずは 移行元としての Awanio CEP から。
新機能
CEP から CEP への cold 移行。 移行元サイトがゲストのディスクを公開し、移行先クラスタ自身の importer がそれを直接取得します。Condensa は指揮するだけで 1 バイトも運ばないため、この経路には公開アドレスが不要です。稼働中のゲストは先に停止され、停止したままにされます。移行先で起動するのは複製された側です。
export の有効期間は作業量から決まり、作業の完了とともに閉じられます。 Condensa は固定値ではなく総ディスクサイズから導いた有効期間を要求し、その中で終わらないほど大きいゲストは — 何かを停止する前に — 拒否します。そして移行の終了時に export を閉じ、ダウンロードトークンを失効させます。期限切れまで有効なまま放置しません。
本当の進捗と、中断に耐える転送。 ディスクはサイズを申告する形式で取得されるため、バーは 0 のまま止まらず実際の割合を数えます。中断された転送はディスクを最初からやり直すのではなく、止まった地点から再開します。
修正
- 移行の進捗は完了時にしか再計算されなかったため、バーは転送中ずっと 0% を示し、その後成功へ飛んでいました。現在は移行一覧でも詳細表示でも、ポーリングのたびに更新されます。
- 転送が本当に総量を報告できない場合、バーは誤解を招く 0% を主張する代わりに size unknown と表示して往復します。
- ゲストはサイトが表示している名前で一覧されます。ホスト名で一覧すると、移行された複製が元のゲストの名前で現れ、オペレーターが電源状態でしか区別できない同一の行が 2 つ並んでいました。
- CEP サイトからのゲスト情報の取得は、最初の 10 件で止まらずサイト全体をたどり、ブートディスクだけでなくすべてのボリュームを合計し、サイトが報告するあらゆる形式のアドレスを読み取り、ゲストが OS variant を記録していない場合はカタログにフォールバックします。
対応する移行経路
| 移行元 | 移行先 | Cold | Warm |
|---|---|---|---|
| VMware vSphere / ESXi | Awanio CEP | ✓ | ✓ ¹ |
| VMware vSphere / ESXi | Awanio Vapor (単一ホスト) | ✓ | ✓ ² |
| VMware vSphere / ESXi | Awanio Cockpit (フリート) | ✓ | ✓ ² |
| Proxmox VE | Awanio Vapor (単一ホスト) | ✓ | ✓ |
| Proxmox VE | Awanio Cockpit (フリート) | ✓ | ✓ |
| Proxmox VE | Awanio CEP | — | — |
| Awanio CEP | Awanio CEP | ✓ | — ³ |
| Awanio CEP | Awanio Vapor または Cockpit | — | — |
¹ 移行元 VM で changed-block tracking (CBT) が有効であり、既存のスナップショットが必要です。 ² 移行先ホストに VDDK toolchain が必要です。VDDK は cold 移行にもより高速な直接経路をもたらします。 ³ KubeVirt がゲストのディスクを公開するのは停止中のみで、changed-block tracking も提供しないため、この経路に warm はありません。
更新の前に
- CEP の移行先は、移行ディスクを受け入れるプラットフォームビルドで動作している必要があります。古いビルドでは最初のディスクで移行が停止し、endpoint 名を含むメッセージが出ます — 更新するのは移行先であり、移行元ではありません。
- CEP の移行元には何も必要ありません。エージェントも設定も再起動も不要です。古い移行元に対しては、export が早期に閉じられる代わりに自然に期限切れとなり、その旨がログに残ります。
- 移行先クラスタの node が移行元サイトの API へ到達できる必要があります。ディスクを取得するのは node 自身なので、Condensa が両サイトに到達できるだけでは足りません。
- VMware および Proxmox の移行には変更はありません。
バージョン 1.4.1 (2026年 8月)
Proxmox の移行が完全にプライベートネットワーク内で完結するようになりました。 cold 移行は Proxmox の node 上で変換され、warm 移行が既に使っているのと同じ認証済みかつ短命なチャネルを通じて、移行先のストレージへ直接書き込まれます。Condensa は指揮しますがもはやディスクを運ばず、Proxmox を移行元とする場合に公開アドレスを必要としません。
新機能
- cold 移行はボリューム形式を問わず node から移行先へ直行します。 qcow2 も raw も同じく node 上で変換され、移行先にのみ着地します。Condensa 上に一時領域は不要で、何も入っていないブロックは回線を渡らないため、ほとんど空のボリュームは短時間で転送され thin のまま到着します。単一の Vapor ホストへも Cockpit のフリートへも同様に動作します。
- 移行用のポート範囲を移行先で固定できます。 Vapor 3.0.2 では Host → System → Migration で設定します。Proxmox の node と移行先ホストの間のファイアウォール規則は、ephemeral 範囲全体ではなく 1 つの小さな範囲で済みます。warm と cold は同じチャネルを使うため、規則は 1 つで両方をカバーします。
- 経路が塞がれていても迂回であって失敗ではありません。 データが動く前に、node が移行先のポートへ到達できるかを確認します。到達できない場合はアドレスと考えられる原因を挙げてログに記録し、移行は Condensa が運ぶフォールバック経路で続行します。
CONDENSA_PUBLIC_URLを使うのはそのフォールバックだけです。
対応する移行経路
| 移行元 | 移行先 | Cold | Warm |
|---|---|---|---|
| VMware vSphere / ESXi | Awanio CEP | ✓ | ✓ ¹ |
| VMware vSphere / ESXi | Awanio Vapor (単一ホスト) | ✓ | ✓ ² |
| VMware vSphere / ESXi | Awanio Cockpit (フリート) | ✓ | ✓ ² |
| Proxmox VE | Awanio Vapor (単一ホスト) | ✓ | ✓ |
| Proxmox VE | Awanio Cockpit (フリート) | ✓ | ✓ |
| Proxmox VE | Awanio CEP | — | — |
¹ 移行元 VM で changed-block tracking (CBT) が有効であり、既存のスナップショットが必要です。 ² 移行先ホストに VDDK toolchain が必要です。VDDK は cold 移行にもより高速な直接経路をもたらします。
更新の前に
- Proxmox の移行には、移行先ホストに Awanio Vapor 3.0.2 以降、フリートの手前に Awanio Cockpit 3.0.1 以降 が必要です。移行の前に Vapor 自身の更新ページから更新してください。
CONDENSA_PUBLIC_URLは Proxmox を移行元とする場合には不要になりました。VDDK を使わない VMware の cold 移行と、上記の Proxmox フォールバック経路では引き続き使用されます。- VMware の移行には変更はありません。
バージョン 1.4.0 (2026年 8月)
Proxmox VE が VMware に加わり、移行元として利用できます。 ゲストは Proxmox VE から、Awanio Vapor が管理する単一ホスト、または Awanio Cockpit が管理するフリートへ移動します。まずは 移行元としての Proxmox VE から。
新機能
- Proxmox VE からの移行、warm も cold も。 モードを選ぶ必要はありません。稼働中のゲストはライブでミラーされ、1 秒に満たない停止で切り替わります。停止中のゲストはそのまま複製されます。Proxmox 側で有効化すべきものはありません — changed-block tracking も、手動のスナップショットも不要です。切り替えに成功したあと、移行元のゲストは削除されず一時停止のまま残るため、古い方を手放す前に新しい VM を検証できます。
- すべてのネットワークインターフェースが引き継がれます。最初の 1 つだけではありません。 複数のインターフェースを持つゲストはそのすべてを保持し、それぞれ移行元と同じ MAC アドレスを持ち、移行先が提供できる範囲でアダプタのモデルも維持されます。したがって MAC やインターフェース名で紐付けているゲスト内部の設定はそのまま動作します。
- 移行元のネットワークごとに異なる宛先へ。 選択したゲストが複数の移行元ブリッジにまたがる場合、ウィザードは各ブリッジをどの移行先ネットワークにするか尋ねます。2 つを別々に対応付ければゲストが前提とする分離を保てますし、片方を何にも対応付けなければそのインターフェースは新しい VM に接続されません。
- 失敗した移行をその場で再実行。 行のアクションメニューから再開できます。以前の試行は履歴に残ります。
- ライブのディスクストリームは暗号化され、準備は不要です。 Cockpit フリートへの warm 移行は相互 TLS で保護されます。証明書は移行先が自ら発行し、Condensa は移行元側の分を移行の間だけ Proxmox の node に置き、終了後に削除します。
改善
- qcow2 ボリュームの cold 移行には一時領域が一切不要になりました — 読み取りながら Proxmox の node から移行先へ流れます。raw で保存されたボリューム (LVM-thin、ZFS、Ceph RBD) は引き続き Condensa を経由しますが、開始前に確認されるようになりました。容量が足りない移行は不足分を示して最初に拒否され、同時に実行されるのは 1 つだけなので、大きなゲストが複数あってもディスクを一緒に埋め尽くさず順番待ちになります。
- 別ネットワーク上の移行先への warm 移行。 管理ネットワークが知っている移行先ホストのアドレスと、移行元から到達できるアドレスが異なる場合は
CONDENSA_TARGET_WARM_ADDRESSを設定してください。Cockpit フリートへの warm 移行 を参照。 - 問題は作業の後ではなく前に報告されます。 移行先がこの Condensa からのダウンロードを拒否する場合や、Proxmox の node が移行先の disk-stream ポートへ到達できない場合、移行は 1 時間コピーしたあとではなく開始時にそれを伝えます — アドレスと変更すべき点を示して。何がどこへ到達する必要があるか を参照。
- warm の切り替えは可能な限りアプリケーション整合です。 ゲスト内で
qemu-guest-agentが動作していれば、切り替えの瞬間にファイルシステムが静止されます。動作していない場合はクラッシュ整合となり、どちらであったかがログに残ります。
バグ修正
- 完了した移行に完了時刻が表示されます。 成功した移行は緑のバッジの横に「Completed at: In Progress」と表示され、中止された移行は終了時刻をまったく記録していませんでした。
- 長い転送が停滞と誤認されなくなりました。 問題なくコピー中の大きなディスクが、完了の数分前に失敗扱いされることがありました。
- warm 移行は移行元ゲストのリソースを返します。 失敗または中止された warm 移行は、稼働中の移行元ゲスト内にブロックデバイスを登録したまま残し、それが同じディスクに対する以後のすべての試行を妨げていました。解消する手段はゲストの再起動だけで、それこそ warm 移行が避けるために存在するものでした。
- 移行された VM はゲストが前提とするディスクバスを保ちます。 そのため、ブートイメージにストレージドライバを 1 つしか持たないゲストでも root ディスクを見つけられます。
- 移行一覧が実際の移行元を表示します。 実際の出所にかかわらず、すべての移行が VMware 由来として表示されていました。
更新の前に
- Cockpit フリートへの warm 移行には、移行先側に Awanio Vapor 3.0.1 以降 と Awanio Cockpit 3.0.1 以降 が必要です。
- ファイアウォール規則を計画する前に 何がどこへ到達する必要があるか を確認してください。ディスクを運ぶのがどのマシンかは移行元・移行先・方式によって異なり、それが必要な規則を決めます。
- 本リリースには既存のデプロイの挙動を変える要素はありません。
CONDENSA_TARGET_WARM_ADDRESSは任意で、既定値は従来の Condensa の動作と同じです。
バージョン 1.3.2 (2026年 7月)
移行の動作には変更のないメンテナンスリリースです。Condensa の更新を配信するための公開フローを修正します。
バージョン 1.3.1 (2026年 7月)
大容量・複数ディスク・長時間実行の VM に対する VMware 移行の信頼性向上リリースです。
バグ修正
- 複数ディスクの BIOS VM が手動修正なしで起動します: 複数のディスクを持つ移行済み VM (レガシー/BIOS ブート) がそのまま起動するようになりました。オペレーティングシステムのディスクが自動的に先頭へ配置されるため、移行後にブート順を手で直す必要はありません。
- 長時間の移行でも接続が維持されます: 長時間にわたる移行 — 大容量ディスク、あるいは warm 転送 — が終盤で「session is not authenticated」エラーにより失敗することはなくなりました。VMware への接続は維持され、必要に応じて張り直されるため、最終的な切り替えが確実に完了します。(cold 移行は影響を受けていませんでした。)