23.2. Operating System Booting There are a number of different ways to boot virtual machines, including BIOS boot loader, host physical machine boot loader, direct kernel boot, and container boot. 23.2.1. BIOS Boot Loader Booting the BIOS is available for hypervisors supporting full virtualization. In this case, the BIOS has a boot order priority (floppy, hard disk, CD-ROM, network) determining where to locate the boot image. The <os> section of the domain XML contains the following information: ... <os> <type>hvm</type> <boot dev='fd'/> <boot dev='hd'/> <boot dev='cdrom'/> <boot dev='network'/> <bootmenu enable='yes'/> <smbios mode='sysinfo'/> <bios useserial='yes' rebootTimeout='0'/> </os> ... Figure 23.2. BIOS boot loader domain XML Important Instead of using the <boot dev/> configuration for determining boot device order, Red Hat recommends using the <boot order/> configuration. For an example, see Specifying boot order . The components of this section of the domain XML are as follows: Table 23.2. BIOS boot loader elements Element Description <type> Specifies the type of operating system to be booted on the guest virtual machine. hvm indicates that the operating system is designed to run on bare metal and requires full virtualization. linux refers to an operating system that supports the KVM hypervisor guest ABI. There are also two optional attributes: arch specifies the CPU architecture to virtualization, and machine refers to the machine type. For more information, see the libvirt upstream documentation . <boot> Specifies the boot device to consider with one of the following values: fd , hd , cdrom or network . The boot element can be repeated multiple times to set up a priority list of boot devices to try in turn. Multiple devices of the same type are sorted according to their targets while preserving the order of buses. After defining the domain, its XML configuration returned by libvirt lists devices in the sorted order. Once sorted, the first device is marked as bootable. For more information, see the libvirt upstream documentation . <bootmenu> Determines whether or not to enable an interactive boot menu prompt on guest virtual machine start up. The enable attribute can be either yes or no . If not specified, the hypervisor default is used. <smbios> determines how SMBIOS information is made visible in the guest virtual machine. The mode attribute must be specified, as either emulate (allows the hypervisor generate all values), host (copies all of Block 0 and Block 1, except for the UUID, from the host physical machine's SMBIOS values; the virConnectGetSysinfo call can be used to see what values are copied), or sysinfo (uses the values in the sysinfo element). If not specified, the hypervisor's default setting is used. <bios> This element has attribute useserial with possible values yes or no . The attribute enables or disables the Serial Graphics Adapter, which enables users to see BIOS messages on a serial port. Therefore, one needs to have serial port defined. The rebootTimeout attribute controls whether and after how long the guest virtual machine should start booting again in case the boot fails (according to the BIOS). The value is set in milliseconds with a maximum of 65535 ; setting -1 disables the reboot. 23.2.2. Direct Kernel Boot When installing a new guest virtual machine operating system, it is often useful to boot directly from a kernel and initrd stored in the host physical machine operating system, allowing command-line arguments to be passed directly to the installer. This capability is usually available for both fully virtualized and paravirtualized guest virtual machines. ... <os> <type>hvm</type> <kernel>/root/f8-i386-vmlinuz</kernel> <initrd>/root/f8-i386-initrd</initrd> <cmdline>console=ttyS0 ks=http://example.com/f8-i386/os/</cmdline> <dtb>/root/ppc.dtb</dtb> </os> ... Figure 23.3. Direct kernel boot The components of this section of the domain XML are as follows: Table 23.3. Direct kernel boot elements Element Description <type> Same as described in the BIOS boot section. <kernel> Specifies the fully-qualified path to the kernel image in the host physical machine operating system. <initrd> Specifies the fully-qualified path to the (optional) ramdisk image in the host physical machine operating system. <cmdline> Specifies arguments to be passed to the kernel (or installer) at boot time. This is often used to specify an alternate primary console (such as a serial port), or the installation media source or kickstart file. 23.2.3. Container Boot When booting a domain using container-based virtualization, instead of a kernel or boot image, a path to the init binary is required, using the init element. By default, this will be launched with no arguments. To specify the initial argv , use the initarg element, repeated as many times as required. The cmdline element provides an equivalent to /proc/cmdline but will not affect <initarg> . ... <os> <type arch='x86_64'>exe</type> <init>/bin/systemd</init> <initarg>--unit</initarg> <initarg>emergency.service</initarg> </os> ... Figure 23.4. Container boot

Commands:
<os> <type>hvm</type> <boot dev='fd'/> <boot dev='hd'/> <boot dev='cdrom'/> <boot dev='network'/> <bootmenu enable='yes'/> <smbios mode='sysinfo'/> <bios useserial='yes' rebootTimeout='0'/> </os>
<os> <type>hvm</type> <kernel>/root/f8-i386-vmlinuz</kernel> <initrd>/root/f8-i386-initrd</initrd> <cmdline>console=ttyS0 ks=http://example.com/f8-i386/os/</cmdline> <dtb>/root/ppc.dtb</dtb> </os>
<os> <type arch='x86_64'>exe</type> <init>/bin/systemd</init> <initarg>--unit</initarg> <initarg>emergency.service</initarg> </os>