Problem
VMM proxies several API methods to the Guest Agent over vsock. Request deadlines bound how long each individual call can remain active, but they do not cap the number of calls that can execute concurrently. A burst of requests, or many unresponsive guests, could therefore create a large number of concurrent connection attempts and request tasks until their deadlines expire.
Possible approach
Consider adding admission control at the centralized Guest Agent client boundary, with:
- a global VMM concurrency limit;
- an optional per-VM concurrency limit so one guest cannot consume the full budget;
- explicit overload behavior (fail fast versus bounded queueing);
- metrics for active calls, rejected calls, and timeout rates;
- limits derived from expected deployment size and measured resource use rather than hard-coded without capacity data.
This is intentionally tracked separately from request timeout hardening so the timeout fix remains small and the operational policy can be reviewed independently.
Problem
VMM proxies several API methods to the Guest Agent over vsock. Request deadlines bound how long each individual call can remain active, but they do not cap the number of calls that can execute concurrently. A burst of requests, or many unresponsive guests, could therefore create a large number of concurrent connection attempts and request tasks until their deadlines expire.
Possible approach
Consider adding admission control at the centralized Guest Agent client boundary, with:
This is intentionally tracked separately from request timeout hardening so the timeout fix remains small and the operational policy can be reviewed independently.