| Updated: October 28, 2024 |
To configure the VMs in which guests run, you can use command-line input or configuration files to configure the qvm processes that create the VMs.
See the “VM Configuration Reference” chapter for descriptions and configuration instructions for the individual VM components, and the “Virtual Device Reference” chapter for the vdevs.
Every guest in a virtualized system requires a virtual machine (VM) in which it can run. Every VM is created by an instance of a qvm process, which is a hypervisor host domain process. To configure a VM, you configure the qvm process that creates it. Every qvm process instance should have its own configuration input. This input can be presented in one or many configuration files, via the command line, or by a combination of command-line input and files (see “Starting VMs”).
The VM must match the guest that will run in it: architecture, board-specifics, memory, CPUs, devices, etc. You can think of VM configuration as building or assembling a hardware platform. But instead of assembling physical memory cards, CPUs, etc., you specify the virtual components of your machine, which a qvm process will create and configure according to your specifications.
The rules about where things appear are the same as for a real board:
In short, put into the VM configuration everything that the guest software requires be present on its “board”, and put each component at the location where the guest expects to find it.
On ARM platforms, you have a bit more flexibility, because your guest can query the Flattened Device Tree (FDT) for information such as the location of the vGIC registers.
When configuring a VM, always consider:
A poorly considered configuration, especially the vCPU configuration, can have significant undesired consequences. For example, if you configure two vCPUs in a VM to share the same physical CPU (two vCPUs pinned to the same core), your guest may see unexpected behavior: timeouts, delays, spin loops never returning, etc. This problem may worsen if the two vCPUs have different priorities; the lower priority vCPU may never get a chance to run.
When it starts, a qvm process reads its configuration input and uses this information to define the virtual hardware it creates for a VM. Thus, when you add, remove, or edit entries in a VM configuration, you are adding, removing, or editing virtual hardware in the VM. You are doing the equivalent of plugging in a memory card or a serial device, etc. into a physical board.
A qvm process instance reads its configuration input in a single pass, from start to finish. If you define a component more than once, your VM will be configured with either multiple instances of the same component (if multiple instances are permitted) or the last configuration information read for the component.
Since VM configuration is complex, we recommend you use configuration files. The names of the VM configuration (qvm process) files provided with QNX hypervisors use the following nomenclature: guest.qvmconf, where guest is the guest OS (e.g., qnx71, linux44) that will run in the VM configured by this file.
See the following topics for information about:
A VM configuration example is given in “VM configuration file example” in this chapter. Information about starting guests is provided in “Starting a guest” in the “Booting and Shutting Down” chapter.
Typically, we place the VM configuration files at /guests/guestos/, where guestos identifies the guest OS (e.g., /guests/qnx71/qnx71-guest.qvmconf).
This location is arbitrary. You can put the configuration files anywhere you want on the target, and maintain several copies for different configurations while you are developing your system. Just be sure to point each qvm process instance to the configuration file you want to use for each guest.