KVM - Deployment and Setup for NFV Controller vCPE

This section contains information on Qemu/KVM, which is a Linux Hypervisor. It includes information on installing the associated packages.

• Install the following packages on Linux kernel 6.5.0 or later:
• qemu-kvm: A generic machine emulator and virtualizer. Use version 6.2.0 or later.
• libvirt-daemon-system: a collection of software that provides a convenient way to manage virtual machines and other virtualization functionality, such as storage and network interface management. Use version 8.0.0 or later.
• libvirt-clients: contains the user-space tools that interact with the libvirt library to perform various virtualization management tasks. Use version 8.0.0 or later.
• Optional: virt-manager (i.e., the Virtual Machine Manager): If you use a GUI on your server, virt-manager provides a graphical tool for managing virtual machines. It uses libvirt-client library as the management API.

Installing the Applications

To install the KVM Hypervisor and libvirt virtualization library on a Ubuntu based Distribution

1. Issue the following command in a command shell to install a KVM environment:
   $ sudo apt-get install qemu-kvm libvirt-daemon-system and libvirt-clients virt-manager

2. Add your user account to the libvirtd group using the following command:
   $ sudo adduser [your_username] libvirtd

3. Restart the libvirtd dæmon:
   $ sudo service libvirtd restart

4. Start the libvirtd command shell by issuing the following command:
   $ virsh

5. Issue the list command from the libvirtd command shell:
   An empty list of virtual machines will be displayed, indicating that the installation is OK.

Deploying the Skylight sensor: control Solution on a Server

To deploy a Skylight sensor: control within a KVM Hypervisor

1. Create an accedian directory in the libvirt image directory by issuing the following command in the Linux command shell:
   $ sudo mkdir -p /var/lib/libvirt/images/accedian

2. Copy the sensor: control (Skylight sensor: control) archive file to be deployed using scp or another secured FTP file transfer. (On MS Windows, you can use WinSCP.)

3. From your workstation, connect to the Linux server IP address with an SSH session and log in. (On MS Windows, you can use PuTTY.)

4. Find the directory where you transferred the Skylight sensor: control archive and use ‘cd’ to move to it.

5. Issue the following Linux shell command to extract the sensor: control (Skylight sensor: control) archive into the /var/lib/libvirt/images/accedian directory. The example below shows the filename for the Skylight sensor: control 2.0.0 build 7083 firmware release (adjust for your archive filename):
   $ sudo tar xjvf VCX_2.0.0_7083_KVM.tar.bz2 -C /var/lib/libvirt/images/accedian

6. The XML file extracted from the sensor: control (Skylight sensor: control) archive contains preconfigured parameters that define the correct domain in the KVM Hypervisor. However, you must edit the XML file to customize the configuration to your specific network requirements. At a minimum, replace the Local-1 (management port) and Local-2 ports (network port typically used to reach the Skylight modules) with the correct local interface names. You can do the customization directly on the server with the “sudo vi” or “sudo Skylight sensor: SFP compute” (easiest) command-line text editors that are typically pre-installed, as follows:

• Locate and replace the “Local-1” label with the server’s interface name used for the management of the Skylight sensor: control instance (ex.: eth0 or eno1).
  Locate and replace the “Local-2” label with the server’s interface name used to connect with the Skylight modules deployed in the network (ex.: eth1 or eno2).

7. The following example shows how to replace the Local-1 and Local-2 port labels in the XML file provided in the archive to the eth0 and eth1 server ports (look for the “<interface…” section).
   Before:
   
   After:
   
   The following example shows the CPU assignment in the XML file:
   

8. Define a new virtual machine (called “domain” in libvirt) by issuing the following command from the Linux command line. This command defines the VM instance in libvirt using the XML file as input. The example below shows the XML file for the Skylight sensor: control 2.0.0 build 7083 (adjust for your own version number):
   $ sudo virsh define /var/lib/libvirt/images/accedian/VCX_2.0.0_7083_
   KVM/VCX_2.0.0_7083_KVM.xml

9. From the Linux command shell, issue the following command to access the virtual shell prompt:
   $ virsh
   Welcome to virsh, the virtualization terminal.
   Type: 'help' for help with commands
   Type: 'quit' to quit
   virsh #

