Guest plugins currently communicate with the host over gRPC. While this works across all providers, it doesn't take advantage of more efficient, provider-native transport mechanisms that can bypass the network stack entirely.
We should introduce provider capabilties that allows each provider to supply its own guest communication backend. For example, the libvirt provider could use virtio-serial instead of gRPC, reducing overhead and avoiding reliance on guest networking.
Context:
Parts of the transport stack already support provider-specific implementations (e.g. sample transfers), so the groundwork for this pattern partially exists. This is also related to #43 (inter-VM IPC), since the mechanism could also serve as an alternative transport backend- and might be provider-dependent.
Rough scope:
- Allow providers to register their own transport implementation (e.g.
virtio-serial for libvirt)
- Extend the provider-specific capabilities already used for sample transfers into this abstraction
Guest plugins currently communicate with the host over gRPC. While this works across all providers, it doesn't take advantage of more efficient, provider-native transport mechanisms that can bypass the network stack entirely.
We should introduce provider capabilties that allows each provider to supply its own guest communication backend. For example, the
libvirtprovider could usevirtio-serialinstead of gRPC, reducing overhead and avoiding reliance on guest networking.Context:
Parts of the transport stack already support provider-specific implementations (e.g. sample transfers), so the groundwork for this pattern partially exists. This is also related to #43 (inter-VM IPC), since the mechanism could also serve as an alternative transport backend- and might be provider-dependent.
Rough scope:
virtio-serialfor libvirt)