Condensa リリースノート
このログは Condensa の更新、新機能、バグ修正を記録します。
バージョン 1.9.4 (2026年 10月)
VMware の VM を選択すると、同じ BIOS UUID を持つ別の VM があっても、必ずその VM が選択されるようになりました。
- 同じ BIOS UUID を持つ 2 つの VM が 1 つとして表示されなくなりました。 vSphere でコピーした VM は、コピー元の BIOS UUID を引き継ぐことがあります。これまでのすべてのバージョンでは、そのような 2 つの VM のどちらかを選ぶと両方にチェックが入り、移行では vCenter が返した方の VM が使われたため、一方を移行できませんでした。現在の Condensa は、vSphere が一意に保つ instance UUID で各 VMware VM を識別します。
- BIOS UUID を共有する VM は Awanio CEP へ移行できません。 CEP のディスクインポーターは BIOS UUID で VM を探すため、こうした VM を区別できません。ウィザードはその VM に Duplicate BIOS UUID と表示し、同じ BIOS UUID を持つ VM の名前を示します。vSphere でどちらかに新しい BIOS UUID を設定するか、Vapor または Cockpit ターゲットへ移行してください。
- 以前のバージョンで作成した移行は、アップデート後も動作します。 その移行の VM が別の VM と BIOS UUID を共有している場合は、どちらかで開始する代わりに両方の名前を示して拒否されます。移行を作成し直してください。
バージョン 1.9.3 (2026年 10月)
Condensa がソースの電源を切った後に移行が止まった場合、ワークロードが元に戻るようになりました。
- 移行が完了しなかった場合、ソース VM の電源が再び入るようになりました。 これまでのすべてのバージョンでは、カットオーバー時に失敗またはキャンセルされた VMware のウォーム移行はソース VM の電源を切ったままにし、Awanio CEP からの移行も同様にソースのゲストを停止したままにしていました。そのため、誰かが手動で起動するまで、ワークロードは両側で停止していました。現在は、ターゲット VM がまだ要求されていなければ、Condensa がソースの電源を入れ直し、そのことを移行ログに記録します。Condensa の再起動で中断された移行も対象です。手動カットオーバーのためにご自身でシャットダウンしたソースや、最初から電源が切れていたソースは、そのままです。
- ターゲット VM が要求された後は、ソースは停止したままです。 コピーがすでにターゲットに存在する可能性があり、1 つのゲストのコピーを 2 つ同時に動かしてはならないためです。移行ログはソースを停止したままにしたことを記録し、ソースを起動する前にターゲットを確認して、そこにあるコピーを削除するよう案内します。
- ウォーム移行をキャンセルしても、ソース VM に Condensa のチェックポイントが残らなくなりました。 キャンセルすると
condensa-warm-*スナップショットがすべて残っていましたが、現在は他の終了時と同様に削除されます。 - Awanio CEP からの移行をキャンセルすると、ソースサイトのエクスポートが閉じられます。 これまではキャンセル後も、エクスポートとそのダウンロードトークンが何時間も有効なままでした。現在は、ターゲットが読み取りを終えた時点で閉じられます。
バージョン 1.9.2 (2026年 9月)
各 VM に何が起きるかを決める設定が 1 つのステップにまとまり、レビューが変更内容を表示するようになりました。
- 移行をキャンセルしても、移行済みの VM が削除されなくなりました。 これまでのすべてのバージョンでは、バッチを途中でキャンセルすると、Awanio CEP 上で移行が完了していた VM のディスク（PVC）も削除され、それらの VM がストレージを失っていました。現在のキャンセルは処理中の VM のみを停止し、完了済みの VM はディスクを保持します。移行ログには保持された VM の数が記録されます。一部の VM が移行済みのバッチをキャンセルする前に、アップデートしてください。
- レビューが VM ごとの変更をすべて示します。 変更が New MAC address、default network の無効化、default route、固定アドレス、VPC のいずれかだけだった VM は
vm-demo —と表示され、ダッシュの後に何もありませんでした。現在はいずれも説明され、ダッシュは示すものがあるときだけ表示されます。 - Power on the VM after migration が Mapping ステップに移動しました。 これは移行内のすべての VM に対する既定値で、これが適用される VM ごとのスイッチも同じステップにあります。ヘルプ文自体が、そこで個別に変更するよう案内していました。Basic Info は移行先だけを扱うようになりました（プロバイダー、ホスト、ストレージプール、組織、プロジェクト）。
- Manual cutover が移行全体の設定になりました。 Vapor と Cockpit のターゲットでは、VM のカードを 1 つずつ開かずに一度指定できます。warm 移行は移行元を自分で停止せず、各ゲストを OS 内からシャットダウンするのを待ちます。cold 移行には影響しません。
- 停止した移行の編集で、この 2 つの既定値を変更できます。 power と cutover の既定値は、編集しても黙って破棄される唯一の Mapping 設定でした。
- マッピングする対象がないゲストにもインターフェースを与えられます。 ターゲットネットワークはソースのインターフェースごとに接続されるため、唯一のインターフェースが移行元の pod ネットワークであるゲスト、またはインターフェースを持たないゲストはそこへ到達できず、理由も示されないまま pod ネットワークだけで起動していました。Mapping ステップの各カードに Attach an interface on が追加され、与えるターゲットネットワークを指定できます。指定しない限り何も追加されません（VM ごと）。
- VM に複数の追加インターフェースを与えられ、それぞれに固有のアドレスと default route を設定できます。 Attach an interface on では、サイト自身の Create Network ダイアログと同様に、ネットワークの種類、ネットワーク、任意の IP アドレス、Set as default route の順に指定します。その VM で既に使われているネットワークは再度表示されず、default route を持てるのは VM ごとに 1 つのインターフェースだけです。
- そうしたゲストに既定ネットワークを強制しなくなりました。 以前は Create default network を戻さない限り先へ進めませんでしたが、同じカードには「ネットワークなしで到着することは許容され、後からターゲット側で接続できる」と正しく書かれていました。
- ディスクを取得できない移行は、いつまでも実行中のままにならず失敗するようになりました。 移行元がディスクのダウンロードを 3 回のインポーター再試行すべてで拒否した場合（401、403、404、410）、または移行元のエクスポート期間が終了した場合、移行は Running のままとなり、ターゲットでインポーターが際限なく再試行していました。現在は移行元の名前と対処方法を示す理由とともに失敗し、途中までインポートされたディスクをターゲットから削除します。遅い、または一時的に到達できない移行元は引き続き再試行されます。 Condensa の再起動で中断された移行も、途中までインポートされたディスクをターゲットから削除するようになり、インポーターが動き続けることはなくなりました。
- 保存済みの SSL thumbprint がホストと一致しなくなった VMware プロバイダーを、転送前に検出するようになりました。 ESXi の再インストールやアップグレードでホスト証明書が再生成されると、スナップショット・変更追跡・VM 一覧は動き続けるのに、VDDK 転送はすべて
VixDiskLib_Open: … Unknown errorで失敗していました。ディスクを開く前に thumbprint をホストが提示する証明書と比較するようになりました。Allow insecure connection が有効なら現在のホストの thumbprint を使い、保存値が古いことを移行ログに記録します。無効なら何も作成する前に移行を停止し、両方の値と新しい証明書の有効開始日を示します。プロバイダーの Test Connection も同じ不一致を報告するため、証明書の差し替えはディスク失敗ではなく Providers ページで見つかります。 - Keep the final snapshot on the source VM を VM ごとに指定できるようになりました。 Mapping の既定値の中で唯一 VM 単位のスイッチがなく、バッチ内の全ゲストで復元ポイントを残すか、どれも残さないかしか選べませんでした。各 VM のカードにスイッチが付き、Review は異なる設定の VM を示し、Edit and retry で移行を開き直したときもこのオプションが表示されます（以前は表示されませんでした）。残されるのは Condensa が作成したチェックポイントだけで、Condensa 以外が作成したスナップショットには触れません。
- warm か cold かは、移行を作成した時点ではなく開始時点の電源状態で決まるようになりました。 ゲスト停止中に準備し、ゲスト起動後に開始した移行は cold 経路に入り、起動中のゲストが開いているディスクで失敗していました。開始時に移行元（VMware と Proxmox）へ問い合わせ、記録と異なれば移行ログに記し、移行元に到達できない場合は記録された状態を使います。
- Select VMs ステップに Refresh list ボタンが付きました。 ウィザードを開いている間にゲストの起動・停止や変更追跡の有効化があっても、以前はダイアログを閉じてすべて入力し直す必要がありました。一覧をその場で読み直し、選択は保持されます。
- 開始待ちの移行をそのページから開始できます。 Migration Details のステータスカードに Start Migration ボタンが付き、行の Actions メニューに戻る必要がなくなりました。拒否された場合はボタンの下に表示されます。
- 待機中のディスクが移行の進捗を「size unknown」にしなくなりました。 VM の最初のディスクをコピー中、後ろで待つディスクが測定不能と数えられ、進行中のディスクが割合を報告していても移行バーに割合が出ませんでした。
- ターゲットに収まらないディスクは、何度もコピーされ続けず移行が失敗するようになりました。 ターゲットのストレージの空き容量がディスクより小さい場合（ストレージのクォータや上限など）、インポーターはディスク全体を 100% までコピーしてから 0% に戻ってやり直し、移行は何時間も Running のままでした。現在はディスクのサイズとターゲットの空き容量を示して失敗し、途中までインポートされたディスクを削除します。ターゲットの上限を引き上げるか空き容量を確保してから、移行を再度開始してください。
既定ネットワークを無効にするには Awanio CEP 3.9.0 以降が必要です
Awanio CEP への移行で Create default network をオフにするには、CEP 3.9.0 以降（CEP ダッシュボードのサイドメニュー下部に表示されるバージョン）が必要です。それより前の CEP では既定ネットワークが接続されたままとなり、移行ログにその旨が記録されます。追加インターフェースとネットワークのマッピングは以前のバージョンでも動作します。
Mapping ステップに移行全体の Target Network はなくなりました
各 VM のインターフェースは、その VM のカードでマッピングします。マッピングしないインターフェースは作成されず、カードにその旨が表示されます。1 つのソースネットワークをすべての VM で同じ場所に送るには、カードの上にある Per-network mapping を使います。1.9.2 より前に Target Network 付きで保存された移行はその設定を保持し、編集で開くと各 VM のインターフェースにそのネットワークが表示されます。
バージョン 1.9.1 (2026年 9月)
移行ウィザードが VM を移行できない理由を表示するようになり、CEP ターゲットでは移行後の VM を停止したままにできるようになりました。
- 移行できない VM は、その行の下に理由を表示します。 CBT が無効でスナップショットのない稼働中の VMware VM は選択できませんでしたが、行には Warm バッジが表示され、理由はツールチップにしかありませんでした。現在は Needs CBT と表示され、行の下に理由（CBT を有効にするか、VM の電源を切る）が表示されます。
- vCenter がサイズを報告しないディスクについて説明します。 そのような VM は
0 GBと表示され、1.9.0 以降は理由が示されないまま移行が拒否されていました。ウィザードは VM のファイル構成から判明した原因（例: 0 バイトのディスク記述子ファイル）を、ファイルのパスとデータファイルのサイズとともに表示し、VM を Unreadable disk とマークします。修正は vSphere 側で行います。ディスクを修復または置き換えてから、一覧を再読み込みしてください。 - CEP ターゲット: 移行後に VM の電源を入れるかを選択できます。 Awanio CEP に移行した VM はすべて自動的に起動されていました。Vapor と Cockpit のターゲットで提供されていた Power on the VM after migration が CEP でも使えるようになりました。移行全体の既定値として、また Mapping ステップで VM ごとに設定できます。
- プロバイダーの VM を表示できます。 プロバイダーのカードをクリックすると、その詳細と保持している VM（VMware はデータセンターごと、Proxmox、Awanio CEP、OVA/VHD アップロード、Vapor、Cockpit）が、ステータス、vCPU、メモリ、ストレージ、IP アドレス、OS（プロバイダーが報告する範囲で）とともに表示されます。管理者はそこからプロバイダーを編集し、Back で戻ることができます。
- プロバイダーの編集時に、シークレットを再入力せずに Test Connection を実行できます。 1.1.5 以降、保存済みの値を保持するためにフォームの案内どおりパスワード、アクセスシークレット、API トークンを空欄にすると、Test Connection は何もテストせずに
vendor vapor requires an API tokenなどのメッセージで失敗していました。現在は保存済みのシークレットでテストします。プロバイダーのアドレスまたはアカウントを変更した場合は、シークレットを再入力してください。保存済みのシークレットが別のサーバーに送られることはありません。 - Vapor ターゲット: 既に使用されている VM 名を転送前に検出します。 移行先の VM 名が Vapor ホストで既に使われている場合、ディスク転送をすべて実行した後で VM の作成に失敗していました。現在は転送前に停止し、該当する VM 名を示して、名前の変更または既存 VM の削除を求めます。
プロバイダーのカードをクリックしても編集フォームは開かなくなりました
カードをクリックするとプロバイダーの詳細が開きます。プロバイダーを変更するには、カードまたは詳細画面の Edit を使用してください。
バージョン 1.9.0 (2026年 9月)
正しく実行できない移行は、始まってから遠い場所で失敗するのではなく、始まる前に停止するようになりました。 本リリースで修正された 4 つの失敗は、運用者にはそれぞれ別の問題に見えていました。容量が空と表示されるディスク、拒否されるインポート、ディスク名を含まない接続エラー — いずれも原因から遠く離れた場所で終わっていました。これらは発生した場所で、VM 名とディスク名を添えて報告されます。
- ディスク容量は vSphere が実際に設定するフィールドから読み取られます。 ソース側で 100 GB あるディスクが、VM 選択画面で
0 GBと表示されることがありました。容量を、VMware が vSphere 5.5 以降で非推奨とし、常には設定しなくなったフィールドから読んでいたためです。 - 容量を読み取れないディスクは、名前を挙げて拒否されます。 従来そのようなディスクには 1 GiB の移行先ボリュームが割り当てられていました。大きなディスクではインポートが容量に触れないままインポーター内部で失敗し、小さなディスクでは完了してしまい、移行したはずのものとは別のディスクを持つゲストが手元に残りかねませんでした。
- 完成したボリュームは、インポート成功として記録される前に移行元ディスクと照合されます。 明確に小さい場合、そのディスクは成功ではなく失敗として、両方の容量を添えて報告されます。誰も対処できない「成功」を残しません。
- VMware インポートに必要な SSL サムプリントは、処理開始前に解決されます。 従来は
spec.source.VDDK source VDDK is not validで失敗していました。問題のフィールドもプロバイダーも示さず、しかも移行が始まって再試行したあとにようやく現れるメッセージです。insecure と指定されたプロバイダーはホストからサムプリントを読み取り、検証を前提とするプロバイダーは名前を挙げて拒否され、値を取得できるエンドポイントも示されます。 - スナップショットや旧形式のディスクも検出されます。 スナップショットのデルタ (SEsparse) や旧来の sparse / flat 形式を使うディスクはパスが読み取れず、インポートが
server has no export named ''で失敗していました。VM 名もディスク名もファイル名も含まないメッセージです。現在はファイルベースのディスクを形式によらず読み取ります。 - ネットワーク障害が「どちらのネットワークか」を示します。 ディスクインポーターは移行先クラスター内で動作し、クラスターの DNS で名前を解決し、クラスターのネットワークから接続します。したがって Condensa から到達できる移行元 — 接続テストに成功したばかりのものを含め — がそこからは到達できないことがあり得ます。そうした障害はその旨を述べ、名前が解決しなかった場合と、エンドポイントが応答しなかった場合を区別します。
これまで開始できた移行が拒否される場合があります
これは意図した動作です。容量や場所を正しく決められない移行が、従来は開始され、実行され、下流のどこかで失敗していました。最悪の場合は移行元より小さいディスクのまま完了していました。現在は、VM とディスクをまだ名指しできる時点で拒否されます。
以前は実行できた移行が拒否された場合、メッセージが VM 名とディスク名を示します。まず移行元 VM を再スキャンしてください。容量とパスは毎回読み直され、その読み取り自体が本リリースの修正対象です。
インポーターが成功と報告したインポートが、失敗として記録される場合があります。 積極的な根拠がある場合に限ります。すなわち両方の容量が判明しており、ボリュームが移行元ディスクより小さい場合です。容量が単に不明な場合、Condensa はその旨を述べるだけで、欠けている情報をどちらの判定にも変えません。
プラットフォームの migration-disk API 経由のインポートは、まだ容量を照合できません
このインターフェースはボリューム容量を報告しないため、その経路のインポートは引き続きインポーターの報告に基づいて受け入れられます。Condensa がこれを伝えるのは、移行元の容量も不明な場合だけです。つまり、そのディスクがどれだけの大きさであるべきかを誰も確定していない場合であり、確認できるのは運用者だけになります。
バージョン 1.8.1 (2026年 9月)
更新チェックが「確認できなかった」を「最新である」と取り違えなくなりました。 ソースからビルドした環境は 1.8.0+g94ca213 のようなバージョンを報告します。この末尾はビルドメタデータであり、バージョン番号の正当な一部で、どちらのリリースが新しいかを判断する際には無視すべきだと規格が定めているものです。Condensa はそれを無視するどころか、バージョンそのものを読み取れず、何も比較しないまま 「Condensa is up to date — you are on the newest published release」 と報告していました。ポータルにはより新しいリリースがあったにもかかわらずです。
- ビルドメタデータを伴うバージョンが正しく読み取られ、そうした環境も他と同じように更新を提示されます。
- プレリリース版 —
1.8.0-rc1— は、それが至るリリースより下位に位置づけられるようになりました。 - バージョンをどうしても読み取れない場合、ダイアログはその旨を述べ、比較できなかったバージョン名を示します。良い知らせとして報告することはありません。行われなかったチェックが、問題なしの結果として提示されることはなくなりました。
エンタープライズポータルから入手した環境は、そもそも影響を受けていません。 それらは素のバージョン番号を報告し、比較は常に正しく行われていました。この修正が届くのはソースからビルドした環境であり、それはエアギャップ環境が自前でビルドする方法でもあります。
1.8.0+g94ca213 のようなバージョンを表示している環境は、一度だけ手動で更新してください
このリリースは、そうした環境へ自力では届きません。まさにこのリリースが直している理由で止まっているため、このリリースもまた提示されないからです。一度だけ手動で更新すれば、以後は自動更新が機能します。
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再設定は一切行われません。プロバイダー、認証情報、移行履歴、二つのシークレットはそのまま残ります。完了後にバージョンを確認してください。condensa -version が素の 1.8.1 を出力するはずです。
バージョン 1.8.0 (2026年 9月)
ウォームマイグレーションに、最後のスナップショットを移行元 VM へ残すよう指示できるようになりました。 ウォームマイグレーションが VMware の移行元で取るチェックポイントはすべて自身のものであり、終了時にすべて削除されます。それが正しい既定です — VMware のスナップショットは存在する限りデルタディスクを肥大させます — が、あとで移行先が誤りだったと分かったときに戻る先が何も残りません。
- 移行元 VM に最後のスナップショットを残す。既定は無効で、VMware を移行元とする場合の Mapping ステップにあります。最後のチェックポイントが、移行先を構築した状態そのものへの復元ポイントとして残ります。
- このスナップショットは
condensa-migrated-<日付>-<移行名>に改名されます。これは飾りではなく機能の核心です。Condensa はウォーム実行のたびに、その冒頭でcondensa-warm-*という名前のものをすべて消去します。そのため、その名前のまま残したスナップショットは、同じ VM の次の移行で削除されてしまいます。改名されたそれは、あなたのものです。 - 複製中に取られたチェックポイントは従来どおり削除されます。それらは残り物ではなくウォームマイグレーションの仕組みそのものであり、残せば利用者に応答し続けている VM にデルタディスクを積み重ねることになります。
- 実行が VM を生み出さなかった場合、何も残りません。着地しなかった移行のチェックポイントは復元ポイントではありません。
- その代償を引き受けるのはあなたです。 残したスナップショットは、削除するまでデルタディスクを肥大させ続けます。忘れられたスナップショットはデータストア枯渇のよく知られた原因です。移行ログは残したスナップショットの名前を再掲するので、後から見つけられます。
Condensa が作成していないスナップショットは、どちらを選んでも変わらず一切触れられません。コールドマイグレーションはそもそもスナップショットを取りません。
移行先と、その手前のフリートのリリースが食い違っていても、転送が止まらなくなりました。 ホストがダウンロードジョブを発行できるほど新しい一方で、それを中継するフリートにそのジョブを問い合わせられない場合、Condensa はそれでもジョブを追い続け、試行のたびに応答を得られず、実際には何も問題が起きていないのに停滞タイマーによって転送を失敗させていました。現在は、そうしたダウンロードをジョブ ID が存在しなかった頃と同じ方法で監視します。今日動作している組み合わせは何も変わりません。
バージョン 1.7.0 (2026年 9月)
移行したディスクは、ゲスト名を冠した専用ディレクトリに置かれるようになりました。 これまでディスクは、それを作成した移行の名前を持つ平置きのファイルとして着地していました — condensa-m119-vm123-disk0.qcow2。複数の移行を収めたデータストアは移行番号の一覧にしか見えず、どの VM がどれを所有しているかはストレージ側からは分かりませんでした。ウィザードで VM の名前を変更しても、そのディスクは古い名前のまま残っていました。
- 各ゲストに自身の名前を冠したディレクトリが作られ、その中のディスクにもゲスト名が付きます:
/pool/centos-7/centos-7-disk0.qcow2。 - 名前は 移行先 の名前に従うため、Mapping ステップで VM の名前を変更すると、そのディレクトリと中のすべてのディスクの名前も変わります。
- ゲストのディスクをディレクトリに収められない移行先は、従来どおりの平置きの名前のまま、これまでと全く同じように移行します。事前に何かを更新する必要はなく、移行先が対応した時点でディレクトリ命名は自動的に有効になります。
Condensa が移行できない移行元と移行先の組み合わせは、フォームの時点で拒否されます。 これまでは選択できてしまい、移行は途中まで進んでから、選んだものとは無関係なハイパーバイザーについてのメッセージで失敗していました — Vapor ホストに向けた Awanio CEP の移行元が、あるプロバイダーは VMware プロバイダーではないと報告していたのです。
- ウィザードは、処理を始める前に、その移行元が実際に到達できる移行先を提示します。
- Awanio CEP の移行元が到達できるのは Awanio CEP の移行先です。他の移行元は他の移行先に到達します。
Condensa からディスクをダウンロードする移行先に、Condensa 自身の認証局が渡されます。 Condensa がプライベート証明書を提示している環境では、このダウンロードは unknown authority エラーで失敗し、唯一の解決策はすべての移行先ホストに手作業で CA を導入することでした。
- Condensa はダウンロード要求と一緒に自身の CA を送ります。移行先ホストには何も変更を加えず、証明書の検証もそのまま行われます。
移行先が Condensa に接続すべきアドレスが、プロバイダーの設定項目になりました。 以前はサーバー側から推測していました。移行先が運用者とは異なるアドレスで Condensa に到達するサイトでは、それを訂正するためにサーバーの環境変数が必要でした。
- 移行先プロバイダーのフォームに Disk stream address の項目があります。空のままなら、従来の動作から変わりません。
Awanio CEP サイトへの移行が、ゲストのより多くの要素を引き継ぐようになりました。
- Mapping ステップが、移行元のインターフェースを移行先サイトのネットワークに対応付けます。VM ごとに異なる場合は VM 単位で指定でき、自由入力ではなく検索できる一覧から選びます。
- MAC アドレスは、サイトが保持できる場合には保持され、そのアドレスをサイトが既に使用している場合には要求されません。移行は、想定ではなく実際に返ってきた答えを報告します。
- ゲストは移行元のホスト名とタグ、root アクセス、SSH ホストキーを保ちます。
- Pod ネットワークを辞退し、デフォルトルートを対応付けたネットワークへ移せます。
- 移行元にネットワークが無かったゲストも、そのまま着地します。移行はどの移行先でもその事実を伝え、処理を止めません。
- プライベート証明書を持つ CEP 移行元は、移行先プロバイダー上で自身の CA を指定します。証明書の確認は、開始後の失敗としてではなく Review ステップで開始前に表示されます。
細かな変更
- 失敗した移行は、再実行の前に編集できます。最初から作り直す必要はありません。
- ディスクが失敗した VM は、そのディスクの理由とともに失敗として記録されます。
- ログイン画面にバージョンが表示され、サインイン前に何を見ているのか分かるようになりました。
バージョン 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 移行は影響を受けていませんでした。)