Operating System:
Linux
Kit Version:
107 (Kit App Template)
Kit Template:
USD Composer
Hi,
I’m trying to run two Omniverse livestream server instances in Docker containers using the omni.kit.livestream.webrtc extension.
When I run a single instance, everything works fine — I’m using --network=host and can successfully connect using the AppStreamer from @nvidia/omniverse-webrtc-streaming-library v4.4.2.
However, when I try to start a second container instance, I run into problems because both containers attempt to use the same default signaling and media ports.
My questions:
- Since I’m using
--network=host, how can I run two containers without port conflict?
- In the backend (container entrypoint), how do I explicitly specify the signaling and media ports for each container instance?
- What arguments or environment variables should I pass to the container to make
omni.kit.livestream.webrtc listen on different ports?
- Are there any best practices for multi-instance deployment when using
AppStreamer on the client side?
Any suggestions or official guidance would be greatly appreciated!
Thanks in advance.
@shaun.chen you captured the problem well, and seem to understand the root cause! Great work.
You’re correct, when you implement --network=host when launching a container, the entire host NIC gets allocated to the container. Which means that any additional container on the same system becomes unable to use the NIC or forward traffic properly.
You can see the limitations here, specifically that port-mapping doesn’t work when using --network=host:
[Host network driver | Docker Docs]
This addresses your first question:
- Since I’m using
--network=host, how can I run two containers without port conflict?
Using only --network=host you can’t. But maybe you can do unique 1-to-1 port mappings when launching the Docker container so you can have multiple apps.
Just be aware, the livestream extension isn’t designed for usage in this way. So you’ll be on your own to manipulate Docker networking, OV Kit app listeners and client side configuration to get this to work.
Our scaled our solution is focused around Omniverse Kit App Streaming [Overview — Kit App Streaming]
- In the backend (container entrypoint), how do I explicitly specify the signaling and media ports for each container instance?
The streaming uses two sets of ports:
- Websocket on TCP port 49100
- WebRTC on UDP port range 49000-49007
You can see these in the ports forwarded for this range in the Dockerfile: [kit-app-template/tools/containers/Dockerfile.j2 at 106.5 · NVIDIA-Omniverse/kit-app-template · GitHub ]
- What arguments or environment variables should I pass to the container to make
omni.kit.livestream.webrtc listen on different ports?
This is configurable in the streaming extension. It’s not well documented, but let me give you an example.
Edit your *.kit file to include the following:
port = 39100
fixedHostPort = 30000
minHostPort = 30001
maxHostPort = 30009```
In the above, I've changed the default ports for signaling (WebSocket) to be 39100 and the stream (WebRTC) to be a range from 30000 to 30009.
> * Are there any best practices for multi-instance deployment when using `AppStreamer` on the client side?
For multiple instances of streaming an Omniverse Kit application, you need to use Kit App Streaming documented here: [https://docs.omniverse.nvidia.com/ovas/latest/index.html]
The client side configuration uses this web client sample: [https://github.com/NVIDIA-Omniverse/web-viewer-sample]
Thank you so much @rdarbha
Does Kit App Streaming support multiple concurrent users sharing a single GPU?
If so, how does it handle GPU resource allocation (VRAM, compute, NVENC sessions) between sessions?
No not really. Ideally you run one streaming instance per GPU. Otherwise you get significant performance degradation. We do not do any kind of GPU resource allocation for a single GPU. So if you want two streams, acquire two GPUs.