このスレッドは、ZVMユーザーが最も必要としていた仮想化機能をどのように定義したかを記録した有用な資料です。IceWhaleは、投票キャンペーンが進行中だった2024年5月に議論を開始しました。当初は、より多くのディスクイメージ形式、イメージへのアクセスの簡便化、他の仮想化プラットフォームからのインスタンスのインポート、LXCサポートに注目が集まりました。その後1年をかけて要望はより具体化し、QCOW2およびアプライアンスイメージ、PCI/GPUパススルー、VMの自動起動、高度なQEMU制御、ストレージ容量の拡張、オーディオパススルー、より詳細なエラー報告などが挙げられました。
この情報源は、現在の機能一覧ではなく、製品に対するフィードバックの履歴として読むべきです。このスレッドに要望が登場したからといって、現在もその機能が存在しないとは限りません。また、IceWhaleが「検討します」と返信していることも、リリースの約束を意味しません。
QCOW2、VDI、OVA、そして事前構築済みアプライアンスが初期の優先事項に
複数のユーザーが、ISOインストーラーに変換せずに事前構築済みの仮想アプライアンスを起動したいと求めました。Home Assistant OSは、一般的なインストール用ISOではなくVMイメージを配布しているため、繰り返し例として挙げられました。
これは「ISOをマウントする」こととは異なる要件です。インストール済みのディスクイメージにはすでにOSが含まれているため、VMの起動ディスクとして接続する必要があります。
Home Assistant OSによってイメージインポートの不足が明確に
複数の返信で、ZVM上でHAOSを実行したいという具体的な要望が寄せられました。その後、より新しいZVMバージョンでHAOSをVMとして実行できることがコミュニティによって確認され、2024年時点の制限を恒久的な現状として説明すべきでない理由が示されました。
PCIおよびGPUパススルーが2025年の主要な要望に
ゲーミングクラスのハードウェアを使用するユーザーは、WindowsやSteamOSのゲストで実GPUを使いたいと考えていました。あるRTX 2070ユーザーは、Windows 11と、予定していたSteamOSゲストの両方が、ゲストがソフトウェアグラフィックスに依存しているように見えるため動作が重いと述べました。
PCIパススルーには、IOMMU/VFIOのサポートと安全なデバイス分離が必要です。これは、エミュレートされたディスプレイ出力や準仮想化されたディスプレイ出力とは本質的に異なります。
VMの自動起動も実用的なサーバー要件に
DebianサーバーVMのユーザーは、ZimaOSの再起動後にインフラ用ゲストを復帰させるため、VMごとに自動起動を切り替えられる機能を求めました。IceWhaleはフィードバックを認識し、チームで検討すると回答しました。
常時稼働するホームサーバーでは、グラフィカルなVM作成よりも、起動順序や再起動後の復旧のほうが重要になることがよくあります。
上級ユーザーはQEMU/libvirtを直接制御したいと考えていた
別のユーザーは、カスタムQEMUコマンドとCockpit Machinesへのアクセスを求めました。目的には、オーディオパススルーの実験、より高いディスプレイ解像度、ストレージプールの容量をより簡単に拡張することなどが含まれていました。
Zima-Giorgioは実際に必要な権限について質問し、その後、ユースケースをチームで検討すると述べました。この情報源からは、ZVMのUIで任意のQEMUコマンドラインフラグを公開するという公式の約束は確認できません。
後のスクリーンショットからVMの起動と設定に関する問題が判明
ユーザーはダウンロードとエラーに関するフィードバックの改善も要望
2025年10月、新しいユーザーが、内蔵のDebian ISOダウンロードリンクは失敗したものの、手動で見つけたDebianのURLは機能したと報告しました。そのユーザーは、一般的なエラーを表示するだけでなく、どのURLが失敗したのかをZVMに表示してほしいと具体的に求めました。
これはハイパーバイザー自体とは別のユーザビリティ上の問題です。ZVMが実際に失敗したリソースやバックエンドのメッセージを表示すれば、トラブルシューティングは大幅に容易になります。
このスレッドを2026年の機能一覧として使用しない
ZVMは初期のフィードバックキャンペーン後も進化を続けており、現在ではコミュニティ拡張によって、内蔵のlibvirtレイヤーにスナップショット、自動起動、USB/PCIeパススルー、バックアップのエクスポート、メトリクスなどの機能が追加されています。そのため、2024年の要望の一部は、当初のインターフェースには存在しなかった場合でも、現在はコミュニティによる実用的な手段が提供されています。
現在、ZVMで特定のアプライアンスを実行できるか判断する際は、この過去の要望一覧だけに頼らず、現行ZVMのイメージ形式とデバイス制御を実際に確認してください。
LXCは当初の公式投票リストに含まれていた
IceWhaleの最初の投稿では、LXCサポートにすでに票が集まっていると明確に述べられていました。これは完全なKVM/QEMU仮想マシンとは異なる仮想化モデルです。LXC形式のシステムコンテナはホストのカーネルを共有しながら、よりVMに近いユーザー空間を提供します。
このスレッドには、IceWhaleがLXCをZVMの機能として提供したことを示す内容はありません。そのため、安全な歴史的説明は、LXCが要望された方向性だったということに限られます。
ユーザーが求めていたのは、単なる拡張子の追加ではなくアプライアンスのインポート
QCOW2、VDI、OVAへの対応要望は、実際には可搬性に関するものでした。ユーザーはすでにQNAP、Unraid、VMware、その他のハイパーバイザーで動作するアプライアンスを所有しており、インストールメディアから再構築せずにそれらのシステムをZVMへ移行したいと考えていました。
つまり重要なのは、形式のサポートだけでなく、ディスクバスの互換性、ファームウェアモード、ネットワーク設定、インポートしたVMのメタデータです。ファイル拡張子を認識できるだけでは、アプライアンスが正常に起動するとは限りません。
ディスプレイ解像度とオーディオパススルーも実用上の問題に
ある上級ユーザーは、Linuxゲストでより高いディスプレイ解像度を実現するためにQEMUオプションを試したいと考えていました。また、Windowsのオーディオパススルーは利用できないと以前説明されていたため、その機能も求めていました。さらに、より高機能なGUIを通じてストレージプールの容量を簡単に拡張したいとも考えていました。
これらの要望は、ZVMへのフィードバックがVMの作成だけに関するものではなかったことを示しています。ユーザーは、VMを作成した後のライフサイクルやデバイスも、より深く制御したいと考えていました。
このスレッドは初心者とパワーユーザーの優先事項を分けて考えるのに役立つ
一般ユーザーにとっては、イメージのインポート、明確なエラー表示、確実な起動、自動起動によって、利用時の負担が軽減されます。上級ユーザーにとっては、PCIパススルー、カスタムQEMU引数、ストレージ容量の拡張、LXC、libvirtへの直接アクセスのほうが重要です。
この違いは、現在のZVMを評価する際に役立ちます。単純なHome Assistantアプライアンスには不要な機能でも、GPUを使用するWindows VMやゲーミングVMには不可欠な場合があります。
ZVMフィードバックに関するFAQ
ユーザーはQCOW2サポートを求めましたか？
はい。QCOW2やその他の事前構築済みVM形式は、最も繰り返し寄せられた要望の一つでした。
IceWhaleはこのスレッドでPCIパススルーを約束しましたか？
いいえ。ユーザーは要望し、チームはフィードバックを認識しましたが、このスレッドはリリースの約束ではありません。
VMの自動起動は要望されましたか？
はい。特に、ホストの再起動後に復帰する必要があるサーバーVM向けに要望されました。
