Chapter 7. Networking

1. Configure an OVN-Kubernetes secondary network by creating a network attachment definition (NAD).
2. Connect the VM to the OVN-Kubernetes secondary network by adding the network details to the VM specification.

Procedure

1. Edit the interfaces spec of your virtual machine configuration file:

   apiVersion: kubevirt.io/v1
   kind: VirtualMachine
   metadata:
     name: example-vm
   spec:
     template:
       spec:
         domain:
           devices:
             interfaces:
               - name: default
                 masquerade: {} 1
                 ports: 2
                   - port: 80
   # ...
         networks:
         - name: default
           pod: {}

   1

   Connect using masquerade mode.

   2

   Optional: List the ports that you want to expose from the virtual machine, each specified by the port field. The port value must be a number between 0 and 65536. When the ports array is not used, all ports in the valid range are open to incoming traffic. In this example, incoming traffic is allowed on port 80.

   Note

   Ports 49152 and 49153 are reserved for use by the libvirt platform and all other incoming traffic to these ports is dropped.

2. Create the virtual machine:

   $ oc create -f <vm-name>.yaml

Procedure

1. In a new virtual machine configuration, include an interface with masquerade and configure the IPv6 address and default gateway by using cloud-init.

   apiVersion: kubevirt.io/v1
   kind: VirtualMachine
   metadata:
     name: example-vm-ipv6
   spec:
     template:
       spec:
         domain:
           devices:
             interfaces:
               - name: default
                 masquerade: {} 1
                 ports:
                   - port: 80 2
   # ...
         networks:
         - name: default
           pod: {}
         volumes:
         - cloudInitNoCloud:
             networkData: |
               version: 2
               ethernets:
                 eth0:
                   dhcp4: true
                   addresses: [ fd10:0:2::2/120 ] 3
                   gateway6: fd10:0:2::1 4

   1

   Connect using masquerade mode.

   2

   Allows incoming traffic on port 80 to the virtual machine.

   3

   The static IPv6 address as determined by the Network.pod.vmIPv6NetworkCIDR field in the virtual machine instance configuration. The default value is fd10:0:2::2/120.

   4

   The gateway IP address as determined by the Network.pod.vmIPv6NetworkCIDR field in the virtual machine instance configuration. The default value is fd10:0:2::1.

2. Create the virtual machine in the namespace:

   $ oc create -f example-vm-ipv6.yaml

Procedure

1. Edit the VirtualMachine manifest to add the label for service creation:

   apiVersion: kubevirt.io/v1
   kind: VirtualMachine
   metadata:
     name: example-vm
     namespace: example-namespace
   spec:
     running: false
     template:
       metadata:
         labels:
           special: key 1
   # ...

   1

   Add special: key to the spec.template.metadata.labels stanza.

   Note

   Labels on a virtual machine are passed through to the pod. The special: key label must match the label in the spec.selector attribute of the Service manifest.

2. Save the VirtualMachine manifest file to apply your changes.

3. Create a Service manifest to expose the VM:

   apiVersion: v1
   kind: Service
   metadata:
     name: example-service
     namespace: example-namespace
   spec:
   # ...
     selector:
       special: key 1
     type: NodePort 2
     ports: 3
       protocol: TCP
       port: 80
       targetPort: 9376
       nodePort: 30000

   1

   Specify the label that you added to the spec.template.metadata.labels stanza of the VirtualMachine manifest.

   2

   Specify ClusterIP, NodePort, or LoadBalancer.

   3

   Specifies a collection of network ports and protocols that you want to expose from the virtual machine.

4. Save the Service manifest file.

5. Create the service by running the following command:

   $ oc create -f example-service.yaml

6. Restart the VM to apply the changes.

Procedure

1. If the VM to which you want to hot plug the network interface is not running, start it by using the following command:

   $ virtctl start <vm_name> -n <namespace>

2. Use the following command to add the new network interface to the running VM. Editing the VM specification adds the new network interface to the VM and virtual machine instance (VMI) configuration but does not attach it to the running VM.

   $ oc edit vm <vm_name>

   Example VM configuration

   apiVersion: kubevirt.io/v1
   kind: VirtualMachine
   metadata:
     name: vm-fedora
   template:
     spec:
       domain:
         devices:
           interfaces:
           - name: defaultnetwork
             masquerade: {}
           # new interface
           - name: <secondary_nic> 1
             bridge: {}
       networks:
       - name: defaultnetwork
         pod: {}
       # new network
       - name: <secondary_nic> 2
         multus:
           networkName: <nad_name> 3
   # ...

   1

   Specifies the name of the new network interface.

   2

   Specifies the name of the network. This must be the same as the name of the new network interface that you defined in the template.spec.domain.devices.interfaces list.

   3

   Specifies the name of the NetworkAttachmentDefinition object.

3. To attach the network interface to the running VM, live migrate the VM by running the following command:

   $ virtctl migrate <vm_name>

Verification

1. Verify that the VM live migration is successful by using the following command:

   $ oc get VirtualMachineInstanceMigration -w

   Example output

   NAME                        PHASE             VMI
   kubevirt-migrate-vm-lj62q   Scheduling        vm-fedora
   kubevirt-migrate-vm-lj62q   Scheduled         vm-fedora
   kubevirt-migrate-vm-lj62q   PreparingTarget   vm-fedora
   kubevirt-migrate-vm-lj62q   TargetReady       vm-fedora
   kubevirt-migrate-vm-lj62q   Running           vm-fedora
   kubevirt-migrate-vm-lj62q   Succeeded         vm-fedora

