Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

VM Host Overview (Junos OS)

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 listed in Table 1

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 Routing Engines with VM Host support. 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 Routing Engines with VM Host SupportArchitecture of Routing Engines with VM Host Support

Routing Engines with VM Host Support

The Routing Engines with VM host support 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. The VMs must be instances of Junos OS. Third-party VMs are not supported on these Routing Engines. Each VM runs its own operating system image and applications that can be different from that of another VM running on the same host.

Note:

Only Junos OS VM are supported. You cannot run third party VMs on these Routing Engines.

On the Routing Engines with VM host support, 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 the following table for more information on hardware specifications of the Routing Engines with VMHost support.

Table 1: Hardware Specifications of the Routing Engines with VM Host Support
Model Number Supported on Device Specifications

RE-ACX-5448

ACX5448

  • High-performance 1.6-GHz Intel 8 Core X86 CPU

  • 32-GB two DIMM DRAM

  • Two 100-GB SATA SSD

EX9200-RE2

EX9204, EX9208, and EX9214

  • Six-core, 2-GHz Intel processor

  • 64-GB of DRAM and dual front pluggable SSDs, each providing 64-GB of storage for Junos OS images and logs.

RE-S-1600x8

MX204

  • High-performance 1.6-GHz Intel 8 Core X86 CPU

  • 32-GB DDR4 RAM

  • 100-GB SATA SSD

RE-S-X6-64G

MX240, MX480, and MX960

  • 6-core Haswell CPU

  • Wellsburg PCH-based Routing Engine with 64-GB DRAM and two 64-GB solid-state drives (SSDs)

RE-S-X6-128G

MX240, MX480, and MX960

  • 6-core Haswell CPU

  • Wellsburg PCH-based Routing Engine with 128-GB DRAM and two 128-GB solid-state drives (SSDs)

REMX2008-X8-64G-LT,

MX2008
  • 8-core Haswell CPU

  • Wellsburg PCH-based Routing Engine with 64-GB DRAM and two 100-GB solid-state drives (SSDs)

REMX2008-X8-128G-S

  • 8-core Haswell CPU

  • Wellsburg PCH-based Routing Engine with 128-GB DRAM and two 200-GB solid-state drives (SSDs)

REMX2K-X8-64G

MX2020 and MX2010

  • 8-core Haswell CPU

  • Wellsburg PCH-based Routing Engine with 64-GB DRAM and two 64-GB SSDs

RE-S-1600x8

MX10003

  • High-performance 1.6-GHz Intel 8 Core X86 CPU

  • 64-GB DDR4 RAM

  • 100-GB SATA SSD

JNP10K-RE1, JNP10K-RE1-LT, and JNP10K-RE1-128

MX10008

MX10004

  • High-performance 2.2-GHz Intel 10 Core X86 CPU

  • 64-GB DDR4 RAM

  • Two 200-GB SATA SSD

JNP304-RE-S

MX304

  • 8-core, Intel Icelake Based Multicore Processor CPU

  • 128-GB of DRAM

  • Two 200-GB SATA SSD

RCBPTX

PTX3000

  • Wellsburg PCH-based Routing Engine with 64-GB DRAM and two 64-GB SSDs

  • Multi-core Haswell CPU

RCB combines the functionality of a Routing Engine, Control Board, and Centralized Clock Generator (CCG)

RE-PTX-X8-64G

PTX5000

  • 8-core Haswell CPU

  • Wellsburg PCH-based Routing Engine with 64-GB DRAM and two 64-GB SSDs

  • New Control Board CB2-PTX

RE-PTX10002-60C

PTX10002-60C

  • High-performance 1.6-GHz Intel 8 Core X86 CPU

  • 32-GB DDR4 RAM

  • Two 50-GB SATA SSD

RE-QFX10002-60C

QFX10002-60C

  • High-performance 1.6-GHz Intel 8 Core X86 CPU

  • 32-GB DDR4 RAM

  • Two 50-GB SATA SSD

SRX5K-RE3

SRX5000
  • 6-core Haswell CPU

  • 128-GB of DRAM

  • Two 128-GB solid-state drives (SSDs)

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 PartitioningSSD 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:

Table 2: SSD Size of Routing Engines
Devices Routing Engine model number SSD size
ACX5448

RE-ACX-5448

2x100GB

EX9204, EX9208, and EX9214 EX9200-RE2 2x64GB
MX204 RE-S-1600x8

2x50GB

MX240, MX480, and MX960

RE-S-2200X6-64G-S

2x50GB

RE-S-X6-64G-LT

2x50GB

RE-S-X6-128G-S

2x200GB

MX2008

REMX2008-X8-64G-LT

2x100GB

REMX2008-X8-128G-S

2x200GB

MX2010 and MX2020

RE-MX2K-X8-64G

2x100GB

RE-MX2K-X8-64G-LT

2x100GB

RE-MX2K-X8-128G-S

2x200GB

MX10003 RE-S-1600x8 2x50GB

MX10008

MX10004

JNP10K-RE1, JNP10K-RE1-LT, and JNP10K-RE1-128

2x200GB

PTX3000 RCBPTX 2x64GB
PTX5000 RE-PTX-X8-64G 2x64GB

PTX10002-60C

RE-PTX10002-60C

2x50GB

QFX10002-60C

RE-QFX10002-60C

2x50GB

SRX5000 SRX5K-RE3

2x128GB

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 SSDsHost 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 VMPartitioning 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 SSDHost 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 RoutersGuest 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.

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

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