Deploy and Manage vJunosEvolved on KVM

SUMMARY Read this topic to understand how to deploy and manage the vJunosEvolved instance after you install it on KVM.

This topic describes:

How to bring up vJunosEvolved on the KVM servers using libvirt.
How to choose the amount of CPU and memory, set up the required bridges for connectivity, and configure the serial port.
How to use relevant XML file sections for the configurations and selections listed earlier for deployment.

Note:
Download the sample XML file and the vJunosEvolved image from the Juniper website.

Set Up the vJunosEvolved Deployment on the Host Server

This topic describes how to set up the vJunosEvolved deployment on the host server.

Note:

This topic highlights only a few sections of the XML file that is used to deploy vJunosEvolved through libvirt.

The entire XML file vJunosEvolved.xml is available for download along with the VM image and associated documentation on the lab download page.

Install the packages mentioned in the minimum software requirements section, if they are not already installed. See Minimum Hardware Requirements for vJunosEvolved.

Create a Linux bridge for RPIO, Packet Forwarding Engine (PFE) links (Routing Engine-COSIM bridges), and WAN interfaces.

For example, et-0/0/0, et-0/0/1, and so on, of vJunosEvolved that you plan to use.

# ip link add PFE_LINK type bridge

# ip link add RPIO_LINK type bridge

# ip link add et000 type bridge

# ip link add et001 type bridge

Note:
Currently, you must mention the PFE and RPIO bridge links for vJunosEvolved in the orchestration because the EVO architecture does not maintain ethernet interface numbering for these bridge links and may incrorrectly consider the COSIM's WAN ineterfaces as the bridges, affecting the traffic path.
Make a live disk copy of the provided QCOW2 vJunosEvolved image.

# cd /root

# cp vJunosEvolved-<release>.qcow2 vJunosEvolved-<release>-live.qcow2

# chmod u+w vjunosEvolved-<release>-live.qcow2

Make a distinct copy for each vJunosEvolved that you plan to deploy. Making a live copy ensures that you do not make any permanent changes on the original image. The live image must also be writable by the userid deploying vJunosEvolved—typically the root user.
Specify the number of cores provided to vJunosEvolved by modifying the following stanza. For the default memory of 8GB required by vJunosEvolved, use the following code snippet:
Note:
A sample vJunosEvolved.xml file is also available with the posted vJunosEvolved image. This document refers to key snippets from that sample file to illustrate the stanzas the you need to edit in the XML file.

Use the sample vJunosEvolved.xml snippet files that are available with the posted vJunosEvolved image to prevent errors.

The following codeblock provides an example CPU XML snippet, where the default number of cores required is 4, which is sufficient for most applications. You can increase the number of cores added, by modifying the below stanza.
You can increase the memory if needed. It also shows the name of the specific vJunosEvolved being spawned, which is vJunosEvo in this case.
Modify the name and location of your vJunosEvolved image.
Note:
For libvirt and QEMU-KVM, each vJunosEvolved VM on the host needs to be provided with its own uniquely named QCOW2 image.

Use the following XML snippet to specify the name and location for your vJunosEvolved image:
Create the configuration disk image.
# ./make-config.sh <juniper.conf> <config.qcow2>
The vJunosEvolved accepts an initial configuration by connecting a second disk to the VM instance that contains the configuration. Use the provided script make-config.sh to create the disk image.

The XML file references this configuration drive as shown below:
Note:
If you do not prefer initial configuration, then remove the above stanza from the XML file.

Create a Linux bridge for each of the ports you specify in the XML file.

The port names are specified in the following codeblock.

The convention for vJunosEvolved is to use et00x. In the following example, et000 and et001 map to the Junos Evolved et-0/0/0 and et-0/0/1 interfaces respectively.

Provide a unique serial console port number for each vJunosEvolved on your host server.

In this sample sinppet "8610" is chosen.

Create channelized or non-channelized interfaces.

The “channelized=yes” in the command line arg provides an option to create channelized WAN interfaces. If nothing mentioned or value of “no” mentioned, then non-channelized interfaces are initialized at COSIM.

Create vJunosEvolved VM using the vJunosEvolved.xml file.
This creates the first vJunosEvolved VM. The subsequent VMs can be vJunosEvolved2,vJunosEvolved3 and so on.
Domain vJunosEvolved created from vJunosEvolved.xml

Verify the vJunosEvolved VM

This topic describes how to verify whether vJunosEvolved is up and running.

Verify if the vJunosEvolved is up and running.

Note:
The XML file for download is “vJunosEvolved.xml”. If you are creating more than one instance, then the domain and XML and live disk files names must be unique.

But for a single instance it looks like this:
Connect to the serial console of the Routing Engine VM.
You can find the port to connect to from the XML file.

Note:
The telnet port number needs to be unique for each vJunosEvolved VM residing on the host server.
Verify whether the ET interfaces that you had specified in your XML file are up.
show interfaces terse

For example if "et000" and "et001" were specified in your XML file, then the et-0/0/0 and et-0/0/1 interfaces should be in "up" state. Other interfaces also shows up, but those interfaces can’t pass traffic.
Verify whether a VNET interface under each corresponding "et" bridge is configured.
Use the brctl command on the host server once vJunosEvolved is started. This command shows a vnet interface under each corresponding "et" bridge:

ON THIS PAGE

Deploy and Manage vJunosEvolved on KVM

Set Up the vJunosEvolved Deployment on the Host Server

Verify the vJunosEvolved VM