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> </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
and interface
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:
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.