Below are instructions for booting guests in your hypervisor's VMs.
QNX Hypervisor reference images provide a complete virtualized environment, including the hypervisor and guests you can run on supported reference hardware: in short, everything you need to try out guests (see the hypervisor release notes for the most up-to-date information about supported hardware platforms).
When the hypervisor has completed its startup, it is ready to host guests. The hypervisor has completed its startup successfully if you can perform any of the activities described in “Viewing hypervisor activity”.
You can configure your hypervisor's startup activities to automatically launch qvm processes that will load and launch guests, or to wait for further input before starting any or all guests.
The hypervisor included in the QNX Hypervisor 2.0 reference images is configured to complete its startup then wait for input. The reference images include the image files (IFSs) for guest OSs, but these guests won't be started automatically. You must start them.
To run a guest (QNX Neutrino OS 7.0 or 6.6, or Linux) on the hypervisor, you need the following on your target board:
In addition to the above, Linux guests may require an initial RAM disk (initrd, initramfs) file.
The QNX Hypervisor 2.0 reference images include all the files required to run their guests.
After you have transferred your reference image to your target (see “Transferring the disk image”), the guests can be found in the /guests/ directory on the target. This directory includes subdirectories with the guest images and the configuration files for the VMs (qvm process instances) that will host each guest:
To start a QNX guest OS, in the command line of your terminal program connected the hypervisor:
Go to the directory with the qvm configuration file for the VM in which you will run your guest (In the reference images, we place them at /guests/, but this location is arbitrary (see “Location of configuration files”).
For example, if you are using a reference image, go to /guests/, then enter to launch:
The at sign (“@”) in front of the filename in the qvm command line instruction designates a path to a qvm configuration file.
When it receives the instruction, the hypervisor should:
Below are some things you can try in order to get to know your virtualized system:
Determining which terminal consoles are connected to the hypervisor host, or to the QNX and Linux guests can be difficult for a novice hypervisor user.
If you know a little about how your system is configured, you can easily determine what your terminal console is showing, however. Running uname -a, and pidin info or ps should give you the information you need. For example, a pidin info command on a terminal connected to a QNX Neutrino OS 7.0 guest configured to run on two vCPUs would show two CPUs, but the same command on a terminal connected to the hypervisor host would show all four CPUs.
The hypervisor host and QNX guests each have an /etc/os.version file. You can open these files to view information about the hypervisor host or the guests.
To view information about thread activity in a qvm process, use pidin in the command line of your terminal program connected to the hypervisor host, or the QNX Momentics IDE tools connected to the hypervisor host.
The qvm thread activity tells you about vCPUs, but not about the various services and applications each guest is running. To view thread activity within a guest from the IDE, you can create a new QNX target and enter the IP address of the guest. In this case, you must be running the qconn service on the guest, because this service supports the IDE.
If the default configuration supplied in the QNX Hypervisor 2.0 reference image, doesn't start this utility, you must start it manually (see qconn in the Utilities Reference).
To start virtual networking, on the command line for a console connected to a QNX guest, run the following script:
/scripts/network-start.sh
When the script completes, you will be able to get an IP address for your guest, ping the guest, and perform other networking activities, such as use SSH to access this guest, mount an NFS share on this guest, etc.
You can do the equivalent on a Linux guest as well.
To start a block device, on the command line for a console connected to a QNX guest, run the following script:
/scripts/block-start.sh
Try using the block device as you would this type of device in a non-virtualized system.
The block device is mounted to /RAM disk on the guest. The VM is configured to use the devb-ram device on the hypervisor host. You can change the qvm configuration for the VM hosting your guest so that your guest's block device uses another device, such as a USB key.