ZimaSpace
ストア

ZimaOS仮想マシン機能の今後

ZimaOS仮想マシン機能の今後

より簡単なイメージのインポート、より安全なネットワーク、ディスクスナップショット、バックアップ、そしてそれらを支える信頼性向上の取り組みについて紹介する開発プレビューです。

開発プレビュー： これはリリースの発表でも、提供時期の確約でもありません。検証中、プロトタイプ、調査と記載された機能は、ZimaOSの公開ビルドに導入されるまでに変更される場合があります。また、利用可否はZimaOSパッケージのロールアウト、ホストハードウェア、ゲストOS、ストレージやネットワークの構成によっても異なります。

ZVM Nextの4つの作業領域である、イメージのインポート、ネットワーク、リカバリー、互換性。

4つの作業領域は、それぞれ異なる速度で進んでいます。本記事のステータスラベルが常に正しい最新情報です。

コンテナに最適なワークロードもあれば、オペレーティングシステム全体を必要とするものもあります。

Windows専用ユーティリティ。Home Assistantアプライアンス。隔離されたLinuxテストマシン。ネットワークのほかの部分に影響を与えず、何度でも再構築できるルーターラボ。こうした用途でこそ、ホームサーバー上のVMが真価を発揮します。

ZVMは、ZimaOSでこの体験を支える仮想マシンサービスです。VMを作成して実行するための基盤はすでに提供していますが、改善が必要な点もコミュニティから寄せられています。既存ディスクイメージのインポートには、今も手作業が多すぎます。ブリッジネットワークは誤解を招きやすい機能です。自動起動、スナップショット、バックアップ、リカバリーには、もっと明確な安全策が必要です。また、処理が失敗したときには、単に問題が発生したと伝えるのではなく、解決に役立つメッセージを表示すべきです。

私たちはそうした報告をもとに、ZVMの方向性をさらに絞り込んできました。ここでは、現在強化しているもの、実際に検証しているもの、まだ調査段階にあるものを紹介します。

ステータス一覧

ステータス 意味 現在の例
アルファ版の基盤 コードは現在のアルファ版系列に含まれていますが、各デバイスでの利用可否は引き続きZimaOSパッケージのロールアウト状況によって異なります。 ブラウザベースのVMコンソール経路に対する認証の強化。
検証中 主な実装は存在しますが、互換性テストとアップグレードテストを続けています。 イメージの直接インポート、段階的な変換、整合性チェック、失敗時のクリーンアップ。
プロトタイプ 設計はコードとテストで動作していますが、挙動とUIは今後も変更される場合があります。 複数モードのネットワーク、安全策を備えたブリッジ変更、自動起動イベント、ディスクスナップショット、フルバックアップの作成。
調査 検討している方向性であり、リリースを確約した機能ではありません。 USB、PCIe、GPU、物理NICのパススルー、増分バックアップ、より広範な移行ワークフロー。

これらのラベルは意図的に使い分けています。開発ブランチやプロトタイプに機能が含まれていても、本番環境のVMで使用できる段階に達したことにはなりません。

手元にあるイメージをインポート

多くのセルフホスト型プロジェクトでは、インストーラーではなく、すぐに実行できる仮想ディスクを公開しています。そのイメージをVMに取り込むには、手作業で変換し、正しいディレクトリに移動してから、新しいマシンに接続しなければならないことがあります。

私たちが目指す体験は、もっとシンプルです。イメージとVMの保存先を選ぶだけで、準備はZVMが処理します。

最初の互換性対象は次の形式です。

  • ISOインストールメディア
  • QCOW2
  • VDI
  • VMDK
  • rawまたはIMGディスク
  • OVFメタデータを含むOVAパッケージ

ソースの選択から内容の検出、検証、準備、アトミックな確定処理までを示すZVMイメージインポートフロー。

どの処理経路でも、最終的には検証済みでVMが使用できるコピーになるか、クリーンアップ処理が行われます。未完成のディスクが使用可能として表示されることはありません。

ある形式をサポートするには、ファイル名の拡張子を信用するだけでは不十分です。ZVMは内容を調べてイメージを検証し、VM用に選択したストレージの場所へコピーまたは変換します。ISO以外のディスクはデフォルトでQCOW2になり、rawは上級者向けのオプションとして残ります。完成したVMは管理対象のコピーを参照するため、元のアップロードファイルやダウンロードファイルを削除してもVMが壊れることはありません。

