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 Hardware Specifications of the Routing Engines with VM Host Support.
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.
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.
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 Table 1 for more information on hardware specifications of the Routing Engines with VMHost support.
| Model Number | Supported on Device | Specifications |
|---|---|---|
|
RE-ACX-5448 |
ACX5448 |
|
|
EX9200-RE2 |
EX9204, EX9208, and EX9214 |
|
|
RE-S-1600x8 |
MX204 |
|
|
RE-S-X6-64G |
MX240, MX480, and MX960 |
|
|
RE-S-X6-128G |
MX240, MX480, and MX960 |
|
|
REMX2008-X8-64G-LT, |
MX2008 |
|
|
REMX2008-X8-128G-S |
|
|
|
REMX2K-X8-64G |
MX2020 and MX2010 |
|
|
RE-S-1600x8 |
MX10003 |
|
|
JNP10K-RE1, JNP10K-RE1-LT, and JNP10K-RE1-128 |
MX10008 MX10004 |
|
|
JNP304-RE-S |
MX304 |
|
|
RCBPTX |
PTX3000 |
RCB combines the functionality of a Routing Engine, Control Board, and Centralized Clock Generator (CCG) |
|
RE-PTX-X8-64G |
PTX5000 |
|
|
RE-PTX10002-60C |
PTX10002-60C |
|
|
RE-QFX10002-60C |
QFX10002-60C |
|
|
SRX5K-RE3 |
SRX5000 |
|
Platform support depends on the Junos OS release in your installation.
See Also
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
- Hardware Assisted Paravirtualized Guest Junos OS
- Guest Junos OS to Serve as the Administrative Framework
- Storage Partitioning and Redundancy
- NTP and Time Zone
- Autorecovery
- Handling Reboot and Power Off
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.
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 |
| 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 4 illustrates the storage allocation of the guest VM.
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.
A virtual disk of size 32-GB is allocated from VM partition to the guest Junos OS as var-config.disk.
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:
host@router> show chassis routing-engine 0 | match "Last reboot reason”
Last reboot reason 0x4000:VJUNOS reboot
host@router> show vmhost uptime re0 | match “Vmhost last reboot reason”
Vmhost last reboot reason: 0x2000:hypervisor reboot
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.