To configure the VMs in which guests run, you use a qvm configuration file 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. A qvm process 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 a configuration file or several configuration files, or via the command line, or by a combination of command-line input and files (see “Starting VMs”).
The VM in which a guest will run must match the guest: architecture, board-specifics, memory and CPUs, devices, etc. You can think of VM configuration as building or assembling a hardware platform. The difference is that 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 it 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 thought-through configuration, especially 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 experience 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 the information in this file to define the virtual hardware it creates for a VM. Thus, when you add, remove, or edit entries in the configuration file, 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 (e.g., qnx7.qvmconf). The names of the VM configuration files provided with QNX hypervisors use the following nomenclature: guest.qvmconf, where guest is the guest OS (e.g., qnx70, linux44) that will run in the VM configured by this file (see “File names” in the “Understanding QNX Virtual Environments” chapter).
See the following for information about how to:
See “VM configuration file example” in this chapter for an example of a VM configuration file. For more information about starting guests, see “Start a guest” in the “Booting and Shutting Down” chapter.
Typically, we place the VM (qvm) configuration files at /guests/guestos/, where guestos identifies the guest OS (e.g., /guests/qnx704/qnx704-guest.qvmconf).
This location is arbitrary. You can put the qvm configuration files anywhere you want on the target, and maintain several copies for different configurations while you are developing and tuning your system. Just be sure to point each qvm process instance to the configuration file you want to use for each guest.