Xen Virtual Machine startup (BOOT) Mode

There are several different ways to boot virtual machines, each of which has its own advantages and disadvantages.

1. BIOS bootloader

Suitable for full virtualization, loader simulates BIOS

Original article:

Booting via the BIOS is available for hypervisors supporting full virtualization. in this case the BIOS has a boot order priority (floppy, harddisk, CDROM, network) determining where to obtain/find the boot image.
...
<OS>
<Type> hvm </type>
<Loader>/usr/lib/xen/boot/hvmloader </loader>
<Boot Dev = 'hd'/>
<Boot Dev = 'cdrom '/>
<Bootmenu enable = 'yes'/>
<Smbios mode = 'sysinfo'/>
</OS>
...
Type
The content of the type element specifies the type of operating system to be booted in the virtual machine. hvm indicates that the OS is one designed to run on bare metal, so requires full virtualization alization. linux (badly named !) Refers to an OS that supports the xen 3 hypervisor guest Abi. there are also two optional attributes, arch specifying the CPU architecture to virtualization alization, and machine referring to the machine type. the capabilities XML provides details on allowed values for these. since 0.0.1
Loader
The optional loader tag refers to a firmware blob used to assist the domain creation process. At this time, it is only needed by xen fully virtualized domains. Since 0.1.0
Boot
The Dev attribute takes one of the values "FD", "HD", "CDROM" or "network" and is used to specify the next boot device to consider. the boot element can be repeated multiple times to setup a priority list of boot devices to try in turn. the boot element cannot be used if per-device boot elements are used (see disks, network interfaces, and USB and PCI devices sections below ). since 0.1.3, per-device boot since 0.8.8
Bootmenu
Whether or not to enable an interactive boot menu prompt on guest startup. The enable attribute can be either "yes" or "no". If not specified, the hypervisor default is used. Since 0.8.3
Smbios
How to populate smbios information visible in the guest. the mode attribute must be specified, and is either "emulate" (let the hypervisor generate all values), "host" (copy all of Block 0 and Block 1, blocks t for the uuid, from the host's smbios values; the virconnectgetsysinfo call can be used to see what values are copied), or "sysinfo" (use the values in the sysinfo element ). if not specified, the hypervisor default is used. since 0.8.7
2. Host bootloader

Applicable to semi-virtualization,Hypersisor does not simulate bios. It is guided by the host's pseudo-bootloader. It provides an interface for guest to select a kernel (not understood)

Original article:

hypervisors employing paravirtualization do not usually emulate a BIOS, and instead the host is responsible to kicking off the operating system boot. this may use a pseudo-bootloader in the host to provide an interface to choose a kernel for the guest. an example is pygrub with xen.
...
/usr/bin/pygrub
-- append single
...
bootloader
the content of the bootloader element provides a fully qualified path to the bootloader executable in the Host OS. this bootloader will be run to choose which kernel to boot. the required output of the bootloader is dependent on the hypervisor in use. since 0.1.0
bootloader_args
the optional bootloader_args element allows command line arguments to be passed to the bootloader. since 0.2.3
3. direct kernel boot

Applicable to full and semi-virtualization, using the host's kernel and initrd (init RAM disk) boot 

When installing a new guest OS it is often useful to boot directly from a kernel and initrd stored in the Host OS, allowing command line arguments to be passed directly to the installer. this capability is usually available for both para and full receivalized guests.
...
<OS>
<Type> hvm </type>
<Loader>/usr/lib/xen/boot/hvmloader </loader>
<Kernel>/root/f8-i386-vmlinuz </kernel>
<Initrd>/root/f8-i386-initrd </initrd>
<Cmdline> console = ttys0 Ks = http://example.com/f8-i386/ OS/</cmdline>
</OS>
...
Type
This element has the same semantics as described earlier in the BIOS boot section
Loader
This element has the same semantics as described earlier in the BIOS boot section
Kernel
The contents of this element specify the fully-qualified path to the kernel image in the Host OS.
Initrd
The contents of this element specify the fully-qualified path to the (optional) ramdisk image in the Host OS.
Cmdline
The contents of this element specify arguments to be passed to the kernel (or installer) at boottime. this is often used to specify an alternate primary console (eg serial port), or the installation media source/kickstart File