インポートパイプラインは、成功時と同じ慎重さで失敗時の動作も設計しています。

  1. ソースを完成したディスクとして扱わず、ステージングします。
  2. 実際の形式を検出し、未対応または破損したイメージを拒否します。
  3. 任意のSHA-256値を確認します。
  4. OVAアーカイブを検査し、パストラバーサルや安全でないエントリーを拒否します。
  5. 一時的な.partialファイルにコピーまたは変換します。
  6. 同期と検証を行い、完成したイメージの名前をアトミックに変更します。
  7. キャンセルまたは失敗した場合は一時データを削除します。

可能な場合、この処理ではスパースディスクの動作も維持します。仮想容量が大きなディスクでも、すぐに同じ容量の物理ストレージを消費することはありません。

長期的なUIの目標は、ローカルからのアップロード、ZimaOS Filesで選択したパス、URLからのダウンロード、組み込みのシステムテンプレートを、同じVM構成フローにまとめることです。この段階で扱うのは、VM用イメージのインポートです。独立したイメージライブラリではなく、VMのエクスポートも含みません。

ステータス：検証中。 イメージを直接インポートするバックエンドと回帰テストはすでに存在し、appliance-1.2.3.qcow2のようにバージョンを含む名前の修正も含まれています。デバイス、イメージ、ゲストOSについて、さらに広範な検証が必要です。

ネットワークは用語テストではなく、選択肢であるべき

仮想ネットワークの各モードは、フォーム上ではほとんど同じに見えても、実際のネットワーク上ではまったく異なる動作をします。ZVMは、保存ボタンを押す前にその違いを説明すべきです。

ネットワークのプロトタイプでは、各仮想NICに明示的なモードを設定します。

  • NAT：外部へのアクセスが可能な、シンプルなプライベートネットワーク向け。
  • Linux bridge：VMをLANに直接接続し、ホストとも通信させる場合に使用。
  • macvtap：より直接的な接続向け。通常はホストからゲストへの通信が利用できないことを明確に警告。
  • 切断：隔離されたラボ、または後から接続するNIC向け。

NAT、Linux bridge、macvtap、切断されたVMネットワークを比較する4枚のトポロジーカード。

設定フォームでは似たラベルに見えても、ホスト、VM、LANの通信方法は同じではありません。

製品としての目標は、VMごとに1-8個のNICを個別に構成できるようにすることです。NATの計画には、DHCP予約とTCPまたはUDPのポートフォワーディングも含まれます。ホストポートが重複している、またはすでに使用中の場合、ZVMは別のルールを黙って置き換えるのではなく、競合を報告すべきです。

ヘッドレスのホームサーバーでブリッジを変更する場合は、特に注意が必要です。ZimaOSの管理接続に使っている物理インターフェースを移動すると、その変更に使用しているブラウザ自体が切断される可能性があります。プロトタイプでは、この操作をトランザクションとして扱います。提案された構成を確認し、適用して接続状態を監視し、新しい経路が正常にならなければロールバックします。

シャットダウンが必要な変更についても、同じように正確に伝えるべきです。ホストまたはゲストがNICを安全にホットプラグできない場合、ZVMは要求された構成を保存して再起動待ちとして表示し、稼働中のVMにすでに反映されたかのように見せないようにします。

ステータス：プロトタイプ。 明示的なインターフェースモード、インターフェースAPI、永続的なNATポリシー、フォワーディングルール、静的ネットワークのシーディング、安全策を備えたLinuxブリッジ変更については、ブランチ上で動作する実装があります。ハードウェアとアップグレードの検証マトリクスは未完成です。

スナップショットとバックアップは別物

スナップショットは、元データの近くに置くロールバックポイントです。バックアップは、元のVMやストレージに問題が起きても残るようにする独立したコピーです。両方を曖昧な1つのボタンにまとめると、リカバリーは簡単になるどころか難しくなります。

ディスクのみのスナップショットと、独立したフルバックアップバンドルを横並びで比較した図。

スナップショットとバックアップは、それぞれ異なる問題を解決します。バックアップからの復元は、今後のマイルストーンです。

ローカルロールバック用のディスクスナップショット

最初のスナップショット設計はディスクのみを対象とします。RAMは取得せず、アプリケーションが停止した命令位置そのものから再開することもできません。

電源を切ったQCOW2 VMの場合、ZVMは安定したディスクを直接コピーできます。稼働中のVMの場合、プロトタイプは一時的な外部オーバーレイを作成して特定時点のディスクビューを確立し、安定したベースをコピーします。その後、コミットして、アクティブディスクを元のパスに戻します。VMが、ZVMの管理するオーバーレイの伸び続けるチェーンに依存したままになることはありません。

