1xmdomain.cfg(5)                       Xen                      xmdomain.cfg(5)
2
3
4

NAME

6       xmdomain.cfg - xm domain config file format
7

SYNOPSIS

9        /etc/xen/myxendomain
10        /etc/xen/myxendomain2
11        /etc/xen/auto/myxenautostarted
12

DESCRIPTION

14       The xm(1) program uses python executable config files to define domains
15       to create from scratch.  Each of these config files needs to contain a
16       number of required options, and may specify many more.
17
18       Domain configuration files live in /etc/xen by default, if you store
19       config files anywhere else the full path to the config file must be
20       specified in the xm create command.
21
22       /etc/xen/auto is a special case.  Domain config files in that directory
23       will be started automatically at system boot if the xendomain init
24       script is enabled.  The contents of /etc/xen/auto should be symlinks to
25       files in /etc/xen to allow xm create to be used without full paths.
26
27       Options are specified by name = value statements in the xmdomain.cfg
28       files.
29

OPTIONS

31       The following lists the most commonly used options for a domain config
32       file.
33
34       kernel
35           The kernel image for the domain.  The format of the parameter is
36           the fully qualified path to the kernel image file, i.e.
37           /boot/vmlinuz-2.6.12-xenU.
38
39       ramdisk
40           The initial ramdisk for the domain.  The format of the parameter is
41           the fully qualified path to the initrd, i.e. /boot/initrd.gz.  On
42           many Linux distros you will not need a ramdisk if using the default
43           xen kernel.
44
45       memory
46           The amount of RAM, in megabytes, to allocate to the domain when it
47           starts.  Allocating insufficient memory for a domain may produce
48           extremely bizarre behavior.  If there isn't enough free memory left
49           on the machine to fulfill this request, the domain will fail to
50           start.
51
52           Xen does not support overcommit of memory, so the total memory of
53           all guests (+ 64 MB needed for Xen) must be less than or equal to
54           the physical RAM in the machine.
55
56       name
57           A unique name for the domain.  Attempting to create two domains
58           with the same name will cause an error.
59
60       root
61           Specifies the root device for the domain.  This is required for
62           Linux domains, and possibly other OSes.
63
64       nics
65           The number of network interfaces allocated to the domain on boot.
66           It defaults to 1.
67
68       disk
69           An array of block device stanzas, in the form:
70
71               disk = [ "stanza1", "stanza2", ... ]
72
73           Each stanza has 3 terms, separated by commas, "backend-dev,fron‐
74           tend-dev,mode".
75
76           backend-dev
77               The device in the backend domain that will be exported to the
78               guest (frontend) domain.  Supported formats include:
79
80               phy:device - export the physical device listed.  The device can
81               be in symbolic form, as in sda7, or as the hex major/minor num‐
82               ber, as in 0x301 (which is hda1).
83
84               file://path/to/file - export the file listed as a loopback
85               device.  This will take care of the loopback setup before
86               exporting the device.
87
88           frontend-dev
89               How the device should appear in the guest domain.  The device
90               can be in symbolic form, as in sda7, or as the hex major/minor
91               number, as in 0x301 (which is hda1).
92
93           mode
94               The access mode for the device.  There are currently 2 valid
95               options, r (read-only), w (read/write).
96
97       vif An array of virtual interface stanzas in the form:
98
99               vif = [ "stanza1", "stanza2", ... ]
100
101           Each stanza specifies a set of name = value options separated by
102           commas, in the form: "name1=value1, name2=value2, ..."
103
104           OPTIONS
105
106           bridge
107               The network bridge to be used for this device.  This is espe‐
108               cially needed if multiple bridges exist on the machine.
109
110           mac The MAC address for the virtual interface.  If mac is not spec‐
111               ified, one will be randomly chosen by xen with the 00:16:3e
112               vendor id prefix.
113
114       vfb A virtual frame buffer stanza in the form:
115
116               vfb = [ "stanza" ]
117
118           The stanza specifies a set of name = value options separated by
119           commas, in the form: "name1=value1, name2=value2, ..."
120
121           OPTIONS
122
123           type
124               There are currently two valid options: vnc starts a VNC server
125               that lets you connect an external VNC viewer, and sdl starts an
126               internal viewer.
127
128           vncdisplay
129               The VNC display number to use, defaults to the domain ID.  The
130               VNC server listens on port 5900 + display number.
131
132           vnclisten
133               The listening address for the VNC server, default 127.0.0.1.
134
135           vncunused
136               If non-zero, the VNC server listens on the first unused port
137               above 5900.
138
139           vncpasswd
140               Overrides the XenD configured default password.
141
142           display
143               Display to use for the internal viewer, defaults to environment
144               variable DISPLAY.
145
146           xauthority
147               Authority file to use for the internal viewer, defaults to
148               environment variable XAUTHORITY.
149

