Assembling a Hypervisor System and Its Components

This chapter explains how to build a QNX Hypervisor system, using the hypervisor host BSP (HHBSP) framework, or independently of the HHBSP.

To build a hypervisor system, you need to configure and build both the hypervisor host and its guests. These instructions assume that you know:

The instructions in this chapter describe three ways to build a QNX Hypervisor system:

QNX provides reference images for a number of supported hardware platforms. We recommend that you start with one of these reference images and become familiar with the QNX Hypervisor before you attempt to build your own system (see the “Getting Started” chapter).

The reference images include components (e.g., some of the vdevs) that you may not need in your finished system, as well as processes, network interfaces, etc. to support the guests and demonstrate key hypervisor system capabilities. When you are getting to know the hypervisor, you may decide to remove some or all of these. For example, you could build a minimalist system that would include only the hypervisor host with a one VM, one guest to run in the VM, and a few vdevs to allow you to do something in the guest, then use this system as a starting point for developing a more complex system.

You can copy the IFSs for the host and for the guests to the target separately, or you can build the entire system and copy a single image with the host and its guests (see “Creating and transferring a hypervisor disk image” in this chapter).

QNX SDP 7.0 or QOS 2.0?

The instructions in this chapter assume that you have QNX SDP 7.0 or QNX OS for Safety 2.0 (QOS 2.0) installed on your development host.

If you use QNX SDP 7.0, you must use the standard variant of the virualization module (libmod-qvm.a).

If you use QOS 2.0, you must use the libmod_qvm-qos_capable.a variant of the virtualization module. You can download this module as a separate package from the QNX Software Center. It is made available as convenience to allow you to develop a safety-related hypervisor system, but adding it to a QOS 2.0 build compromises the QOS 2.0 safety certification.

DANGER

QNX Hypervisor 2.0 is not a safety-certified product. It must not be used in a safety-related production system.

If you want to run the hypervisor in a safety-related system, you must obtain the appropriate QNX Hypervisor variant when it becomes available.

Your QNX Hypervisor package installation will update your QNX SDP 7.0 and the QNX Neutrino OS 7.0 components you'll use to build the hypervisor host, as well as add the hypervisor and other required modules, but you still need to start with QNX SDP 7.0 or QOS 2.0 installed on your development host.

If you are using QOS 2.0, when you read “SDP 7.0” in the instructions, you can substitute “QOS2.0”, unless the instructions explicitly state otherwise.

Build a hypervisor in the HHBSP with the default settings

This method for building a hypervisor uses:

The diagram below illustrates these first two methods, and how they use different BSPs: the board-agnostic HHBSP with a board-specific BSP to create an IFS for the hypervisor host, a QNX guest BSP to create an IFS for a QNX guest, and a Linux package to create an image for a Linux guest.

Figure 1. An illustration of how the HHBSP framework is used to create a QNX Hypervisor system.

This method allows you to quickly modify and rebuild your QNX Hypervisor 2.0 reference images. It is probably the best method to use the first time you build a QNX Hypervisor system. It will build a system you can use to get familiar with the hypervisor and its capabilities.

For instructions on how to use this method to build a hypervisor, see “The HHBSP” and “Building in the HHBSP”.

Build a hypervisor in the HHBSP with BSPs at other locations

This method for building a hypervisor also uses the HHBSP framework, but doesn't require you to place all the components (board-specific BSPs, guest BSPs) in their default locations. You modify the the configuration file (configure.mk) or use the command line to set environment variables so you can leave BSPs outside the HHBSP framework and simply point to them.

This is probably the best method to use for prototyping when you start developing a QNX Hypervisor project. You can have different BSPs in convenient locations, change them, and simply change environment variables to point to them when you want to try different configurations and components.

For instructions on how to use this method to build a hypervisor, see “The HHBSP” and “Building in the HHBSP”.

Build a hypervisor outside the HHBSP framework

This method doesn't use the HHBSP framework. With this method, you start with the BSP for a board that meets the hardware requirements to support the QNX Hypervisor, edit the buildfile to include the hypervisor module, vdevs, and other components, and otherwise configure your build, then build the host in whatever location is convenient. You can then assemble the host and its guest into an image and transfer it to your target.

This is a good method to use when you are preparing a production system, as it gives you full control of the contents and configuration of your finished system. Of course, you can always refer to the HHBSP framework for guidance.

Figure 2. An illustration of how a modified board-specific host BSP for the host, a BSP for a QNX guest, and a Linux package are used to create a QNX Hypervisor system.

For instructions on how to use this method to build a hypervisor, see “Using your own board-specific BSP for the host”.