UEC/Eucalyptus installation test: 20090927.1

[Matt Zimmerman]

I tested karmic-server-i386.iso version 20090927.1 in KVM.

I have been able to confirm that it gives me a reasonable-looking
MANAGED-NOVLAN configuration on the CC (eucalyptus.conf attached).  I did
not try configuring a public IP pool yet.

I haven't tested a node installation yet, though I am fairly confident the
MANAGED-NOVLAN bit there is correct (as it is much simpler).

There are some errors printed on the console during startup which I think
have to do with registration failing:

"ERROR: you need to be on the CLC host and the CLC needs to be running"

(screenshot attached).  I didn't file a bug about this, because I assume it
is nothing new, just auto-registration still not working.

I attempted manual registration (see attached screenshot) and it appeared to
succeed.

Running w3m http://localhost:8774/ to reach the frontend failed (500 server
error), both before and after registration.  The frontend doesn't seem to be
working.  I don't know why.  I've filed
https://bugs.edge.launchpad.net/ubuntu/+source/eucalyptus/+bug/437768 about
this.  Can anyone confirm or deny?

euca2ools was not installed on the CC.  Shouldn't this be part of the task,
so it can be used for administration and debugging?  I went ahead and added
it to the Karmic seeds, for both the CC and node.

I noticed that apport was not installed.  This appears to be because the
eucalyptus-simple-node task derives from standard, not server.  Thus, the
default server packages (like apport) are left off.  I had to install it
before I could report bugs with ubuntu-bug.  I went ahead and committed this
change to the seeds as well.

-- 
 - mdz
-------------- next part --------------
#
# Eucalyptus configuration. 

####
# These are to instruct the init.d script on what to start.
####

# This variable points to where eucalyptus has been installed.
EUCALYPTUS="/"

# This is the username that you would like eucalyptus to run as
EUCA_USER="eucalyptus"

# Uncomment this field if you do not plan on using the dynamic block
# store functionality of Eucalyptus
# DISABLE_EBS="Y"

# Uncomment this field if you do not plan on using the dynamic DNS
# functionality of Eucalyptus
DISABLE_DNS="Y"

# 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 security,
# 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"

####
# These following 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), ROUNDROBIN (nodes are
# selected one after another until one is found that can run the VM),
# or POWERSAVE (nodes are put to sleep when they are not running VMs,
# and reawakened when new resources are required.  VMs will be placed
# on the first awake machine, followed by machines that are asleep).
SCHEDPOLICY="ROUNDROBIN"

# Powersave options.  POWER_IDLETHRESH is the number of seconds that a
# node can remain idle (i.e. no running VMs) before a powerdown is
# attempted.  POWER_WAKETHRESH is the number of seconds that
# Eucalyptus should wait after attempting a node wake-up before it
# will consider the node actually down (and not waking up).
POWER_IDLETHRESH="300"
POWER_WAKETHRESH="300"

# The list of Node Controllers the Cluster Controller will communicate with. 
#
# If you are running Rocks, 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. Change this if you want
# to plug in your own Node Controller service.
NC_SERVICE="axis2/services/EucalyptusNC"

####
# The following 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 this value 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 allowed 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.  This is not 
# recommended for normal use, but it can be useful in debugging VM startup.
# MANUAL_INSTANCES_CLEANUP=0

####
# The following are options for image storage 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 after the instance is
# terminated, but the cached copies will persist, subject to LRU cache
# replacement and the NC_CACHE_SIZE size limit, below.  So, 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.
# This directory should be local to the Node Controller (as
# opposed to a 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

####
# The following are networking options
####

# VNET_PRIVINTERFACE and VNET_PUBINTERFACE specify the local physical
# ethernet interfaces that eucalyptus should use to manage the VM
# network.  On the front-end, VNET_PRIVINTERFACE should be set to the
# device that is attached to the same ethernet network as your nodes.
# VNET_PUBINTERFACE should be set to the device which is connected to
# the 'public' network.  If you have only one interface, these should
# be set to the same value.  On the nodes, both 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_PUBINTERFACE="eth0"
VNET_PRIVINTERFACE="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="br0"

# 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/dhcpd3"

# 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="dhcpd"

# Following are example eucalyptus VM networking configurations.
# There are four modes to choose from (MANAGED, MANAGED-NOVLAN,
# SYSTEM, or STATIC) and each has its own sub-options.  The first
# modes (MANAGED, MANAGED-NOVLAN) configure eucalyptus to fully manage
# the VM networks, and enables the ability to use security groups and
# dynamic public IP assignment (with and without vlan tagging of
# security group networks, respectively).  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.  If you are running in multi-cluster mode (more than one
# CC), you should set VNET_LOCALIP to the local IP of the CC that is
# accessible by all other CCs in the system.  If VNET_LOCALIP is
# unset, the CC will try to determine the list of all IPs currently
# assigned to the machine at CC run time.

#VNET_MODE="MANAGED-NOVLAN"
#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 ..."
#VNET_LOCALIP="your-public-interface's-ip"

# 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"

# network configuration from the input configuration file
VNET_MODE="MANAGED-NOVLAN"
VNET_SUBNET="172.19.0.0"
VNET_NETMASK="255.255.0.0"
VNET_DNS="10.0.2.3"
VNET_ADDRSPERNET="32"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot-QEMU-startup-errors.png
Type: image/png
Size: 12570 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20090927/1b01015d/attachment-0004.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot-QEMU-registration.png
Type: image/png
Size: 13618 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20090927/1b01015d/attachment-0005.png