blob: ad38ca09a2824d1ebc8b6e7df65dc2ed701a749b (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
|
=head1 NAME
xmdomain.cfg - xm domain create config file format
=head1 SYNOPSIS
/etc/xen/myxendomain
/etc/xen/myxendomain2
/etc/xen/auto/myxenautostarted
=head1 DESCRIPTION
The xm(1) program uses python executable config files to define
domains to create from scratch. Each of these config files needs to
contain a number of required options, and may specify many more.
Domain configuration files live in /etc/xen by default, though the
full path to the config file must be specified in the I<xm create>
command, so they can exist anywhere in the filesystem.
/etc/xen/auto is a special case however, as domain config files in
that directory will be started automatically at system boot if the
xendomain init script is enabled.
=head1 OPTIONS
The following lists the most commonly used options for a domain config
file.
=over 4
=item I<kernel>
The kernel image used in the domain.
=item I<ramdisk>
The initial ramdisk to be used in the domain. Default xen domU
kernels do not usually need a ramdisk.
=item I<memory>
The amount of memory, in megabytes to allocate to the domain when it
starts. Allocating insufficient memory for a domain may produce
extremely bizarre behavior.
=item I<name>
A unique name for the domain. You can not create 2 domains with the
same name.
=item I<root>
Root stanza for the domain (required for Linux domains).
=item I<disk>
An array of disk stanzas
=back
A bare minimal config file example might be as follows:
kernel = "/boot/vmlinuz-2.6-xenU"
memory = 128
name = "MyLinux"
root = "/dev/hda1 ro"
=head1 ADDITIONAL OPTIONS
=over 4
=item I<builder>
=back
=head1 DOMAIN SHUTDOWN OPTIONS
There are 3 options which control domain shutdown (both planned and
unplanned) under certain events. The 3 events currently captured are:
=over 4
=item I<shutdown>
Triggered on either an I<xm shutdown> or graceful shutdown from inside
the DomU.
=item I<reboot>
Triggered on either an I<xm reboot> or graceful reboot from inside the
DomU.
=item I<crash>
Triggered when a DomU goes to the crashed state for any reason.
=back
All of them take one of 4 valid states listed below.
=over 4
=item I<destroy>
The domain will be cleaned up completely. No attempt at respawning
will occur. This is what a typical shutdown would look like.
=item I<restart>
The domain will be restarted with the same name as the old domain.
This is what a typical reboot would look like.
=item I<preserve>
The domain will not be cleaned up at all. This is often useful for
crash state domains which ensures that enough evidence is to debug the
real issue.
=item I<rename-restart>
The old domain will not be cleaned up, but will be renamed so a new
domain can be restarted in it's place. (TODO: what does this mean for
resources? What is the renamed name?)
=back
=head1 SEE ALSO
B<xm>(1)
=head1 AUTHOR
Sean Dague <sean at dague dot net>
=head1 BUGS
Not all options are currently documented
|
