Deploy with Helm#

VSR NIM ST 2110 deployment provides two Helm chart paths:

nvidia-vsr-nim-h4m-service: VSR NIM media function only, for integration with existing ST 2110 endpoints.
nvidia-vsr-nim-h4m-sample: end-to-end sample pipeline with sender, VSR NIM service, and receiver.

Use the service chart when upstream and downstream ST 2110 endpoints are already deployed. Use the sample chart when you want a packaged sender to VSR NIM to receiver pipeline for validation.

Pull Charts#

Use the NGC org and team that host the charts for VSR NIM on Holoscan for Media.

ngc config set
ngc registry chart pull nim/nvidia/nvidia-vsr-nim-h4m-service:1.0.10
ngc registry chart pull nim/nvidia/nvidia-vsr-nim-h4m-sample:1.0.10

Verify that the downloaded sample archive is the umbrella sample chart, not the service-only chart:

helm show chart nvidia-vsr-nim-h4m-sample-1.0.10.tgz | grep '^name: nvidia-vsr-nim-h4m-sample$'

Service Chart#

Use the service chart when upstream and downstream ST 2110 endpoints are deployed separately.

Extract the service values:

tar xzf nvidia-vsr-nim-h4m-service-1.0.10.tgz \
  nvidia-vsr-nim-h4m-service/values-nmos.yaml \
  nvidia-vsr-nim-h4m-service/values-st2110.yaml

Deploy in NMOS mode:

helm upgrade --install vsr-nim-service \
  nvidia-vsr-nim-h4m-service-1.0.10.tgz \
  -f nvidia-vsr-nim-h4m-service/values-nmos.yaml \
  --set nodeSelector.hostname=<node-hostname>

Deploy in static ST 2110 mode:

helm upgrade --install vsr-nim-service \
  nvidia-vsr-nim-h4m-service-1.0.10.tgz \
  -f nvidia-vsr-nim-h4m-service/values-st2110.yaml \
  --set nodeSelector.hostname=<node-hostname>

For clusters without topo-aware-scheduler, clear the scheduler name:

helm upgrade --install vsr-nim-service \
  nvidia-vsr-nim-h4m-service-1.0.10.tgz \
  -f nvidia-vsr-nim-h4m-service/values-nmos.yaml \
  --set schedulerName="" \
  --set nodeSelector.hostname=<node-hostname>

Sample Pipeline Chart#

Use the sample chart to deploy a sender to VSR NIM to receiver pipeline. The sample sender generates a live SMPTE color bars test pattern by default and requires no input asset.

Extract the sample values:

tar xzf nvidia-vsr-nim-h4m-sample-1.0.10.tgz \
  nvidia-vsr-nim-h4m-sample/values.yaml \
  nvidia-vsr-nim-h4m-sample/values-nmos.yaml \
  nvidia-vsr-nim-h4m-sample/values-st2110.yaml

The sample chart provides the following values files:

File	Mode	Description
`values.yaml`	NMOS	Default Helm configuration with component defaults and `global.vsrPipeline`.
`values-nmos.yaml`	NMOS	Overlay that enables DNS-SD based NMOS registration.
`values-st2110.yaml`	Static ST 2110	Overlay that disables NMOS discovery and uses static `global.vsrPipeline` transport settings.

The values-st2110.yaml overlay disables NMOS discovery. Stream connections are configured statically from global.vsrPipeline:

sender:
  appName: nvidia-vsr-nim-sender-st2110
  nmos:
    enabled: false
    httpPort: 9010
    label: "VSR NIM Sender"
    description: "ST2110-20 video sender 720p 4:2:2 10-bit"

receiver:
  appName: nvidia-vsr-nim-receiver-st2110
  nmos:
    enabled: false
    httpPort: 8999
    seed: file-receiver
    label: "VSR NIM Receiver"
    description: "ST2110-20 video receiver 4K 4:2:2 10-bit"

nvidia-vsr-nim-h4m-service:
  appName: nvidia-vsr-nim-st2110
  nmos:
    enabled: false
    httpPort: 8980
    name: sender-receiver
    label: "VSR NIM"
    description: "ST2110-20 video sender and receiver with 720p-to-4K upscaling"

The values-nmos.yaml overlay enables DNS-SD based NMOS registration. To force an explicit registration URL, set nmos.registrationUrl for each component:

sender:
  appName: nvidia-vsr-nim-sender-nmos
  nmos:
    enabled: true
    httpPort: 9010
    label: "VSR NIM Sender"
    description: "ST2110-20 video sender 720p 4:2:2 10-bit"
    registrationUrl: ""

receiver:
  appName: nvidia-vsr-nim-receiver-nmos
  nmos:
    enabled: true
    httpPort: 8999
    seed: file-receiver
    label: "VSR NIM Receiver"
    description: "ST2110-20 video receiver 4K 4:2:2 10-bit"
    registrationUrl: ""