デフォルトは、予期しない電源喪失後のディスク状態に近いクラッシュ整合性です。ゲスト上のQEMU Guest Agentが応答している場合、ZVMは静止状態での取得を選択できるようにし、スナップショットの前後でファイルシステムのフラッシュと凍結を行えるようにします。ZVMは、機能しない可能性のあるスイッチを表示するのではなく、その機能を実行時に確認します。

ディスクスナップショットを復元するには、VMをシャットダウンする必要があります。ディスクを置き換える前に、プロトタイプはリカバリージャーナルを書き込み、自動起動を一時的に管理します。複数ディスクの復元が中断された場合は、異なる時点のディスクが混在したVMを残すことなく、ロールバックできます。ライブ取得では空き容量も確認し、コピー中は一時オーバーレイを監視します。

独立したコピーを作るフルバックアップ

バックアップのプロトタイプは、ZimaOS Filesで選択した既存ディレクトリに.zvm-backupバンドルを作成します。非アクティブなVM構成、独立したQCOW2ディスクコピー、SHA-256チェックサム、ファイルサイズ、元のディスクマッピング、バージョン管理されたマニフェストを記録します。

保存先の安全性も機能の一部です。ZVMは昇格されたストレージアクセス権で動作するため、単純な文字列チェックに頼らず、オペレーティングシステムのパス、ZVMのメタデータ保存場所、シンボリックリンクを使った領域外への脱出を拒否します。

重要な制限： バックアップバンドルの作成と一覧表示は、現在のプロトタイプに含まれています。バックアップバンドルからVMを復元する機能は別のマイルストーンであり、利用可能だと想定してはいけません。また、ディスクスナップショットにはメモリ状態が含まれません。

ステータス：プロトタイプ。 API、サービス実装、中断ジャーナル、パスチェック、対象を絞ったテストは、開発中のコードに存在します。実際のlibvirt、電源喪失、容量不足、複数ディスクのテストは、引き続きリリース判定の必須条件です。

自動起動を謎のスイッチにしない

自動起動は、Home Assistant、ルーターVM、またはホストの再起動後に復帰すべきサービスに便利です。一方で、VMがまだ準備できていないストレージやネットワークに依存している場合は危険です。

現在の取り組みでは、既存の自動起動設定をAPIから確認できるようにし、変更時の成功または失敗イベントを記録します。より広範な設計では、起動優先度と設定可能な遅延を追加し、依存するVMを起動する前に、必要なホストリソースが準備されるまで待機します。

ステータス：プロトタイプ。 基本的な自動起動制御とイベント報告を現在検証しています。依存関係を考慮した順序付けと遅延は設計目標であり、完成した動作ではありません。

小さな修正も重要

アップグレード、コンソールセッション、失敗した処理によってVMが不明確な状態になるなら、新機能があっても役に立ちません。大規模な取り組みと並行して、目立ちにくい修正もいくつか進めています。

  • コンソールアクセスのセキュリティ： ブラウザベースのVNCプロキシは、現在のアルファ版コード系列で想定された認証経路に従うようになりました。各デバイスでの利用可否は、引き続きZimaOSパッケージのロールアウト状況に従います。
  • より安全な識別情報の処理： リクエストがローカルかどうかを判断する際に、クライアントが制御できる転送元アドレスを認証処理が信頼しないようになりました。
  • ドットを含むイメージ名： appliance-1.2.3.qcow2のようなファイル名は、誤って短縮されず、有用なバージョン情報を維持します。
  • キャンセルされたアップロード： イメージのアップロードが中断された場合、使用可能なファイルであるかのように残さず、部分ファイルを削除します。
  • 保存済み設定と稼働中の設定： ネットワーク関連の処理は永続的なVM定義を読み取り、稼働中の状態と保存済みの状態を混同せず、再起動待ちを表示できます。
  • ネットワークの整合： 重複するDHCP予約、フォワーディングの競合、部分的に適用されたホストネットワークポリシーに対して、明示的な検証とロールバックを重視した処理を行います。

ブラウザコンソールのバイナリフレーム、再接続ループ、キーボードの挙動、Windowsのインストール、GRUBの表示、アップグレード互換性など、ほかの報告も回帰テスト計画に残っています。調査中というだけで、すべてが修正済みになったわけではありません。

既存のVMはユーザーのものであり続けるべき

コミュニティのVMには、手作業で編集したXML、一般的でないデバイス、カスタムファームウェア、古いZimaOSリリースで作成した設定が含まれることがあります。1つのフィールドを変更するために定義全体を書き換えると、VMを便利にしているカスタマイズそのものが消える可能性があります。

