Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

VM Host Overview

 

What Are VM Hosts?

Starting in Junos OS Release 16.1, virtualized Routing Engines are supported that not only provide increased control plane scalability and performance but also provide virtualization capabilities to the Junos OS infrastructure. These virtualized Routing Engines, or VM hosts, are the Routing Engines RE-MX-X6, RE-MX-X8, RE-PTX-X8, RE-QFX10002-60C.

Note

VM hosts only run Junos OS with Upgraded FreeBSD.

The rest of this section describes the architecture of VM hosts. For more information on VM hosts, see the chapters on System Back Up and Recovery, Installing Software, Installing Firmware, and so on in this guide.

Figure 1 illustrates the architecture of RE-MX-X6, RE-MX-X8, RE-PTX-X8, RE-QFX10002-60C Routing Engines. It comprises the following components:

  • The hardware layer

  • The operating system and hypervisor layer.

  • The host utilities and Junos VM guest layer.

The server at the hardware layer contains the physical network interface cards (NICs), CPUs, memory, and Ethernet management port. The NICs support hardware virtualization based on single root I/O virtualization (SR-IOV). With SR-IOV, the physical NICs (known as a physical functions) are managed by the host, while the virtual functions are managed by the guest OS. Over the hardware layer, a Linux-based OS provides the host environment along with the kernel-based virtual machine (KVM) and Quick Emulator (QEMU). This host OS manages the boot complex, CPU memory storage, and various other hardware components such as the physical functions. Junos OS runs as guest OS, manages the virtual functions, and serves as the administrative framework. Additionally, it also provides the interface for managing the host and the hypervisor.

The additional applications and utilities running on the host OS assist in providing the following functionality:

  • Facilitating communication between host OS and guest OS.

  • Triggering appropriate execution of the host OS based on the command and configuration on the guest Junos OS.

  • Extending the VM management functionality to provide features such as autorecovery.

Figure 1: Architecture of RE-MX-X6, RE-MX-X8, RE-PTX-X8, RE-QFX10002-60C, and RE-PTX10002-60C Routing Engines
 Architecture of RE-MX-X6,
RE-MX-X8, RE-PTX-X8, RE-QFX10002-60C, and RE-PTX10002-60C Routing
Engines

Routing Engines with VM Host Support

The Routing Engines RE-ACX-5448, RE-MX-X6, RE-MX-X8, RE-PTX-X8, RE-QFX10002-60C, and RE-PTX10002-60C not only provide increased control plane scalability and performance but also provide virtualization capabilities to the Junos OS infrastructure to support greater computing demands.

Virtualization enables multiple instances of operating systems, called guests, to run concurrently on the host and share virtualized hardware resources. A guest is a virtual machine (VM) that runs on a hypervisor-based host and shares its resources. A host is a virtualized software whose hypervisor allows multiple guest VMs to run on it concurrently and share its resources. A VM can be an instance of Junos OS or any compatible third-party VM. Each VM runs its own operating system image and applications that can be different from that of another VM running on the same host.

On the RE-ACX-5448, RE-MX-X6, RE-MX-X8, RE-PTX-X8, RCBPTX, RE-QFX10002-60C, and RE-PTX10002-60C Routing Engines, one instance of Junos OS runs as a VM over a Linux-based host (VM host) and serves as the VM operating in the administrative context. Junos OS manages all configurations, chassis control, communication with the host OS, and user interface command execution, thus providing near-native Junos OS experience to the end user.

See Hardware Specifications of the RE-MX-X6, RE-MX-X8, RE-PTX-X8, RCBPTX, RE-QFX10002-60C, and RE-PTX10002-60C Routing Engines for more information on hardware specifications of the Routing Engines with VMHost support.

Note

Platform support depends on the Junos OS release in your installation.

Salient Features of the Routing Engines with VM Host Support

While continuing to provide the same end-user experience, the new architecture provides a better performing Routing Engine.

The following are the salient features of the Routing Engines:

Platform Virtualization