10. From the libvirt shell prompt, start the domain defined above by issuing the following command from the virtual shell prompt:
    virsh # start VCX_2.0.0_7083_KVM

11. To have the VM/Domain start automatically upon the physical server startup, use the autostart option:
    virsh # autostart VCX_2.0.0_7083_KVM

Connecting to the Skylight sensor: control

To connect to a Skylight sensor: control running on KVM from the CLI

1. From your workstation, connect to the Linux server IP address with an SSH session and log in (on MS Windows, you can use PuTTY).

2. From the Linux command shell, issue the following command to access the virtual shell prompt:
   $ virsh

3. Use the list command to review the running Domains/VMs:
   $ virsh # list --all

4. Use the console command to connect to the Skylight sensor: control. The console list can take either a numerical ID or the name of the Domain. The default Skylight sensor: control username is admin and the password is admin. Use Ctrl+] to disconnect from the console and return to the command-line.

To connect to a Skylight sensor: control running on KVM from the GUI

1. Launch the virt-manager application from your Application menu.

2. From the virt-manager application, select the virtual machine/domain you just defined.

3. Click Open (see below) to access the virtual machine’s console.

4. A console window providing the module’s current system messages is displayed. You will be prompted to log into the module; the default username is admin and the password is admin. The name of the console is the same as the name of the Domain in the list.

To configure the IP address for the Skylight sensor: control

1. A default IP address has been assigned to the application’s Management interface. You can use the CLI to assign a different static IP address to the application if needed by entering the following commands:
   login: admin
   password: admin
   interface edit Management dhcp disable
   interface edit Management address < ip address > netmask < netmask > gateway < gateway ip >
   interface show
   

   ---

   Note: Alternatively, you can use the CIDR notation to specify the netmask:

   interface edit Management address < ip address >/< CIDR Mask > gateway < gateway ip >

   ---

• The default username is admin and the password is admin.
• The default IP address is 192.168.1.254.

2. Access the instance by entering the IP address you assigned into the Web browser’s address bar.
3. Log in to the Skylight sensor: control’s Management Web interface when the Skylight sensor: control page appears. The default username is admin and the password is admin.
4. You can configure the following from the Management Web interface:

• SNMP trap forwarding
• Remote syslog
• Date and time.
  Access the System tab for all standard management settings.

Recovering a Failed Skylight sensor: control

If a Skylight sensor: control instance fails to start properly, use the following procedure to recover the instance so it becomes reachable again.

To recover a failed Skylight sensor: control within a KVM Hypervisor

1. Do one of the following to perform a backup of the Skylight sensor: control instance’s configuration files:

• Access the page System ▶ Maintenance ▶ Firmware of the Management Web interface
• Issue the equivalent CLI command configuration export
  You will need these files when restarting the recovered Skylight sensor: control instance.

2. Log in with SSH to the host Linux server using PuTTY or a similar tool and gain admin/root rights.

3. Shut down the running Skylight sensor: control virtual machine with the following command.
   

   ---

   Note: The shutdown command may take up to 30 seconds to cleanly stop the VM. Should a VM fail to respond to the shutdown command, you can force the power-off using the “destroy” command. Despite its forceful name, the “destroy” command simply forcefully powers-off the domain immediately, it doesn’t delete or otherwise harm the system.

   ---

4. Verify that you have the Skylight sensor: control archive.

5. From the command line, extract the qcow2 files from the Skylight sensor: control archive file. To do so, issue the following command from the command shell:
   root@Skylight :~# tar –xvf VCX_2.0.0_7083_KVM.tar.bz2 –wildcards *.qcow2
   VCX_2.0.0_7083_KVM/disk1.qcow2]
   VCX_2.0.0_7083_KVM/disk2.qcow2
   VCX_2.0.0_7083_KVM/disk3.qcow2
   VCX_2.0.0_7083_KVM/disk4.qcow2

