---
title: Configuring namespaced SR-IOV resources
---

# Configuring namespaced SR-IOV resources {#configuring-namespaced-sriov-resources}

Namespaced SriovNetwork Resources allow application owners to create and manage their own SriovNetwork resources directly within their namespaces, rather than relying on a cluster administrator to do it in a shared operator namespace. This method simplifies permissions, improves security, and provides better separation between applications.

## An introduction to namespaced SriovNetwork resources {#introduction-to-namespaced-sriovnetwork-resources_configuring-namespaced-sriov-resources}

SR-IOV networks can be created and managed directly within application namespaces. This capability provides application owners with fine-grained control over network configurations, simplifying their workflow.

This approach offers several key advantages that enhance the user experience:

- Increased Autonomy and Control: Application owners gain direct control over their network configurations, eliminating the need for a cluster administrator to create `SriovNetwork` objects on their behalf.
- Enhanced Security: By allowing users to manage resources within their own namespaces, the feature improves security and provides better separation between applications. This also helps avoid the unintentional incorrect configuration of other applications' NetworkAttachmentDefinition objects.
- Simplified Permissions: Managing `SriovNetwork` resources directly in their own namespaces simplifies user permissions. This streamlines the workflow and reduces the operational burden for developers.

### Configuring SriovNetwork in application namespaces {#nw-configuring-sriov-in-app-namespace_configuring-namespaced-sriov-resources}

When an SriovNetwork custom resource (CR) is deployed in an application namespace, do not define or populate the `spec.networkNamespace` field. In this scenario, the NetworkAttachmentDefinition will be created in the same namespace as the SriovNetwork CR.

The SR-IOV Network Operator webhook rejects the creation of an `SriovNetwork` resource in an application namespace if the `spec.networkNamespace` field is defined.

Follow this procedure to create an `SriovNetwork` resource in an application namespace and attach a pod to the additional network.

**Prerequisites**

The following steps must be completed by a cluster administrator before an application owner can configure a namespaced SriovNetwork resource:

- The SR-IOV Network Operator is installed in the `openshift-sriov-network-operator` namespace.
- Nodes with SR-IOV hardware are labeled for the operator to identify the nodes.

As an application owner you need to have administrator privileges on the application namespace.

**Procedure**

1. Specify the SR-IOV network device configuration for a node by creating an SR-IOV network node policy. The `SriovNetworkNodePolicy` object is created in the `openshift-sriov-network-operator` namespace to define the SR-IOV network device configuration for nodes. Example configuration for Intel DPK is as follows:

   ```yaml
   apiVersion: sriovnetwork.openshift.io/v1
   kind: SriovNetworkNodePolicy
   metadata:
     name: intel-dpdk-node-policy
     namespace: openshift-sriov-network-operator
   spec:
     resourceName: intelnics
     nodeSelector:
       feature.node.kubernetes.io/network-sriov.capable: "true"
     priority: 10
     numVfs: 4
     nicSelector:
       vendor: "8086"
       deviceID: "158b"
       pfNames: [""]
     deviceType: netdevice
   ```
2. Create an application namespace. For example, create a namespace named `sriov-app` by running the following command:

   ```terminal
   $ cat <<EOF | oc create -f -
   apiVersion: v1
   kind: Namespace
   metadata:
       name: sriov-app
   EOF
   ```
3. Create a YAML file, for example, `sriovnetwork.yaml`, to define the `SriovNetwork` object in the application namespace.

   ```yaml
   apiVersion: sriovnetwork.openshift.io/v1
   kind: SriovNetwork
   metadata:
     name: test-network
     namespace: sriov-app
   spec:
     resourceName: intelnics
     ipam:
       type: host-local
       subnet: "10.0.0.0/24"
       routes:
         - dst: "0.0.0.0/0"
           gw: "10.0.0.1"
     vlan: 10
   ```

   - `namespace`: The value must match the name of the application namespace, for example, `sriov-app`.
   - `resourceName`: This value must match the `spec.resourceName` defined in the `SriovNetworkNodePolicy` created by the cluster administrator, which in the example is `intelnics`.
4. Apply the YAML file to create the `SriovNetwork` object in the application namespace.

   ```terminal
   $ oc create -f sriovnetwork.yaml
   ```

   After an application owner has created the SriovNetwork resource, they can create a pod that uses the newly defined network. You attach a pod to the additional network by adding a specific annotation to the pod’s YAML manifest.
5. Create a YAML file, for example, `test-pod.yaml`, to define a pod that uses the new network attachment:

   ```yaml
   apiVersion: v1
   kind: Pod
   metadata:
     name: test-pod
     namespace: sriov-app
     annotations:
       k8s.v1.cni.cncf.io/networks: test-network
   spec:
     containers:
     - name: test-pod-container
       image: centos/tools
       command: ["/bin/bash", "-c", "sleep 3600"]
   ```

   - `namespace`: The namespace where the pod is created. This must be the same namespace where the `SriovNetwork` object is created.
   - `annotations`: `k8s.v1.cni.cncf.io/networks` specifies the additional network that the pod connects to. The value must match the `metadata.name` of the `SriovNetwork` object.
6. Apply the YAML file to create the pod in the application namespace by running the following command:

   ```terminal
   $ oc create -f test-pod.yaml
   ```

**Verification**

1. Verify that the NetworkAttachmentDefinition has been created in the same namespace by running the following command:

   ```terminal
   $ oc get net-attach-def -n sriov-app
   ```

   Where `sriov-app` is the application namespace where the `SriovNetwork` object is created.

   The following is example output:

   ```terminal
   NAME           AGE
   test-network   2m
   ```
2. Verify the pod is running and get its network status by describing the pod with the following command:

   ```terminal
   $ oc describe pod test-pod -n sriov-app
   ```

   Where `sriov-app` is the application namespace where the pod is created.

   In the output, look for the `k8s.v1.cni.cncf.io/network-status` annotation. This shows the name of the network and the IP assigned to the pod on that interface.
3. Check that the pod has the additional network interface by running the following command:

   ```terminal
   $ oc exec -it test-pod -n sriov-app -- ip a
   ```

   Look for a secondary network interface, for example `net1` or `eth1`, in addition to the default eth0 interface. The `net1` interface should have an IP address from the subnet you defined in the SriovNetwork object, for example `10.0.0.0/24`. This confirms the pod is using the new network attachment definition.