Platform virtualization by the introduction of a middle layer that comprises the host OS and the KVM (or the hypervisor).

  • Enables support for multiple instances of Junos OS to be run concurrently.

  • Enables support for third-party software to be run directly.

Hardware Assisted Paravirtualized Guest Junos OS

Provides the user with the benefits of platform virtualization along with the default performance and functionality. Paravirtualization is a virtualization technique in which a software component similar to the underlying hardware component resides in the VM and interacts with the hypervisor to execute many operations. In contrast to full virtualization, this technique reduces the overhead of virtualization in the VM.

Guest Junos OS to Serve as the Administrative Framework

The configurations, chassis control, communication with the host OS, and user interface command execution are managed by the guest Junos OS.

Storage Partitioning and Redundancy

An Internal solid-state drive (SSD) is used as boot media for operating the Routing Engine. Additional options such as USB storage and network boot are available for installation and recovery purposes. A set of two 50-GB SSDs is available for normal functioning of the Routing Engine. The Routing Engine requires both the SSDs to be functional. Storage partitioning is important for debugging the Routing Engine, for new installations, and for SSD replacement.

Of the two SSDs, one operates as the primary SSD and the other as the backup SSD. Two sets of software boot images—the current set and the alternate (or previous) set are available on the primary SSD. The system boots from the current set, while the alternate set contains the previous version of the software boot image. After a software upgrade, the new version of the software is available on the alternate set. When the device is rebooted after the upgrade, the alternate set becomes the new current set and the current set, which now carries an older version of the software image, becomes the alternate set. You can switch to alternate set by using the request vmhost software rollback command. Until a software upgrade or a software rollback is performed, the system is programmed to boot from the same set of images on the disk.

Both the SSDs are partitioned to provide host boot partition, root partition, and partition for the guest image storage. The host boot partition contains the boot loader, which is the software responsible for booting the OS, Linux kernel, and RAM file system. The root partition contains the root file system for the host OS.

Figure 2 shows the partitioning of SSDs.

Figure 2: SSD Partitioning
 SSD Partitioning

Each SSD partition contains more than one set of fully functional host software. In case of a boot failure on the primary SSD, the router can boot by using the snapshot available on the alternate SSD. This snapshot can be generated by a fresh installation or by using the request vmhost snapshot command.

Starting in Junos OS Release 18.1R1, the Routing Engines on the MX240, MX480,MX960, MX2010, MX2020, and PTX5000 support Secure Boot.

Starting in Junos OS Release 18.2R1, the Routing Engine on the MX2008 supports Secure Boot.

The Routing Engines with Secure Boot support have both RAM and SSD upgraded to 128GB and 2x200GB respectively. The increased SSD size facilitates increased storage of core and log files.

The following table provides information on the SSD size for different Routing Engines:

Devices

Routing Engine model number

SSD size

MX240, MX480, and MX960

RE-S-2200X6-64G-S

2x50GB

RE-S-X6-64G-LT

2x50GB

RE-S-X6-128G-S

2x200GB

PTX5000

RE-P-2200-64G-S

2x50GB

RE-PTX-X8-128G-S

2x200GB

MX2010 and MX2020

RE-MX2K-X8-64G

2x100GB

RE-MX2K-X8-64G-LT

2x100GB

RE-MX2K-X8-128G-S

2x200GB

MX2008

REMX2008-X8-64G-LT

2x100GB

REMX2008-X8-128G-S

2x200GB

QFX10002-60C

RE-QFX10002-60C

2x50GB

PTX10002-60C

RE-PTX10002-60C

2x50GB

MX10008

RE-X10

2x200GB

You can use the show vmhost hardware command to display the increased RAM size, SSD size, and other hardware information.

The following illustrations explains the partition of the host to facilitate the increased storage of core files and log files. Figure 3 illustrates the partition of the host on MX240, MX480, MX960, MX2008, and PTX5000 routers with the 200-GB SSDs. A virtual disk of size 56-GB will be allocated from VM partition to the guest as var-config.disk. The current size of this disk is 15-GB.

