This section describes the XML format used to represent domains, there are variations on the format based on the kind of domains run and the options used to launch them:
Normal paravirtualized Xen domains
The formats try as much as possible to follow the same structure and reuse elements and attributes where it makes sense.
The library use an XML format to describe domains, as input to virDomainCreateLinux()
and as the output of virDomainGetXMLDesc(),
the following is an example of the format as returned by the shell command
virsh xmldump fc4
, where fc4 was one of the running domains:
<domain type='xen' id='18'> <name>fc4</name> <os> <type>linux</type> <kernel>/boot/vmlinuz-2.6.15-1.43_FC5guest</kernel> <initrd>/boot/initrd-2.6.15-1.43_FC5guest.img</initrd> <root>/dev/sda1</root> <cmdline> ro selinux=0 3</cmdline> </os> <memory>131072</memory> <vcpu>1</vcpu> <devices> <disk type='file'> <source file='/u/fc4.img'/> <target dev='sda1'/> </disk> <interface type='bridge'> <source bridge='xenbr0'/> <mac address='aa:00:00:00:00:11'/> <script path='/etc/xen/scripts/vif-bridge'/> </interface> <console tty='/dev/pts/5'/> </devices> </domain>
The root element must be called domain
with no namespace, the
type
attribute indicates the kind of hypervisor used, 'xen' is
the default value. The id
attribute gives the domain id at
runtime (not however that this may change, for example if the domain is saved
to disk and restored). The domain has a few children whose order is not
significant:
disk
, interface
and
console
descriptions in no special orderThe format of the devices and their type may grow over time, but the following should be sufficient for basic use:
A disk
device indicates a block device, it can have two
values for the type attribute either 'file' or 'block' corresponding to the 2
options availble at the Xen layer. It has two mandatory children, and one
optional one in no specific order:
An interface
element describes a network device mapped on the
guest, it also has a type whose value is currently 'bridge', it also have a
number of children in no specific order:
A console
element describes a serial console connection to
the guest. It has no children, and a single attribute tty
which
provides the path to the Pseudo TTY on which the guest console can be
accessed
Life cycle actions for the domain can also be expressed in the XML format, they drive what should be happening if the domain crashes, is rebooted or is poweroff. There is various actions possible when this happen:
The following could be used for a Xen production system:
<domain> ... <on_reboot>restart</on_reboot> <on_poweroff>destroy</on_poweroff> <on_crash>rename-restart</on_crash> ... </domain>
While the format may be extended in various ways as support for more hypervisor types and features are added, it is expected that this core subset will remain functional in spite of the evolution of the library.
Here is an example of a domain description used to start a fully virtualized (a.k.a. HVM) Xen domain. This requires hardware virtualization support at the processor level but allows to run unmodified operating systems:
<domain type='xen' id='3'> <name>fv0</name> <uuid>4dea22b31d52d8f32516782e98ab3fa0</uuid> <os> <type>hvm</type> <loader>/usr/lib/xen/boot/hvmloader</loader> <boot dev='hd'/> </os> <memory>524288</memory> <vcpu>1</vcpu> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <features> <pae/> <acpi/> <apic/> </features> <devices> <emulator>/usr/lib/xen/bin/qemu-dm</emulator> <interface type='bridge'> <source bridge='xenbr0'/> <mac address='00:16:3e:5d:c7:9e'/> <script path='vif-bridge'/> </interface> <disk type='file'> <source file='/root/fv0'/> <target dev='hda'/> </disk> <disk type='file' device='cdrom'> <source file='/root/fc5-x86_64-boot.iso'/> <target dev='hdc'/> <readonly/> </disk> <disk type='file' device='floppy'> <source file='/root/fd.img'/> <target dev='fda'/> </disk> <graphics type='vnc' port='5904'/> </devices> </domain>
There is a few things to notice specifically for HVM domains:
<features>
block is used to enable
certain guest CPU / system features. For HVM guests the following
features are defined:
pae
- enable PAE memory addressingapic
- enable IO APICacpi
- enable ACPI bios<os>
block description is very different, first
it indicates that the type is 'hvm' for hardware virtualization, then
instead of a kernel, boot and command line arguments, it points to an os
boot loader which will extract the boot informations from the boot device
specified in a separate boot element. The dev
attribute on
the boot
tag can be one of:
fd
- boot from first floppy devicehd
- boot from first harddisk devicecdrom
- boot from first cdrom device<devices>
section includes an emulator entry
pointing to an additional program in charge of emulating the deviceshda
-hdd
, or a floppy device
fda
, fdb
. The <disk>
element
also supports a 'device' attribute to indicate what kinda of hardware to
emulate. The following values are supported:
floppy
- a floppy disk controllerdisk
- a generic hard drive (the default it
omitted)cdrom
- a CDROM devicehdc
channel, while for 3.0.3 and later, it can be emulated
on any IDE channel.<devices>
section also include at least one
entry for the graphic device used to render the os. Currently there is
just 2 types possible 'vnc' or 'sdl'. If the type is 'vnc', then an
additional port
attribute will be present indicating the TCP
port on which the VNC server is accepting client connections.It is likely that the HVM description gets additional optional elements and attributes as the support for fully virtualized domain expands, especially for the variety of devices emulated and the graphic support options offered.
Graphics and design by Diana Fong