Use-case of dynamic emulator handling

Hi Guys,

I read about this project and it seems very promising. I read through the readthedocs documentation, but I found no use-case for emulators with a dynamic lifecycle.

Let say, you would like to run a custom-built emulator with custom parameters such as QEMU. The value for the parameters is only defined during runtime as a previous automation step creates them (freshly built image, maybe the QEMU was also just built from source).
How this can be handled by labgrid? Please note, that the emulator also has resource dependencies such as CPU and memory, so it cannot be infinite. Is it possible to make an emulator pool machine, which is able to serve a statically known number of emulator 'seats' (based on the available CPU and memory)? If a client could request a 'seat' an after acquiring it, the client could set up and use an emulator via SSH (or maybe via docker) on that pool machine(s).
Does this seem a viable solution supported by labgrid? Or what kind of structure would you suggest for this use-case?
I am open to contributing bits and pieces to this project in order to support this use-case, but I am interested in your opinions first.

The issue names no files, tests, or entry points; it discusses labgrid, QEMU, SSH, and Docker at an architectural level. Start by reviewing existing emulator and resource-management documentation, then define the supported lifecycle, resource limits, and acquisition flow before identifying implementation work.