6. Replace the VM’s hard drives by copying all *.qcow2 files (disk1.qcow2, disk2.qcow2, disk3.qcow2 and disk4.qcow2 files) extracted from the Skylight sensor: control archive to the directory of the Skylight sensor: control to be recovered. The following example updates the .qcow2 files for the Skylight sensor: control 2.0.0_7083 build:
   root@Skylight :~# cp /root/VCX_2.0.0_7083_KVM/.qcow2
   /var/lib/libvirt/images/accedian/VCX_2.0.0_7083_KVM/
   cp: overwrite ‘/var/lib/libvirt/images/accedian/VCX_2.0.0_7083_ KVM/disk1.qcow2’? y
   cp: overwrite ‘/var/lib/libvirt/images/accedian/VCX_2.0.0_7083_ KVM/disk2.qcow2’? y
   cp: overwrite ‘/var/lib/libvirt/images/accedian/VCX_2.0.0_7083_
   KVM/disk3.qcow2’? y
   cp: overwrite ‘/var/lib/libvirt/images/accedian/VCX_2.0.0_7083_
   KVM/disk4.qcow2’? y

7. From the virtual shell prompt, start the VM from its newly replaced storage. The following is an example of the command to use in the virtual shell prompt:
   virsh # start VCX_2.0.0_7083_KVM

8. Ensure that you run any required upgrades to restore the system to its pre-existing version.

9. Restore the backup when the Skylight sensor: control is running the same version as when the backup was taken.

Running a Skylight sensor: control session on Minimal Configuration

The idea behind running the TWAMP sessions using a 'minimum hardware configuration' lies in the need to provide a reference value and hardware/software base configuration that can be used to answer the question “What is the minimum configuration I need to run the sensor: control and TWAMP sessions?” that is posed to us both internally and by our customers.

To this effect we have looked at the current base values defined for the DL360 hardware and software configuration and have estimated the minimum hardware resources that we would need to support at least 100 TWAMP sessions.

Through these tests and results we can now safely indicate what is and is not supported when we are deploying NFV and NON NFV TWAMP Sessions for the minimum hardware reference.

The tests conducted have accounted for the impact of the virtualization layer through NON NFV PM and has also shown the difference in precision when HW assist—Skylight sensor: SFP compute 1G—is used during implementation.

The initial HW resource tested has also accounted for the fact that PCI pass-through may not be available or supported by the customer's minimum HW requirements. Testing with PCI pass-through using minimal HW resources will be conducted separately and added to this document when the tests have been completed.

NON NFV PM tests show the variance and impact of the CPU and Virtual Hypervisor domain on the TWAMP Packets and NFV PM tests show how precision and resource optimization can be achieved with Hardware assist.

Below are the Hardware and Software specifications as well as a brief on the functional details of how the actuator and reflectors were set up and the results that were achieved in terms of the number of TWAMP sessions that can be supported for the Hardware, Software, Session and Measurement limitations defined in the table below.

NON NFV-PM (350 TWAMP Sessions, 95% percentile Delay, 0% Packet Loss)
The following Skylight sensor: control, hardware, software and operating systems are required to host the Virtual Network Function (VNF) Controller that manages the virtualized network functions to support 350 TWAMP sessions simultaneously. The details for the Results and Baseline have been provided in the table below.

Non NFV PM = RESULTS

Hardware Details

Functional Details

• Baseline and test criteria: This configuration has been tested to support 350 TWAMP sessions with clear measurement results within specs. All results were within the expected 95% Percentile for Delay metrics and 0% was observed for Packet loss due to resource limitations.
• Reflector: A sensor: control instance installed on a DL360 standard configuration using VMware and a PCI pass-through port was used for the remote reflection entity. Tests were conducted to measure impact of TWAMP sessions on virtual and physical HW resources mentioned above. Thus, the test network connectivity is based on a direct ethernet link between the Actuator and the reflector.
• Actuator: A sensor: control instance installed on a piece of HW with the specifications mentioned above with no PCI pass-through or HW Assist (Skylight sensor: SFP compute SFP/Skylight sensor: module) was used to generate the packets defined in the baseline. It is important to note the SFP was directly connected to the SFP Cage of the HW resources. The measurements made here do not consider possible network delay for the VCE tunnel between the Skylight sensor: SFP compute and the sensor: control for remote PM Actuation. This is a different test and similar results have been already published regarding the impact of distance on the tunnel interface by the PLM team.

Important Note

Please note that the hardware and software specs are here to provide a reference and guidance to show the maximum number of TWAMP Sessions that can be supported under these conditions. It is here to give you a point of reference about what is possible with the HW and SW used during the tests.

Further testing using a PCI pass-through option is also being conducted and results will be added to the application note when the tests have been completed.