2. Verify that the new interface is added to the VM by checking the VMI status:

   $ oc get vmi vm-fedora -ojsonpath="{ @.status.interfaces }"

   Example output

   [
     {
       "infoSource": "domain, guest-agent",
       "interfaceName": "eth0",
       "ipAddress": "10.130.0.195",
       "ipAddresses": [
         "10.130.0.195",
         "fd02:0:0:3::43c"
       ],
       "mac": "52:54:00:0e:ab:25",
       "name": "default",
       "queueCount": 1
     },
     {
       "infoSource": "domain, guest-agent, multus-status",
       "interfaceName": "eth1",
       "mac": "02:d8:b8:00:00:2a",
       "name": "bridge-interface", 1
       "queueCount": 1
     }
   ]

   1

   The hot plugged interface appears in the VMI status.

Procedure

1. Edit the VM specification to hot unplug a secondary network interface. Setting the interface state to absent detaches the network interface from the guest, but the interface still exists in the pod.

   $ oc edit vm <vm_name>

   Example VM configuration

   apiVersion: kubevirt.io/v1
   kind: VirtualMachine
   metadata:
     name: vm-fedora
   template:
     spec:
       domain:
         devices:
           interfaces:
             - name: defaultnetwork
               masquerade: {}
             # set the interface state to absent
             - name: <secondary_nic>
               state: absent 1
               bridge: {}
       networks:
         - name: defaultnetwork
           pod: {}
         - name: <secondary_nic>
           multus:
             networkName: <nad_name>
   # ...

   1

   Set the interface state to absent to detach it from the running VM. Removing the interface details from the VM specification does not hot unplug the secondary network interface.

2. Remove the interface from the pod by migrating the VM:

   $ virtctl migrate <vm_name>

Procedure

1. Edit the VM configuration file to add the sidecar.istio.io/inject: "true" annotation:

   Example configuration file

   apiVersion: kubevirt.io/v1
   kind: VirtualMachine
   metadata:
     labels:
       kubevirt.io/vm: vm-istio
     name: vm-istio
   spec:
     runStrategy: Always
     template:
       metadata:
         labels:
           kubevirt.io/vm: vm-istio
           app: vm-istio 1
         annotations:
           sidecar.istio.io/inject: "true" 2
       spec:
         domain:
           devices:
             interfaces:
             - name: default
               masquerade: {} 3
             disks:
             - disk:
                 bus: virtio
               name: containerdisk
             - disk:
                 bus: virtio
               name: cloudinitdisk
           resources:
             requests:
               memory: 1024M
         networks:
         - name: default
           pod: {}
         terminationGracePeriodSeconds: 180
         volumes:
         - containerDisk:
             image: registry:5000/kubevirt/fedora-cloud-container-disk-demo:devel
           name: containerdisk

   1

   The key/value pair (label) that must be matched to the service selector attribute.

   2

   The annotation to enable automatic sidecar injection.

   3

   The binding method (masquerade mode) for use with the default pod network.

2. Apply the VM configuration:

   $ oc apply -f <vm_name>.yaml 1

   1

   The name of the virtual machine YAML file.

3. Create a Service object to expose your VM to the service mesh.

   apiVersion: v1
   kind: Service
   metadata:
     name: vm-istio
   spec:
     selector:
       app: vm-istio 1
     ports:
       - port: 8080
         name: http
         protocol: TCP

   1

   The service selector that determines the set of pods targeted by a service. This attribute corresponds to the spec.metadata.labels field in the VM configuration file. In the above example, the Service object named vm-istio targets TCP port 8080 on any pod with the label app=vm-istio.

4. Create the service:

   $ oc create -f <service_name>.yaml 1

   1

   The name of the service YAML file.

Procedure

1. Create a NetworkAttachmentDefinition manifest according to the following example:

   Example configuration file

   apiVersion: "k8s.cni.cncf.io/v1"
   kind: NetworkAttachmentDefinition
   metadata:
     name: my-secondary-network 1
     namespace: openshift-cnv
   spec:
     config: '{
       "cniVersion": "0.3.1",
       "name": "migration-bridge",
       "type": "macvlan",
       "master": "eth1", 2
       "mode": "bridge",
       "ipam": {
         "type": "whereabouts", 3
         "range": "10.200.5.0/24" 4
       }
     }'

   1

   Specify the name of the NetworkAttachmentDefinition object.

   2

   Specify the name of the NIC to be used for live migration.

   3

   Specify the name of the CNI plugin that provides the network for the NAD.

   4

   Specify an IP address range for the secondary network. This range must not overlap the IP addresses of the main network.

2. Open the HyperConverged CR in your default editor by running the following command:

   oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv

3. Add the name of the NetworkAttachmentDefinition object to the spec.liveMigrationConfig stanza of the HyperConverged CR:

   Example HyperConverged manifest

   apiVersion: hco.kubevirt.io/v1beta1
   kind: HyperConverged
   metadata:
     name: kubevirt-hyperconverged
   spec:
     liveMigrationConfig:
       completionTimeoutPerGiB: 800
       network: <network> 1
       parallelMigrationsPerCluster: 5
       parallelOutboundMigrationsPerNode: 2
       progressTimeout: 150
   # ...

   1

   Specify the name of the Multus NetworkAttachmentDefinition object to be used for live migrations.

4. Save your changes and exit the editor. The virt-handler pods restart and connect to the secondary network.

Procedure

1. Navigate to Virtualization > Overview in the Red Hat OpenShift Service on AWS web console.
2. Click the Settings tab and then click Live migration.
3. Select the network from the Live migration network list.