ZVM Nextの設計では、追加的なアプローチを採用します。

  • 既存のVMを変更せずに検出します。
  • 要求された操作が所有するXMLノードだけを更新します。
  • UUID、既存のMACアドレス、ディスクパス、NVRAM、自動起動、変更対象外のデバイスを維持します。
  • 機能をライブで適用できるか、シャットダウンが必要か、明示的な変換が必要か、未対応かを説明します。
  • 新しい操作が失敗しても、それ以前の構成でVMを起動できなくなる事態を防ぎます。

安定版のリリース前に予定している回帰テストマトリクスでは、既存のWindows、Linux、Home Assistant OS、OpenWRTまたはpfSenseのVMを対象に、機能の利用、再起動、アップグレード、ロールバックの各シナリオを検証します。

パススルーは単なるチェックボックスではない

ハードウェアパススルーは、コミュニティから最も要望の多い機能の1つです。同時に、複雑さを隠しすぎると、危険な実装になりやすい機能の1つでもあります。

USBの割り当ては比較的限定できます。PCIeとGPUのパススルーは、IOMMUグループ、ファームウェア、ドライバーのバインド、デバイスのリセット動作、同じグループを共有するほかの要素に依存します。物理NICのパススルーによって、ZimaOS自体が必要とするインターフェースが失われる可能性もあります。チェックボックスだけで、互換性のないハードウェアを安全にすることはできません。

そのため、PCIe、GPU、物理NICのパススルーは引き続き調査／プレビュー段階です。公開プレビューには、互換性マトリクス、ホストへの影響に関する明確な警告、リカバリー手順、機能を個別に無効化する方法が必要です。

増分バックアップ、オンラインストレージ移行、ホスト間移行、クラスタリング、高可用性、分散ストレージ、RAMスナップショット、バックアップの重複排除も、現在の中核スコープには含まれません。

実際のワークロードのテストにご協力ください

最も有用なフィードバックは実際のワークロードから始まるため、アイデアだけでなく範囲の境界も共有しています。

次の情報をお寄せください。

  1. どのイメージ形式とアプライアンスをインポートしたいですか？
  2. NAT、真のLinuxブリッジ、macvtap、隔離された複数NICのラボのどれが必要ですか？
  3. QEMU Guest Agentがインストールされていない場合でも、クラッシュ整合性スナップショットは役立ちますか？
  4. フルバックアップの保存先として何を希望し、どのような空き容量保護を期待しますか？
  5. どのUSB、PCIe、GPU、NICデバイスをパススルーしたいですか？
  6. 現在、どのVMの不具合によって作業が妨げられていますか？

不具合を報告する際は、Zimaハードウェアまたはx86ホストのモデル、ZimaOSとZVMのバージョン、ゲストOS、VMのファームウェア形式、ディスク形式と保存場所、ネットワークモード、失敗した正確な操作、UIに表示された完全なエラーを含めてください。

ZimaSpace Communityでの議論にご参加ください。こうした詳細があれば、ほかのコミュニティメンバーやZimaチームが、報告内容を既知の事例と比較できます。

私たちの目標は、libvirtのすべてのスイッチをWebフォームに移すことではありません。ホームサーバーで重要なVMワークフローを理解しやすく、リカバリー可能にし、次回の再起動を安心して任せられるほど安全にすることです。

よくある質問

これらの機能はすべて現在利用できますか？

いいえ。ステータス表では、アルファ版の基盤、検証中、プロトタイプ、調査を区別しています。本記事は方向性の更新であり、リリースノートではありません。

スナップショットにはVMのメモリ状態が含まれますか？

現在の中核設計には含まれません。最初の実装ではディスクのみを取得します。稼働中VMのスナップショットはデフォルトでクラッシュ整合性となり、QEMU Guest Agentが利用できる場合はファイルシステムを静止させて取得できます。

すべてのOVA、VMDK、VDIイメージをインポートできますか？

これらの形式は互換性の対象ですが、実際のイメージにはさまざまな違いがあります。ファームウェア、アーキテクチャ、コントローラー、ドライバー、暗号化、破損、ベンダー固有のOVFメタデータによって、イメージに互換性がなくなる場合があります。ZVMは、起動できないVMを作成するのではなく、対処方法が分かる説明とともに未対応のケースを拒否すべきです。

バックアップからの復元はすでにサポートされていますか？

いいえ。現在のプロトタイプでは、フルバックアップバンドルを作成して一覧表示できます。それらのバンドルからの復元は、独立して明示的にテストするワークフローとして計画されています。

GPUパススルーはすべてのZimaデバイスで動作しますか？

いいえ。CPU、ファームウェア、IOMMUのグループ化、GPU、ホストドライバー、ゲストドライバー、リセット動作によって異なります。サポート対象のマトリクスとリカバリー手順が明確になるまでは、調査およびプレビューの領域です。