view docs/man/xmdomain.cfg.pod.5 @ 7634:65c3b9382caa

This patch is to remove the pit_timer when the vmx domain is
inactive to save HV external IRQ caused by ac_time and some cleanup for
ioapic in HV.

Signed-off-by: Eddie Dong <eddie.dong@intel.com>
author kaf24@firebug.cl.cam.ac.uk
date Sat Nov 05 11:26:29 2005 +0100 (2005-11-05)
parents b818029835de
children 12c3b4463cba
line source
1 =head1 NAME
3 xmdomain.cfg - xm domain create config file format
5 =head1 SYNOPSIS
7 /etc/xen/myxendomain
8 /etc/xen/myxendomain2
9 /etc/xen/auto/myxenautostarted
13 The xm(1) program uses python executable config files to define
14 domains to create from scratch. Each of these config files needs to
15 contain a number of required options, and may specify many more.
17 Domain configuration files live in /etc/xen by default, though the
18 full path to the config file must be specified in the I<xm create>
19 command, so they can exist anywhere in the filesystem.
21 /etc/xen/auto is a special case however, as domain config files in
22 that directory will be started automatically at system boot if the
23 xendomain init script is enabled.
25 =head1 OPTIONS
27 The following lists the most commonly used options for a domain config
28 file.
30 =over 4
32 =item I<kernel>
34 The kernel image used in the domain.
36 =item I<ramdisk>
38 The initial ramdisk to be used in the domain. Default xen domU
39 kernels do not usually need a ramdisk.
41 =item I<memory>
43 The amount of memory, in megabytes to allocate to the domain when it
44 starts. Allocating insufficient memory for a domain may produce
45 extremely bizarre behavior.
47 =item I<name>
49 A unique name for the domain. You can not create 2 domains with the
50 same name.
52 =item I<root>
54 Root stanza for the domain (required for Linux domains).
56 =item I<disk>
58 An array of disk stanzas
60 =back
62 A bare minimal config file example might be as follows:
64 kernel = "/boot/vmlinuz-2.6-xenU"
65 memory = 128
66 name = "MyLinux"
67 root = "/dev/hda1 ro"
71 =over 4
73 =item I<builder>
75 =back
79 There are 3 options which control domain shutdown (both planned and
80 unplanned) under certain events. The 3 events currently captured are:
82 =over 4
84 =item I<shutdown>
86 Triggered on either an I<xm shutdown> or graceful shutdown from inside
87 the DomU.
89 =item I<reboot>
91 Triggered on either an I<xm reboot> or graceful reboot from inside the
92 DomU.
94 =item I<crash>
96 Triggered when a DomU goes to the crashed state for any reason.
98 =back
100 All of them take one of 4 valid states listed below.
102 =over 4
104 =item I<destroy>
106 The domain will be cleaned up completely. No attempt at respawning
107 will occur. This is what a typical shutdown would look like.
109 =item I<restart>
111 The domain will be restarted with the same name as the old domain.
112 This is what a typical reboot would look like.
114 =item I<preserve>
116 The domain will not be cleaned up at all. This is often useful for
117 crash state domains which ensures that enough evidence is to debug the
118 real issue.
120 =item I<rename-restart>
122 The old domain will not be cleaned up, but will be renamed so a new
123 domain can be restarted in it's place. (TODO: what does this mean for
124 resources? What is the renamed name?)
126 =back
128 =head1 SEE ALSO
130 B<xm>(1)
132 =head1 AUTHOR
134 Sean Dague <sean at dague dot net>
136 =head1 BUGS
138 Not all options are currently documented