nvidia-vsr-nim-h4m-service:
  appName: nvidia-vsr-nim-nmos
  nmos:
    enabled: true
    httpPort: 8980
    name: sender-receiver
    label: "VSR NIM"
    description: "ST2110-20 video sender and receiver with 720p-to-4K upscaling"
    registrationUrl: ""

Deploy in NMOS mode:

helm upgrade --install vsr-nim-h4m \
  nvidia-vsr-nim-h4m-sample-1.0.10.tgz \
  -f nvidia-vsr-nim-h4m-sample/values-nmos.yaml \
  --set sender.enabled=true \
  --set receiver.enabled=true \
  --set nvidia-vsr-nim-h4m-service.enabled=true \
  --set sender.nodeSelector.hostname=<node-hostname> \
  --set receiver.nodeSelector.hostname=<node-hostname> \
  --set nvidia-vsr-nim-h4m-service.nodeSelector.hostname=<node-hostname>

Deploy in static ST 2110 mode:

helm upgrade --install vsr-nim-h4m \
  nvidia-vsr-nim-h4m-sample-1.0.10.tgz \
  -f nvidia-vsr-nim-h4m-sample/values-st2110.yaml \
  --set sender.enabled=true \
  --set receiver.enabled=true \
  --set nvidia-vsr-nim-h4m-service.enabled=true \
  --set sender.nodeSelector.hostname=<node-hostname> \
  --set receiver.nodeSelector.hostname=<node-hostname> \
  --set nvidia-vsr-nim-h4m-service.nodeSelector.hostname=<node-hostname>

On clusters in which the VSR service and the sample sender and receiver use different SR-IOV pools, set the media networks and pool resources explicitly. The following example gives the VSR service two virtual functions from the RX pool and places the sample sender and receiver on the TX pool. This pattern is useful on clusters that require single-numa-node placement and expose separate SR-IOV resource pools:

helm upgrade --install vsr-nim-h4m \
  nvidia-vsr-nim-h4m-sample-1.0.10.tgz \
  -f nvidia-vsr-nim-h4m-sample/values-st2110.yaml \
  --set sender.enabled=true \
  --set receiver.enabled=true \
  --set nvidia-vsr-nim-h4m-service.enabled=true \
  --set sender.nodeSelector.hostname=<node-hostname> \
  --set receiver.nodeSelector.hostname=<node-hostname> \
  --set nvidia-vsr-nim-h4m-service.nodeSelector.hostname=<node-hostname> \
  --set sender.network.name=media-b-tx-net \
  --set sender.network.txPoolResource=openshift.io/media_b_tx_pool \
  --set receiver.network.name=media-b-tx-net \
  --set receiver.network.rxPoolResource=openshift.io/media_b_tx_pool \
  --set nvidia-vsr-nim-h4m-service.network.rxName=media-b-rx-net \
  --set nvidia-vsr-nim-h4m-service.network.txName=media-b-rx-net \
  --set nvidia-vsr-nim-h4m-service.network.rxPoolResource=openshift.io/media_b_rx_pool \
  --set nvidia-vsr-nim-h4m-service.network.rxPoolCount=2 \
  --set nvidia-vsr-nim-h4m-service.network.txPoolResource="" \
  --set nvidia-vsr-nim-h4m-service.input.video.localInterfaceName=net1 \
  --set nvidia-vsr-nim-h4m-service.output.video.localInterfaceName=net2

Use equivalent network-resource overrides in NMOS mode when the same SR-IOV placement constraints apply.

In NMOS mode, use DNS-SD registration by default. If DNS-SD is not available in the cluster, you can point each component directly at the NMOS IS-04 registration endpoint:

helm upgrade --install vsr-nim-h4m \
  nvidia-vsr-nim-h4m-sample-1.0.10.tgz \
  -f nvidia-vsr-nim-h4m-sample/values-nmos.yaml \
  --set sender.enabled=true \
  --set receiver.enabled=true \
  --set nvidia-vsr-nim-h4m-service.enabled=true \
  --set sender.nodeSelector.hostname=<node-hostname> \
  --set receiver.nodeSelector.hostname=<node-hostname> \
  --set nvidia-vsr-nim-h4m-service.nodeSelector.hostname=<node-hostname> \
  --set 'sender.nmos.registrationUrl=http://nmos-registry-nmos-cpp-registry:8010/x-nmos/registration/v1.3' \
  --set 'receiver.nmos.registrationUrl=http://nmos-registry-nmos-cpp-registry:8010/x-nmos/registration/v1.3' \
  --set 'nvidia-vsr-nim-h4m-service.nmos.registrationUrl=http://nmos-registry-nmos-cpp-registry:8010/x-nmos/registration/v1.3'

Set site-specific values for node selection, image pull secrets, network attachment names, multicast groups, ports, packet sizes, and Rivermax secret names before production use.

The sample sender and receiver pass nmos.registrationUrl directly to nvdsnmosbin. The VSR NIM service writes the value into config.json as nmos_config.registration_url. When you use an explicit registration URL, verify that the VSR NIM pod can reach the IS-04 registry endpoint and that the sender, VSR NIM service, and receiver all register in the NMOS registry.

