Building guests

When you build guests to run in a QNX virtualized environment, you must build them for the appropriate hardware architecture, and configure the VMs in which they will run.

You need to have the build environment and tools that correspond to the hypervisor and the guests you are building (see Supported development hosts).

When you have made your changes to your guest or guests and rebuilt it (or them), you will need to:

  1. Create a disk image that includes:

    • the QHS host IFS in a bootable partition
    • the guest or guests in a data partition
  2. Transfer the bootable image to your target (see Transferring the disk image).

Validate the guests without the hypervisor

It is much easier to identify and debug problems on a non-virtualized system than on a system running a hypervisor. If possible, before you add a guest to your hypervisor system, you should build and test it running directly on the hardware.

  1. If you are building a QNX guest, follow the instructions in the BSP User’s Guide to build the BSP for your hardware platform and copy it to your target.

    If you are building a non-QNX guest, following the instructions for building that guest and copy it to your target.

  2. Boot your system and make sure it runs as required.
  3. In particular, make sure that all the devices you will configure as pass-through devices to a guest are functioning properly.

    Problems with these devices are easier to resolve in a non-virtualized system than in a system with a hypervisor.

  4. Repeat for each of the OSs you will run as a guest in your hypervisor system.

When you are satisfied that all the OSs you will run as guests function as required in a non-virtualized system, you are ready to add them to your hypervisor system image and copy them to your target to run as guests.

Note:

It may not always be possible to test a guest without the hypervisor (i.e., running directly on the hardware). For example:

  • The guest may use para-virtualized devices, which by definition don't exist as hardware.
  • The startup driver required for the guest may not work directly on the board; this can usually be corrected by changing the buildfile for the guest to (temporarily) use the appropriate driver for starting up directly on the board.

Guest images

The hypervisor can launch guests placed on the system as bootable images in the following formats:

When you have rebuilt your guests, use a familiar method to transfer them to your hardware target platform (see Transferring the disk image).

Configuring the VMs

Each guest in a hypervisor system is hosted in a hypervisor qvm process. When it is started, each instance of the qvm process reads its specified configuration file and assembles a VM from the components specified in this file. This VM becomes the virtual environment in which the guest runs.

If you change anything in your guest that accesses hardware (physical or virtual), you need to ensure that the qvm configuration file for the VM that will host the guest is properly configured.

When building a guest to run in a QNX virtualized environment, it is important to remember that each guest must be configured to match the VM in which it will run. This means that it must have the drivers it needs to access devices, whether these devices are virtual or pass-through. You must, therefore, ensure that your guest has the drivers it needs for the devices it will use, and that these drivers are configured in the VM to be where the guest expects them to be in the VM.

In a QNX system, board-specific drivers and other components are brought into the build through BSPs. This is true for a QNX OS that will run in a VM, just as it is for a QNX OS that will run directly on hardware.

For both ARM and x86 architecture hardware platforms, you will need the BSP for your supported hardware platform to build the hypervisor host domain, and a hypervisor guest BSP to build each guest. These are available for QOS 2.1 and QNX Neutrino OS 7.0.4+ guests. If you add new devices for your guest, you will probably need to add the appropriate new drivers to the BSPs, and rebuild the guest with them.

What is true for QNX guests is also true for non-QNX guests: the VM must be configured to present to the guest the virtual environment the guest OS expects to find (i.e., the hardware components it has been built to use). The only difference is that QNX OSs (including QNX OSs that will run as guests in virtualized environments) use BSPs to bring in the architecture-specific and board-specific components, while other OSs may use other mechanisms to achieve the same end.

For more information, see Assembling and configuring VMs in the Configuration chapter.