Chapter 9. Networking

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: {}

   Copy to Clipboard Toggle word wrap

   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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

   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

   Copy to Clipboard Toggle word wrap

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:
     runStrategy: Halted
     template:
       metadata:
         labels:
           special: key 

   1

   
   # ...

   Copy to Clipboard Toggle word wrap

   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

   Copy to Clipboard Toggle word wrap

   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

   Copy to Clipboard Toggle word wrap
6. Restart the VM to apply the changes.

Procedure

1. Use your preferred text editor to edit the VirtualMachine manifest, as shown in the following example:

   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

   
   # ...

   Copy to Clipboard Toggle word wrap

   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.

2. Save your changes and exit the editor.

3. For the new configuration to take effect, apply the changes by running the following command. Applying the changes triggers automatic VM live migration and attaches the network interface to the running VM.

   $ oc apply -f <filename>.yaml

   Copy to Clipboard Toggle word wrap

   where:

   <filename>

   Specifies the name of your VirtualMachine manifest YAML file.

Verification

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

   $ oc get VirtualMachineInstanceMigration -w

   Copy to Clipboard Toggle word wrap

   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

   Copy to Clipboard Toggle word wrap

2. Verify that the new interface is added to the VM by checking the status of the virtual machine instance (VMI):

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

   Copy to Clipboard Toggle word wrap

   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
     }
   ]

   Copy to Clipboard Toggle word wrap

   1

   The hot plugged interface appears in the VMI status.

Procedure

1. Using your preferred text editor, edit the VirtualMachine manifest file and set the interface state to absent. Setting the interface state to absent detaches the network interface from the guest, but the interface still exists in the pod.

   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>
   # ...

   Copy to Clipboard Toggle word wrap

   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. Save your changes and exit the editor.

3. For the new configuration to take effect, apply the changes by running the following command. Applying the changes triggers automatic VM live migration and removes the interface from the pod.

   $ oc apply -f <filename>.yaml

   Copy to Clipboard Toggle word wrap

   where:

   <filename>

   Specifies the name of your VirtualMachine manifest YAML file.

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

   Copy to Clipboard Toggle word wrap

   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

   Copy to Clipboard Toggle word wrap

   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

   Copy to Clipboard Toggle word wrap

   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

   Copy to Clipboard Toggle word wrap

   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

   
       }
     }'

   Copy to Clipboard Toggle word wrap

   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

   Copy to Clipboard Toggle word wrap

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
     namespace: openshift-cnv
   spec:
     liveMigrationConfig:
       completionTimeoutPerGiB: 800
       network: <network> 

   1

   
       parallelMigrationsPerCluster: 5
       parallelOutboundMigrationsPerNode: 2
       progressTimeout: 150
   # ...

   Copy to Clipboard Toggle word wrap

   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.