この2025年9月の報告は、現在の「ZVMは動作しない」という結論ではなく、ベータ版に特有の過去のZVM障害として扱うべきです。ユーザーはZimaOS 1.4.4-beta1を実行しており、VMの起動時にclient socket is closedというメッセージが内部エラーとして繰り返し表示されていました。Zima-Giorgioは、同じベータ版でUbuntu VMをテストし、正常に動作したと述べているため、この問題は1.4.4-beta1のすべてのインストールで発生する普遍的なものではありません。
このスレッドの有用な点は、診断を絞り込めることです。KVMはロード済みで、libvirtのデフォルトネットワークとストレージプールはアクティブでした。また、libvirt設定をリセットしても改善しませんでした。その後のログには virtqemud libvirtネットワークソケットへの接続に失敗した後、非アクティブ化されました。
libvirt-guestsの再起動は適切な層での対応ではなかった
元のユーザーが最初に再起動したのは libvirt-guests.serviceコミュニティの回答者は、このサービスは主にホストのシャットダウン時にゲストの保存・復元処理を扱うものであり、VMを起動する中核のQEMU/libvirtデーモンではないと指摘しました。
したがって、そこでの再起動が成功しても、VMスタックが正常に動作している証明にはなりませんでした。
KVMハードウェアアクセラレーションは利用可能だった
ユーザーはロード済みモジュールを確認し、両方の kvm および kvm_intelこれにより、よくある原因の1つである、カーネルレベルで仮想化サポートが完全に利用できないという可能性は排除されました。
デフォルトネットワークとストレージプールはアクティブだった
このスレッドでは、libvirtのデフォルトネットワークとストレージプールも確認されました。どちらもアクティブでアクセス可能だと報告されています。
そのため、VMストレージの欠落やNATネットワークの非アクティブ状態が主な原因である可能性は低くなりました。
libvirtの設定を完全にリセットしても解決しなかった
元の投稿者は以下のディレクトリ配下の設定を削除しました /etc/libvirt および /var/lib/libvirt それでも失敗が再現されました。これは破壊的な診断手順であり、現在の第一選択の解決策として推奨すべきではありません。
現行の本番システムでは、libvirtの状態を変更する前にVMの定義とディスクイメージをバックアップしてください。
後のログでvirtqemudとネットワークソケットが示された
その後、ユーザーはより有用なエラーを投稿しました： virtqemud ソケットへの接続に失敗しました /var/run/libvirt/...その後、サービスは停止しました。そのため、UIに表示されたクライアントソケット切断メッセージは、バックエンドデーモンの問題による下流の症状である可能性が高いものでした。
「正常に終了しました」と表示されるデーモンでも、アプリケーションを停止させることがある
複数のlibvirtデーモンはソケットによって起動され、アイドル状態になると停止することがあるため、「inactive」だけでは障害の証拠になりません。ただしこのケースでは、明示的なソケット接続失敗とVM終了ログがあり、バックエンドの相互作用が疑わしい状況でした。
systemdの状態は、単独のステータス行だけで判断せず、実際のlibvirt/QEMUエラーと併せて解釈してください。
IceWhaleはテスト環境でこの障害を再現できなかった
Zima-Giorgioは、Ubuntu VMが1.4.4-beta1上で正常に動作したと述べ、OSの種類とスクリーンショットまたは動画を求めました。これは重要な公式見解です。つまり、ソースからは実際のユーザー障害は確認できますが、ベータ版全体に及ぶ障害が確認されたわけではありません。
ユーザーはこれをGitHubのベータ版バグとしてエスカレーションした
投稿者は、フォーラムでのファイルアップロードが難しかったため、詳細なログと動画をIceWhaleのGitHubトラッカーに移しました。添付されたソースは静止画のフォーラムスクリーンショットではなく、動画でした。
公開フォーラムのスレッドには、単一の確定した根本原因を示すリリースノートや最終パッチはありません。
現在のZimaOSに1.4.4-beta1向けのサービス操作を適用しないでください
現在のZimaOSは、このベータ版から大きく進化しています。libvirtのパッケージ構成、ZVMのUI、イメージ対応、systemdサービスの動作はすべて異なる可能性があります。
同様の現在の障害では、システムファイルを変更する前に、VMエラー、現在のZimaOSバージョン、KVMの状態、libvirtのネットワークとストレージの状態、QEMUログを収集してください。
ユーザーがより良い証拠を集めるにつれて、障害の様子が変化した
当初の理論は、サービスを再起動しても改善しなかったため、ZVMベータ版にはより深刻なバグがあるという単純なものでした。次の調査で、KVMが存在し、デフォルトのネットワークとストレージが正常であることが確認されました。その後になって初めて、内部のソケットエラーが virtqemud 見えるようになりました。
この経過は、仮想化のトラブルシューティングにおける良い手本です。一般的なUIエラーから、いきなりハイパーバイザーの再インストールに進むのは避け、ハードウェアアクセラレーション、ストレージ、ネットワーク、サービスの各層を順番に切り分けます。
virtqemudはモジュール型libvirtスタックの残りの部分に依存する
記録された失敗は、libvirtネットワークソケットに関連していました。最新のモジュール型libvirtでは、QEMU管理、ネットワーク管理、ロギングなどの各機能が、別々のデーモンとソケットに分かれている場合があります。そのため、QEMUデーモンが存在していても、必要なネットワークデーモンとの通信に失敗する可能性があります。
これは、KVMとストレージプールが正常に見えていたにもかかわらず、VMが失敗する可能性がある理由の説明に役立ちます。
QEMUログには、ゲストが終了させられていたことが示されていた
ユーザーのQEMUログには、ゲストプロセスがシグナル15によって繰り返し終了したことが示されていました。 virtqemud。これは、ゲストが不良なWindowsまたはLinuxのISOが原因でクラッシュしたのではなく、仮想化制御スタックによって停止させられていたという考えを裏付けます。
ユーザーは複数のISOイメージもテストし、同じ挙動を確認しました。これにより、「インストールメディアの不良」という説明の可能性はさらに低くなります。
ベータ版のリグレッションでは、破壊的な修復を行う前に安定版と比較する
コミュニティからの返信では、VMをすぐに使う必要がある場合は安定版チャンネルにロールバックすることが提案されました。これはベータ版限定の障害に対する妥当な診断の境界です。同じVMとハードウェアが安定版で動作するなら、ベータ版が最も有力な変更要因になります。
元の投稿者による最終的なロールバック確認はスレッドに含まれていないため、これは検証済みの解決策ではなく、診断戦略として扱われます。
現在のZVM障害では、最初のバックエンドエラーを保存する
「クライアントソケットが閉じています」のようなUIメッセージは、意味のあるバックエンドイベントの後に発生することがよくあります。［Start］をクリックした正確な時点でシステムログとQEMUログを取得し、最後のステータスメッセージだけでなく、最初に発生したエラーを保存してください。
これにより、下流の症状を根本原因と誤って扱うリスクが低減します。
ZVMベータ版FAQ（過去版）
元の事例ではKVMがありませんでしたか？
いいえ。ユーザーはKVMモジュールが読み込まれていることを確認しました。
libvirtの設定をリセットすると解決しましたか？
いいえ。
すべての1.4.4-beta1システムで問題が確認されましたか？
いいえ。Zima-Giorgioによると、同じベータ版でUbuntuのテストVMは正常に動作しました。
バックエンドに関する最も有力な手がかりは何でしたか？
virtqemud 無効化する前に、libvirtネットワークソケットへの接続に失敗したことが記録されていた。