For NMOS validation, deploy the receiver and VSR NIM first, wait for both pods to become ready, and then enable the sender. This procedure avoids filling the VSR output queue before the downstream receiver is connected.

Sender Input#

The public sample chart path uses a live SMPTE color bars test pattern by default and requires no input asset.

Image Pull Secrets#

Image pull secret names are configurable examples. Use names that match the secrets in your workload namespace.

The VSR NIM service chart leaves image.secret empty by default. Set it when the kubelet does not already have registry credentials:

--set image.secret=<secret-name>

For the sample chart, set the VSR NIM service image secret:

--set nvidia-vsr-nim-h4m-service.image.secret=<secret-name>

The sample sender and receiver default to ngc-secret-h4m as the image pull secret. If the sender or receiver use a different secret name, set those values too:

--set sender.image.secret=<secret-name>
--set receiver.image.secret=<secret-name>

Network Attachments#

The sample sender and receiver each use one NetworkAttachmentDefinition. The VSR NIM service uses network.rxName for the input-side media interface and network.txName for the output-side media interface:

network:
  rxName: media-a-rx-net
  txName: media-a-tx-net

The rxName and txName keys describe how the VSR NIM pod uses each interface. The underlying media networks do not have to be RX-only or TX-only as long as the selected attachments support the traffic direction used by the pod.

If your SR-IOV device plugin exposes named Rivermax resources, set the optional pool resource values:

network:
  rxPoolResource: nvidia.com/rivermax_rx
  txPoolResource: nvidia.com/rivermax_tx
  rxPoolCount: 1
  txPoolCount: 1

When rxPoolResource and txPoolResource are the same device resource, the service chart aggregates the counts into one rendered resource request. When they are different, each resource is requested separately.

For a VSR pod that needs two virtual functions from the same SR-IOV pool, set one pool resource with count 2 and leave the other pool resource empty:

nvidia-vsr-nim-h4m-service:
  network:
    rxName: media-b-rx-net
    txName: media-b-rx-net
    rxPoolResource: openshift.io/media_b_rx_pool
    rxPoolCount: 2
    txPoolResource: ""
  input:
    video:
      localInterfaceName: net1
  output:
    video:
      localInterfaceName: net2

Do not collapse separate RX and TX pools into one logical resource unless the cluster exposes one shared pool. On single-numa-node clusters, hiding the resource split can cause scheduler or kubelet topology placement failures.

Verify#

Check the deployments:

kubectl get deploy
kubectl rollout status deployment/<deployment-name> --timeout=300s
kubectl logs deployment/<deployment-name>

On Red Hat OpenShift, replace kubectl with oc.

For media-flow verification, see End-to-End Verification.

Troubleshooting#

Symptom	Likely Cause	Action
`ImagePullBackOff` on sender or receiver.	The configured sender or receiver image pull secret is missing or invalid.	Verify that the secret exists in the workload namespace, or set `sender.image.secret` and `receiver.image.secret`.
`ImagePullBackOff` on VSR NIM.	The VSR service image pull secret is missing or invalid.	For the sample chart, set `nvidia-vsr-nim-h4m-service.image.secret`; for the service chart, set `image.secret`.
Pods stay `Pending`.	Node selector, scheduler, GPU, hugepages, CPU, memory, or SR-IOV resources do not match the cluster.	Check pod events with `kubectl describe pod <pod-name> -n <namespace>`.
Scheduler error.	`topo-aware-scheduler` is not installed on the cluster.	For the sample chart, clear `h4m.schedulerName` and `nvidia-vsr-nim-h4m-service.schedulerName`; for the service chart, clear `schedulerName`.
Pods stay `Pending` with `single-numa-node` topology errors.	GPU and SR-IOV pool resources cannot be placed on the same NUMA node.	Check node resource topology. Set the VSR service to a NUMA-local pool, such as two `media-b-rx-net` attachments with `rxPoolResource=openshift.io/media_b_rx_pool` and `rxPoolCount=2`; place sender and receiver on a pool local to their target node resources.
Only the VSR NIM service pod is deployed.	The service-only chart was installed, or a previous upgrade kept sample components disabled.	Verify the chart name with `helm show chart`, and then set `sender.enabled=true`, `receiver.enabled=true`, and `nvidia-vsr-nim-h4m-service.enabled=true`.
Rivermax errors in logs.	The Rivermax license secret is missing or misnamed.	Verify that the configured Rivermax secret exists in the workload namespace.
Sender and receiver appear in NMOS but VSR NIM does not.	The VSR NIM service cannot reach the configured NMOS registry, or the explicit `nmos.registrationUrl` value is incorrect.	Verify DNS-SD discovery or the explicit IS-04 registration URL. Confirm that the VSR NIM pod can reach the registry and that `nvidia-vsr-nim-h4m-service.nmos.registrationUrl` matches the registry endpoint.

Uninstall#

helm uninstall vsr-nim-service
helm uninstall vsr-nim-h4m