This chapter explains how to build (assemble) a QNX hypervisor system, and transfer a bootable image to a supported target platform.
When you build a QNX hypervisor, you don't recompile the hypervisor. If you have added or modified components (e.g., drivers or vdevs) you will of course have to compile them. However, the QHS and other QNX hypervisors are provided as binaries only. You don't compile them; you include them unmodified when you assemble a bootable image with your hypervisor system.
The instructions in this chapter describe three ways to build a QHS or other QNX hypervisor system:
The overviews below include links to the step-by-step instructions in this chapter.
Before you begin to work, check that your board's hardware and firmware support virtualization.
Even if your board hardware supports all the virtualization capabilities needed to run a QNX virtualized system, the firmware on the board may not enable or may even expressly disable some of these capabilities, in which case you won't be able to run the hypervisor.
You may wish to contact your board vendor to confirm that the board you are considering supports all the virtualization capabilities you'll need, and that you have the appropriate firmware on the board.
To build a hypervisor system, you need to configure and build both the hypervisor host and its guests. These instructions assume that you know:
With this method, you start with the BSP for a board that meets the hardware requirements to support the 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 guests 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.
For step-by-step instructions on how to use this method, see Building the host.
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.
This method is probably the best method to use the first time you build a hypervisor system. It will build a system you can use to get familiar with the hypervisor and its capabilities.
For step-by-step instructions on how to use this method, see The HHBSP framework and Building in the HHBSP.
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 specific locations. You modify 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 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 step-by-step instructions on how to use this method, see The HHBSP framework and Building in the HHBSP.