/
eucalyptus.conf
216 lines (183 loc) · 9.12 KB
/
eucalyptus.conf
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
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
# $Id: eucalyptus.conf,v 1.14 2009-01-06 02:57:46 sunils Exp $
#
# this is the configuration for Eucalyptus.
####
# These are to instruct the init.d script on what to start.
####
# This variable point to where eucalyptus has been installed.
EUCALYPTUS="not_configured"
# This is the username that you require eucalyptus to run as
EUCA_USER="root"
# This variable controls whether or not the Cloud Controller will be
# started. Typically there is only one Cloud Controller in the whole
# system, which can controls multiple Cluster Controllers.
START_CLOUD="N"
# This variable controls whether or not the Cluster Controller will be
# started. Typically there is one Cluster Controller per cluster,
# controlling multiple Node Controllers. The Cluster Controller needs to
# be accessible from the outside world, so typically it's installed on
# the head node (frontend).
START_CC="N"
# This variable controls whether or not to start the Node Controller. The
# Node Controller is responsible to talk to the hypervisor to get
# instances running, so it need to run on machine where the
# virtualization hypervisor is running. Typically they are the compute
# node on the cluster.
START_NC="N"
# This variable controls whether ws-security is enabled between
# eucalyptus components. The default settings provide secure
# connections between the Cloud, Cluster, and Node Controllers and we
# recommend that this feature remains enabled. If you wish to disable,
# you must change this variable to "N" and manually configure the
# services.xml for both Cluster and Node Controllers (see documentation
# for more details).
ENABLE_WS_SECURITY="Y"
# This variable controls the level of logging output that appears in
# various eucalyptus log-files. The options are, in descending order
# of verbosity, 'DEBUG, INFO, WARN, ERROR, and
# FATAL'. The default is DEBUG (everything).
LOGLEVEL="DEBUG"
####
# there are Cloud Controller configuration options.
####
# The Cloud Controller needs 2 ports.
CLOUD_PORT="8773"
CLOUD_SSL_PORT="8443"
####
# These are Cluster Controller configuration options.
####
# This is the port the Cluster Controller will be listening on.
CC_PORT="8774"
# This option configures the Cluster Controller's scheduling policy.
# Currently, this option can be set to GREEDY (first node that is
# found that can run the VM will be chosen) or ROUNDROBIN (nodes are
# selected one after another until one is found that can run the VM).
SCHEDPOLICY="GREEDY"
# The list of Node Controllers the Cluster Controller will be in charge
# of. For example on the rocks cluster you can run rocks list host to
# find out the list of machines available to you (in our case we are
# interested in the VM Container kind).
NODES=""
# The name of the Node Controller service: this could be used if you want
# to plug in your own Node Controller.
NC_SERVICE="axis2/services/EucalyptusNC"
####
# These are Node Controller configuration options.
####
# This is the port the Node Controller will be listening on.
NC_PORT="8775"
# The hypervisor that the Node Controller will interact with in order
# to manage virtual machines. Currently, supported values are 'kvm'
# and 'xen'.
HYPERVISOR="not_configured"
# The maximum amount of memory Eucalyptus is allowed to use on the node:
# if you leave this commented out, Eucalyptus will use all available
# memory, otherwise it will use at most the specify number of MB
# for all running instances.
# MAX_MEM=2048
# The maximum number of CPU/cores Eucalyptus is allowed to use on the
# node (at the moment we don't differentiate between cores and CPU): if
# you leave this commented out, Eucalyptus will use all available
# CPU/cores it can find.
# MAX_CORES="2"
# The size of the swap partition, in MB, for each instance started on the
# node (default is 512MB). If the maximum disk allowance for the instance
# is not big enough to accommodate the swap together with the root partition,
# then no swap is allocated. If there is extra room left, then an "ephemeral"
# partition will be created, available as /dev/sda3 inside the VM.
# SWAP_SIZE=512
# Setting this to 1 disables the cleanup of instance files (root, kernel,
# ramdisk) for failed and terminated instances. Such setting is not
# recommended for normal use, but it can be useful in debugging the later
# stages of VM startup.
# MANUAL_INSTANCES_CLEANUP=0
####
# These are options for storage of images on the Node Controller
####
# This variable points to a directory which is used by the Node Controller
# to store images of running instances as well as local cached copies of
# images. The running images will be deleted once the instance is
# terminated, but the cached copies will persist, subject to the LRU cache
# replacement policy and the size limit NC_CACHE_SIZE, below. Hence, this
# partition should be at least as big as the cache size (or the maximum
# space needed by all images, whichever is bigger) plus the maximum space
# needed by the maximum number of instances allowed on the node, combined.
# Finally, this directory should be local to the Node Controller (as
# opposed to an NFS share) for performance reasons.
INSTANCE_PATH="not_configured"
# The maximum amount of disk space, in Megabytes, that Eucalyptus is
# allowed to use in the cache directory (INSTANCES_PATH/eucalyptus/cache).
# A generous size is recommended. Setting this to zero disables caching.
# NC_CACHE_SIZE=99999
####
# there are the options for the network
####
# VNET_INTERFACE specifies the local physical ethernet interface that
# eucalyptus should use to manage the VM network. On the front-end,
# this should be set to the device that is attached to the same
# ethernet network as your nodes. On the nodes, this should be set to
# either the name of the bridge that has been set up by Xen (xenbr0,
# eth0, etc), or the physical ethernet device that is attached to the
# xen bridge (peth0, peth1, etc), depending on your xen configuration.
VNET_INTERFACE="eth0"
# (node setting only) VNET_BRIDGE should be set to the name of the
# bridge that xen has configured. This is typically named 'xenbr0,
# xenbr1, etc' on older Xen versions, and 'eth0, eth1, etc' on newer
# Xen versions. The command 'brctl show' will give you more
# information on your local bridge setup.
VNET_BRIDGE="xenbr0"
# This indicates where we have a dhcp server binary. We use it to provide
# the images with IPs: Eucalyptus provides its own configuration per
# instance.
VNET_DHCPDAEMON="/usr/sbin/dhcpd"
# Some systems have their DHCP daemon configured to run as a non-root
# user. If this is the case, set the name of that user here (by
# default, Eucalyptus will set up DHCPD configuration files and
# directories as owned by root).
#VNET_DHCPUSER="root"
# Following are example eucalyptus VM networking configurations.
# There are three modes to choose from (MANAGED, SYSTEM, or STATIC)
# and each has its own sub-options. The first mode (MANAGED)
# configured eucalyptus to fully manage the VM networks, and enables
# the ability to use security groups and dynamic public IP assignment.
# VNET_SUBNET should be set to an IP subnet that is free for
# eucalyptus to use (i.e. no other system connected to your network
# directly is configured with addresses from this subnet).
# VNET_NETMASK defines the size of the subnet. VNET_DNS should be set
# to a DNS server that your systems use (usually safe to use the same
# DNS that is configured on the front-end). VNET_ADDRSPERNET can be
# used to limit the number of instances that can be attached to each
# named security group simultaneously. Finally, VNET_PUBLICIPS should
# be set to any public IPs, that are currently unused, that can be
# dynamically assigned to VMs. Of these options, only VNET_PUBLICIPS
# can be left blank or undefined.
#VNET_MODE="MANAGED"
#VNET_SUBNET="192.168.0.0"
#VNET_NETMASK="255.255.0.0"
#VNET_DNS="your-dns-server-ip"
#VNET_ADDRSPERNET="32"
#VNET_PUBLICIPS="your-free-public-ip-1 your-free-public-ip-2 ..."
# If you would like eucalyptus to not manage the VM network at all,
# you can set VNET_MODE to SYSTEM. In this mode, VM interfaces are
# attached directly to your physical ethernet, at which point they
# will typically invoke a DHCP client to aquire an IP address. Use
# this mode if you wish to manage VM IPs yourself, or allow the VMs to
# pick up an IP from a non-eucalyptus managed DHCP server.
VNET_MODE="SYSTEM"
# If VNET_MODE is set to STATIC, you can manually configure a set of
# IP addresses that will be allocated to VMs at boot time in a first
# come, first served manner. VNET_SUBNET, VNET_NETMASK, and
# VNET_BROADCAST define your subnet (front-end must have an interface
# configured on this subnet). VNET_ROUTER defines the subnet's
# gateway. VNET_DNS is a nameserver address. It is usually safe to
# get these settings by examining your front-end network settings and
# duplicating them here. VNET_MACMAP is a list of mac address/IP
# address mappings that you would like to be allocated to VMs at run
# time (see example below for the format of this list).
#VNET_MODE="STATIC"
#VNET_SUBNET="192.168.1.0"
#VNET_NETMASK="255.255.255.0"
#VNET_BROADCAST="192.168.1.255"
#VNET_ROUTER="192.168.1.1"
#VNET_DNS="192.168.1.1"
#VNET_MACMAP="AA:DD:11:CE:FF:ED=192.168.1.2 AA:DD:11:CE:FF:EE=192.168.1.3"