ADDITIONAL OPTIONS

151       The following options are also supported in the config file, though are
152       far more rarely used.
153
154       builder
155           Which builder should be used to construct the domain.  This
156           defaults to the linux if not specified, which is the builder for
157           paravirtualized Linux domains.
158
159       cpu Specifies which CPU the domain should be started on, where 0 speci‐
160           fies the first cpu, 1 the second, and so on.  This defaults to -1,
161           which means Xen is free to pick which CPU to start on.
162
163       cpus
164           Specifies a list of CPUs on which the domains' VCPUs are allowed to
165           execute upon.  The syntax supports ranges (0-3), and negation, ^1.
166           For instance:
167
168               cpus = "0-3,5,^1"
169
170           Will result in CPUs 0, 2, 3, 5 being available for use by the
171           domain.
172
173       extra
174           Extra information to append to the end of the kernel parameter
175           line.  The format is a string, the contents of which can be any‐
176           thing that the kernel supports.  For instance:
177
178               extra = "4"
179
180           Will cause the domain to boot to runlevel 4.
181
182       nfs_server
183           The IP address of the NFS server to use as the root device for the
184           domain.  In order to do this you'll need to specify root=/dev/nfs,
185           and specify nfs_root.
186
187       nfs_root
188           The directory on the NFS server to be used as the root filesystem.
189           Specified as a fully qualified path, i.e. /full/path/to/root/dir.
190
191       vcpus
192           The number of virtual cpus to allocate to the domain.  In order to
193           use this the xen kernel must be compiled with SMP support.
194
195           This defaults to 1, meaning running the domain as a UP.
196

DOMAIN SHUTDOWN OPTIONS

198       There are 3 options which control domain shutdown (both planned and
199       unplanned) under certain events.  The 3 events currently captured are:
200
201       on_shutdown
202           Triggered on either an xm shutdown or graceful shutdown from inside
203           the DomU.
204
205       on_reboot
206           Triggered on either an xm reboot or graceful reboot from inside the
207           DomU.
208
209       on_crash
210           Triggered when a DomU goes to the crashed state for any reason.
211
212       All of them take one of 4 valid states listed below.
213
214       destroy
215           The domain will be cleaned up completely.  No attempt at respawning
216           will occur.  This is what a typical shutdown would look like.
217
218       restart
219           The domain will be restarted with the same name as the old domain.
220           This is what a typical reboot would look like.
221
222       preserve
223           The domain will not be cleaned up at all.  This is often useful for
224           crash state domains which ensures that enough evidence is to debug
225           the real issue.
226
227       rename-restart
228           The old domain will not be cleaned up, but will be renamed so a new
229           domain can be restarted in it's place.  The old domain will be
230           renamed with a suffix -1, -2, etc, and assigned a new random UUID;
231           the new domain will keep the original name and UUID.  The old
232           domain will release the devices that it holds, so that the new one
233           may take them.
234

EXAMPLES

236       The following are quick examples of ways that domains might be config‐
237       ured.  They should not be considered an exhaustive set.
238
239       A Loopback File as Root
240               kernel = "/boot/vmlinuz-2.6-xenU"
241               memory = 128
242               name = "MyLinux"
243               root = "/dev/hda1 ro"
244               disk = [ "file:/var/xen/mylinux.img,hda1,w" ]
245
246           This creates a domain called MyLinux with 128 MB of memory using a
247           default xen kernel, and the file /var/xen/mylinux.img loopback
248           mounted at hda1, which is the root filesystem.
249
250       NFS Root
251           FIXME: write me
252
253       LVM Root
254           FIXME: write me
255
256       Two Networks
257           FIXME: write me
258

SEE ALSO

260       xm(1)
261

AUTHOR

263         Sean Dague <sean at dague dot net>
264

BUGS

266       Not all options are currently documented
267
268
269
270xen-unstable                      2007-11-14                   xmdomain.cfg(5)
Impressum