Figure 3: Host partition table for Routing Engines with 200-GB SSDs
 Host partition table for
Routing Engines with 200-GB SSDs

Figure 4 illustrates the storage allocation of the guest VM.

Figure 4: Partitioning of the guest VM
 Partitioning of the
guest VM
Note

For Routing Engines with 50GB SSD, the host partition remains as–is.

Figure 5 and Figure 6 illustrates the host partition table and the storage allocation of the guest VM for the MX2010 and MX2020 routers respectively.

Figure 5: Host partition table for Routing Engines on MX2010 and MX2020 routers with 100GB SSD
 Host partition
table for Routing Engines on MX2010 and MX2020 routers with 100GB
SSD

A virtual disk of size 32-GB is allocated from VM partition to the guest Junos OS as var-config.disk.

Figure 6: Guest VM partition on MX2010 and MX2020 Routers
 Guest VM partition on
MX2010 and MX2020 Routers

A reformatting of the SSD is required to implement the enhancement of the /var size. The upgrade can be implemented by any of the following methods:

  • Installation from SSD Disk2-Boot the host OS from the backup disk (SSD Disk2) and install the junos-vmhost-install-x.tgz image.

  • Installation from USB

NTP and Time Zone

The date and time zones are synchronized from the administrative guest Junos OS to the host OS. Therefore, the timestamps in system log files of Junos OS and the host OS are synchronized.

Autorecovery

The automatic recovery (autorecovery) feature provides the following functions:

  • Detecting corruptions in disk partitioning during system startup and attempting to recover partitions automatically

  • Detecting corruptions in the Junos OS configuration during system startup and attempting to recover the configuration automatically, thereby ensuring that the operations and management are not disrupted.

  • Detecting corruptions in Junos OS licenses during system startup and attempting to recover licenses automatically.

During the process of recovery, the host OS tries to launch the Junos VM from the image available on the primary disk. However, if the Junos VM fails to launch, the host OS attempts to launch the Junos VM from the snapshot of the host OS image and Junos OS image available in the backup disk, provided request vmhost snapshot was the last operation performed. If the backup disk does not contain the snapshot, the host OS attempts to launch the Junos VM from the software available in the alternate set in the primary disk, provided request vmhost upgrade was the last operation performed.

The autorecovery feature is enabled by default on the guest OS. If you need to disable autorecovery—for example, to examine the failure state for debugging—use the following command:

user@host> set vmhost no-auto-recovery

Handling Reboot and Power Off

You can reboot the Routing Engine by using the request vmhost reboot command. This command reboots the Routing Engine by rebooting both the guest Junos OS and the host OS. However, reboot of the Routing Engine can be triggered because of various reasons. The events or the reasons that trigger a host OS reboot are different from those that trigger a guest OS reboot.

Guest OS reboot implies that only the Junos OS is rebooted, and that the host OS is up and running. The following are a few of the reasons that trigger a guest OS reboot:

  • Reboot due to panic

  • VJUNOS reboot—Guest OS reboot after a shutdown.

  • VJUNOS watchdog from host—Guest reboot due to emulated watchdog timer expiry

Host OS reboot implies that both the host OS and the guest OS (here, Junos OS) are rebooted. The following are a few reasons that trigger a host OS and guest OS reboot:

  • Hypervisor reboot

  • Power cycle or power failure

  • Reboot due to exception.

  • Reset-button reset—Reboot triggered by the pressing of the reset button on the front panel.

  • Thermal shutdown

  • Watchdog—Reboot due to PCH watchdog timer expiry

You can find the reason for the reboot by using the show chassis routing-engine command or the show vmhost uptime command.

For example:

If the Routing Engine finishes booting and if you need to power off the router again, run the request vmhost power-off command. If you want the Routing Engine to reboot, use the request vmhost reboot command.

Release History Table
Release
Description
Starting in Junos OS Release 18.2R1, the Routing Engine on the MX2008 supports Secure Boot.