Table of Contents
Who Should Read this Guide? ............................................................................................................................7 What’s in this Guide? .............................................................................................................................................7 What’s New in Eucalyptus EE 2.0? ..................................................................................................................9 Conventions Used in this Guide ........................................................................................................................9 Contacting Eucalyptus ....................................................................................................................................... 10

The most straightforward way to configure vSphere for Eucalyptus—and the least likely to incur permissions-related complications—is to give Eucalyptus unrestricted (administrator-level) access to your vSphere endpoint(s). This can be accomplished either by using an existing administrative account and password or by creating a new account for Eucalyptus and associating it with vSphere’s standard ‘Administrator’ role at the top level of the vSphere hierarchy as seen in vSphere client.

23

Figure 3.1 The vSphere client Assign Permissions window. Here you can associate user ‘eucalyptus’ with ‘Administrator’ role at the top of the vSphere hierarchy.

Option B: ‘Least privilege’ access to vSphere infrastructure:

To give the minimum required amount of control to Eucalyptus over your vSphere infrastructure, you will need to create one new user and two new roles. The new user, named, e.g., ‘eucalyptus’, and its password will be used when configuring Eucalyptus for VMware support (as described in Section 4.4 Configuring VMware Support). The new roles should be defined and associated with vSphere objects as follows: (1) Top-level role, named, e.g., ‘Eucalyptus vSphere’, must be associated with the ‘eucalyptus’ user at the top level of the vSphere hierarchy only (“Propagate to Child Objects” does not need to be checked). This role should have only one privilege:
Global Licenses

(2) Resource-level role, named, e.g., ‘Eucalyptus’, can be associated with the ‘eucalyptus’ user at the level(s) encapsulating the resources that you wish Eucalyptus to use. For example, you can create a new virtual datacenter for Eucalyptus to use, add to it the relevant hosts or clusters, and assign the ‘eucalyptus’ user ‘Eucalyptus’ role for the new datacenter (making sure to check “Propagate to Child Objects”). The ‘Eucalyptus’ role should have the following privileges:
Datastore Allocate Space Browse datastore Low level file operations Folder Create folder Host Configuration Network configuration Storage partition configuration Network Assign network Resource Assign virtual machine to resource pool Virtual machine all permissions

Part II – Deploying Your Eucalyptus Cloud

4. Each node requires at least one datastore (either local or one shared by multiple nodes). If more than one datastore is available to a node, Eucalyptus will choose the datastore arbitrarily. Hence you may need to specify a datastore in Eucalyptus’s configuration file for VMware (vmware_conf.xml). 1. Select a host in left-hand-side panel. 2. Select the "Configuration" tab. To check datastores available on a host, perform the following steps with vSphere client pointed either at vCenter or at a particular ESX/ESXi node:

3. Select "Storage" in the secondary left-hand-side panel. 4. Select "View: Datastores" at the top of the panel.

4. If there is no "VM Network" in the list, add it as follows: a. b. c. d.

2. Select the "Configuration" tab.

3. Select "Networking" in the secondary left-hand-side panel.

1. Select a host in left-hand-side panel.

To check the network settings and create a network (if necessary) perform the following steps with vSphere client pointed either at vCenter or at a particular ESX/ESXi node:

25

5. To enable EBS support in Eucalyptus on VMware, each of the ESX/ESXi nodes in your infrastructure must be configured to support iSCSI. Given a node that is licensed for iSCSI support, this amounts to enabling and configuring the gateway for the VMkernel network. To accomplish that, perform the following steps with vSphere client pointed either at vCenter or at a particular ESX/ESXi node: 1. Select a host in left-hand-side panel. 2. Select the "Configuration" tab. a. b. c. d. e. f. 3. Select "Networking" in the secondary left-hand-side panel.

MANAGED and MANAGED-NOVLAN modes - The CC attempts to auto-discover it's list of local IP addresses upon startup, but if the IP that was used to register the CC is not locally available, you can override the CC's notion of 'self' by setting the 'VNET_LOCALIP' variable in eucalyptus.conf. MANAGED and MANAGED-NOVLAN modes - Do not run two CCs in the same broadcast domain with tunneling enabled, this will potentially lead to a broadcast storm as tunnels start forwarding packets in a loop on your local network. If you wish to disable tunneling altogether, set 'VNET_LOCALIP=0.0.0.0' in eucalyptus.conf.

78

Section 8: Eucalyptus EE Network Configuration

8.4 Network Configuration for Components on Separate Machines

If your cluster controller (CC) and cloud controller (CLC) are running on separate hosts, the following value needs to be set within the CC’s configuration file:
VNET_CLOUDIP="<ip-of-cloud-controller>"

If you are running multiple clusters, you may wish to explicitly specify the IP address that the CC used to register with the CLC. You may set the variable VNET_LOCALIP within the configuration file for each of the CCs.

VNET_LOCALIP="<ip-of-cluster-controller>"

If the VNET_LOCALIP value is not set, the CC will attempt to determine this value, automatically.

Section 9: Troubleshooting Eucalyptus EE
9.1 How to Troubleshoot Eucalyptus EE
To troubleshoot Eucalyptus EE, the administrator must know the location of the Eucalyptus components, that is, on which machine each component is installed. The administrator must have root access to each machine hosting the components and must know the network configuration connecting the components. Usually when an issue arises in Eucalyptus, you can find a clue or trace or record that suggests the nature of the problem either in the eucalyptus log files or in the system log files. The eucalyptus logs are located on each machine hosting a component in the following directory: /var/log/eucalyptus/. Cloud Controller (CLC), Walrus, and Storage Controller (SC): o cloud-debug.log o cloud-error.log o cloud-output.log Cluster Controller (CC) o cc.log o axis2c.log o httpd-cc_error_log Node Controller (NC) o nc.log o axis2c.log o httpd-nc_error_log o euca_test_nc.log

Administrator credentials convey more information than user credentials. For example euca-describe-instances give you additional information, including all instances running by all users on the system. Thus, make sure you have Euca2ools installed with proper administrator credentials.

80

Section 9: Troubleshooting Eucalyptus EE

9.2 Common Eucalyptus Problems and Solutions
Are all Eucalyptus components registered?

You can use the euca_conf to check that all components are registered correctly. To do so, on the CLC machine (as root user) run these commands: Check that the IP addresses returned are consistent with your network configuration. For example, Walrus should be registered with a public IP, not localhost (127.0.0.1). Is Eucalyptus running?
euca_conf euca_conf euca_conf euca_conf --list-clusters --list-scs --list-walruses --list-nodes