VMware vCloud Director Essentials

By Lipika Pal
  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies

About this book

VMware vCloud Director is a key technology in today's cloud computing market; it provides a self-service portal and catalog that enables application provisioning and automated operation management.

This book ensures that you have a comprehensive understanding of the different components of VMware vCloud Director and their interaction with the physical and logical layers. This includes the ESXi host, virtual machine, vSphere cluster, vSphere storage, and vSphere network. This book enhances your ability to install, configure, and administer complex, single, multitenant public/private/hybrid VMware vCloud environments.

This book follows a practical and step-by-step approach with ample screenshots that make it easier for you to configure and manage networks and implement a private cloud running on vCloud Director.

Publication date:
August 2014
Publisher
Packt
Pages
198
ISBN
9781783986521

 

Chapter 1. Configuring and Maintaining vCloud Director

A VMware vCloud combines a vCloud Director server group with the vSphere platform. When you install one or more vCloud Director software instances, they create a vCloud Director server group by connecting the servers to a shared database as well as the shared NFS storage directory and integrating the vCloud Director server group with a vSphere platform. vCloud Director (vCD) is web server appliance. So, when you install vCloud Director on one or more servers, you can form a vCloud Director server group and this group can be balanced behind a load balancer. Each vCloud Director is referred to as a cell. Multiple cells form a vCloud Director server group, which leverages a single database.

The installation and configuration procedure for VMware vCloud Director describes how to create the vCloud Director cells, connect them to the shared database, and establish the first connections to a vCenter Server, vShield Manager, and ESX/ESXi hosts. It is then the system administrator's job to use the vCloud Director web console to connect additional vCenter Servers, vShield Manager servers, and ESX/ESXi servers to a vCloud Director cell at any time

This chapter covers the following topics:

  • How to configure centralized logging

  • How to configure vCloud Director for scalability

  • How to maintain vCloud using command-line tools

 

Configuring centralized logging


Centralized logging is the most important feature of vCD that allows us to see what happens within the cloud from one central place. The following are the various important logs and tasks you can view from one central location.

To understand how to configure a centralized logging system, we need to explain the role of the administrator and why you have to manually configure centralized logging.

vCloud Director provides the log in information for each cloud cell in the system. You can view the logs to monitor your cells and to troubleshoot issues.

As a vCloud System Administrator, you can do the following:

  • View the system log to monitor system-level tasks that are in progress. System logs show you which tasks are currently running in vCloud Director or are already completed tasks in vCloud Director, which includes tasks that are in progress and failed tasks.

  • Find the failed tasks that have been logged and troubleshoot them.

  • Analyze vCloud Director logs to monitor vCloud Director cells.

  • Similarly, as an organization admin, you can view the tasks at the organization level.

We are essentially discussing system-level tasks and organization-level tasks.

As the name suggests, these tasks are specific to the system- and organization-level tasks and events that get logged there. If you are running a small private cloud with just a single-cell cloud deployment, then there is not much scope or use in configuring centralized logging. However, for a large-scale cloud implementation, especially where a public cloud is running, you should have an external syslog server configured to send logs to a centralized location.

You can find the logs for a cell at /opt/vmware/cloud-director/logs.

Apart from the diagnostics logs in vCloud Director, you have audit logs as well, which you can see in the following table:

Log name

What the log shows

cell.log

This logfile is the console output from the vCloud Director cell

vcloud-container-debug.log

This logfile shows the debug-level log messages from the cell

vcloud-container-info.log

This container information log shows the warnings or errors encountered by the cell

vmware-vcd-watchdog.log

When the cell crashed, restarted, and so on, then this logfile shows us what possibly went wrong

diagnostics.log

This logfile shows diagnostics information; however, this log first needs to be enabled in the local logging configuration

YYYY_MM_DD.request.log

HTTP request from vCloud Director cells logs in the Apache common log format to this file

However, by default, these files do not get forwarded to the centralized logging server. You have to manually configure the vCloud cell to forward these to the centralized logging server. It is recommended that you configure this option for the following reasons:

  • Remote logging allows audit logs from all cells to be viewed together in a central location at the same time.

  • Database logs are not retained after 90 days, but logs transmitted via syslog can be retained as long as desired.

  • The vCloud cell protects the audit logs from any loss on the local system due to failure, lack of disk space, compromise, and so on.

  • It supports forensics operations in the face of problems, like those listed in the preceding points.

  • Logging to a remote system, instead of the cell, provides data integrity by inhibiting tampering. Even if the cell is compromised, it does not necessarily enable access to, or alteration of, the audit log.

Modifying the default Log4j configuration

To implement centralized logging in vCloud Director, you need to modify the Log4j configuration that vCloud Director uses and add an additional appender to the loggers. However, as a prerequisite, you need to know the IP address or FQDN of the log server and the port this server is listening to (the default port: UDP 514). On another note, you also need to figure out the level of logging information you want to send to the logging server.

There are seven levels of logging available in vCloud director, which are as follows:

  • FATAL: This level designates very severe error events that will presumably lead the application to abort

  • ERROR: This level designates error events that might still allow the application to continue running

  • WARN: This level designates potentially harmful situations

  • INFO: This level designates informational messages that highlight the progress of the application at a coarse-grained level

  • DEBUG: This level designates fine-grained informational events that are most useful to debug an application

  • TRACE: This level is designed to log informational events at a level finer than DEBUG logging

  • OFF: This level is intended to turn off logging

Let's look at how to enable centralized logging in vCloud Director by performing the following steps:

  1. Before you start the activity, you should confirm that the remote logging server supports listening to remote connections.

    Note

    Make sure that the appropriate firewall configuration is in place for vCloud Director—the outbound UDP access and inbound UDP access for the syslog host.

  2. Log in to the cell using the console or SSH.

  3. Change the directory to /opt/vmware/vcloud-director/etc.

  4. Create a backup of the logging configuration:

    # cp log4j.properties log4j.properties.default
  5. Open the log4j.properties file in a text editor and add the following lines:

    log4j.appender.vcloud.system.syslog=org.apache.log4j.net.SyslogAppender
    log4j.appender.vcloud.system.syslog.syslogHost=remoteSyslogHost.example.com
    #Logs go to port 514 unless you specify a port, as in the disable example below.
    #log4j.appender.vcloud.system.syslog.syslogHost=remoteSyslogHost.example.com:5555
    log4j.appender.vcloud.system.syslog.facility=LOCAL1
    log4j.appender.vcloud.system.syslog.layout=com.vmware.vcloud.logging.CustomPatternLayout
    log4j.appender.vcloud.system.syslog.layout.ConversionPattern=%d{ISO8601} | %-8.8p | %-25.50t | %-30.50c{1} | %m | %x%n
    log4j.appender.vcloud.system.syslog.threshold=DEBUG
  6. Modify line 2 of this file to append the name of the new syslog appender, as follows:

    log4j.rootLogger=ERROR, vcloud.system.debug,vcloud.system.info, vcloud.system.syslog
  7. Save the file.

  8. Restart the vCloud Director server service:

    # service vmware-vcd restart

    After the cell starts, the diagnostic log output from the cell appears on the central syslog server.

  9. Repeat this procedure for each cell in your vCloud Director server group.

The following screenshot illustrates a sample configuration of centralized logging for vCloud Director:

The preceding procedure will configure centralized logging for a vCloud cell; however, you need to configure the syslog servers for networks and other components. In the Administration tab, the General page allows you to type in up to two IP addresses for the syslog servers that the networks will use. This setting does not apply to syslog servers used by cloud cells.

There is a possibility to view the syslog server settings for a routed organization network. vCloud Director also supports logging events to a syslog server, where the events are related to firewall rules. If an administrator does not enable the logging permissions for an organization network, then they can synchronize the network with the most current syslog server settings.

The syslog file is usually found in the messages file under /var/log in your syslog receiver.

Configuring syslog in the vCloud Director GUI

Let's look at how to configure the syslog settings in vCloud Director.

To configure a syslog server in vCloud Director, use the following steps:

  1. Open a browser. Go to the URL of the vCD server; for example https://serverFQDN/cloud.

  2. Log in to vCD by typing in an administrator user ID and password.

  3. Click on the Administrator tab.

  4. Click on General in the left panel.

  5. Scroll down to the Networking section. Specify the syslog server IP address or FQDN for syslog server 1, as shown in following screenshot. Optionally, if you have another server, then specify the IP address or FQDN for that syslog server. Your screen should look similar to what is shown in the following screenshot:

  6. Click on Apply.

Configuring logging for vShield Manager

vShield Manager can manage vShield Edge Gateway, which is a multi-interface vShield Edge virtual device that connects the vCloud Director organization vDC networks to external networks through the vCloud GUI. Each vShield Manager can be configured to send its logs to up to two remote syslog servers. Additionally, the protocol (UDP/TCP) can be specified as well, and these will be applied to every Edge device that's deployed (either Edge Gateways or vApp Edges).

When configured, audit logs and system events for vShield Manager are sent to the syslog servers via UDP using the default port (514) unless a different port is specified.

Note

The system event message logged in syslog has the following structure:

syslog header (timestamp + hostname + sysmgr/)
Timestamp (from the service)
Name/value pairs
Name and value separated by delimiter '::' (double colons)
Each name/value pair separated by delimiter ';;' (double semi-colons)

The fields and types of the system event contain the following information:

  • Event ID :: 32 bit unsigned integer

  • Timestamp :: 32 bit unsigned integer

  • Application name :: string

  • Application submodule :: string

  • Application profile :: string

  • Event code :: integer (possible values: 10007 10016 10043 20019)

  • Severity :: string (possible values are INFORMATION LOW MEDIUM HIGH CRITICAL)

  • Message: string

Let's look at how to configure logging for VMware vShield Manager. To configure a syslog server in vShield Manager, follow the ensuing steps:

  1. Open a browser. Go to the URL of vShield Manager.

  2. Log in with an enterprise-level account.

  3. Click on Settings & Reports from the vShield Manager inventory panel.

  4. Click on the Configuration tab.

  5. Ensure that you are in the General tab.

  6. Click on Edit next to Syslog Server.

  7. Type in the IP address of the syslog server, as shown in the following screenshot:

  8. Type in the port number for the syslog server (this is an optional step).

  9. If you do not specify a port, the default UDP port for the IP address/host name of the syslog server is used.

  10. Click on OK.

 

Configuring vCloud Director for scalability


After you have installed vCloud Director, the very next step is to do the initial configuration. Once you are done with the installation of the vCloud Director software, you will be asked to configure the software as well. However, we tend to skip this step as we normally do not have the SSL certificates ready by this time. So, as a prerequisite, you need to create self-signed SSL certificates. In a cloud environment, where trust concerns are minimal, self-signed certificates can provide an easy way to configure SSL for vCloud Director.

Each vCloud Director cell requires two SSL certificates, one for each of its IP addresses, in a Java keyStore file. We need two IP addresses in a vCloud director cell: one is for the web UI and the other is for the console proxy that requires the user to open up the VM console within the vCloud Director web UI. An administrator must create two SSL certificates for each server that they intend to use in their vCloud Director server group.

To finish off the configuration, we need to run the following script:

# /opt/vmware/vcloud-director/bin/configure

With this script, you need to provide the following information:

  • The HTTP service IP address

  • The remote console Proxy IP address

  • The Java KeyStore path

  • The Java KeyStore password

  • The Syslog server hostname of the IP address

  • The database host

  • The database port

  • The database name

  • The database instance

  • The database username

  • The database password

Note

The database connection information and other reusable responses you provided during configuration are preserved in a responses.properties file located at /opt/vmware/vcloud-director/etc/ on the vCloud server. This file will store the reusable information, that you can reuse when you add more servers to a server group.

Let's look at how to generate the vCloud Director response file. You need a response file when you configure another vCloud Director cell in the same group. It is created automatically once you configure the first vCloud Director cell. The steps to configure the cell have been discussed in the preceding steps.

Once you configure the first vCD cell and start the service, you will get the responses.properties file located at /opt/vmware/vcloud-director/etc.

This file must be owned by vcloud.vcloud and have read and write permissions for the owner vCloud and the group vCloud, as shown in the following screenshot:

The following screenshot shows the typical content in this file:

You can use this response file to add an additional vCloud Director server to the existing vCloud Director server's group. As a prerequisite, you need to use the same database details, and there you can leverage this response file from the first server. Also, you need a shared NFS directory.

When you use multiple cells in your vCloud environment, you need to have a shared spooling area that will be accessed by all your cells. It is called the NFS Transfer Server Storage. Transfer Server Storage is used for uploading and downloading vApps when you import VMs into your vCD from the vCenter Server. If you have larger vApps or ISO images, whose size is 100 GBs or greater, then the default Transfer Server Storage will not be sufficient. If your Transfer Server Storage capacity is small, it will result in the inability to upload or download vApps.

Note

In order to provide temporary storage for uploads and downloads, an NFS or other shared storage volume must be accessible to all servers in the vCloud Director cluster. You should have the write permissions for the root to this volume (No_Root_Squash). All of your hosts should mount this volume at $VCLOUD_HOME/data/transfer, which is typically /opt/vmware/vcloud-director/data/transfer.

Let's look at how to add additional vCloud Director cells using the response file. To add additional cells using the responses.properties file, perform the following steps:

  1. Log in to the server where you want to install the vCloud Director software.

  2. Retrieve the response file from the first server and put it in the target server's /tmp directory.

  3. Run the following command:

    ./installation-file –r /tmp/responses.properties
    

Setting up the transfer storage space

Let's see how to set up the vCloud Director transfer storage space.

As a prerequisite, you need to have the NFS export details. Let's execute the given steps to set up the transfer storage space:

  1. You need to add a line in /etc/fstab to make sure that the NFS server export is persistent in the vCloud cell. The following statement is an example line:

    <NFS-Server-IP>:/<Export-Directory> /opt/vmware/vcloud-director/data/transfer nfs rw,soft,_netdev 0 0
  2. Now, you can mount the NFS. Run the following command:

    # mount –a
    
  3. You need to set the permissions for your transfer directory. Run the following command that will provide the RWX permission to the owner and the read permission to everyone else:

    chmod 750 /opt/vmware/vcloud-director/data/transfer
    
  4. You need to change the User and Group ownership of your transfer folder as well. Run the following command:

    chown -R vcloud:vcloud /opt/vmware/vcloud-director/data/transfer
    
  5. Finally, you need to restart the vCD service by using the following command:

    service vmware-vcd restart
    

When you deploy vCloud Director in a multi-cell environment, you tend to use it for high availability and load balancing. In these scenarios, you need a load balancer for your vCloud environment. For this matter, you can choose a hardware-based load balancer (for example, F5) or a software-based load balancer (for example, VMware vCloud Networking and Security (vCNS), Citrix Netscaler, and so forth).

The new version of vShield, which is vCNS, comes up with a lot of new features. Some of them are load balancing HTTPS and generic TCP connections. It also inherits the old mechanism of load balancing HTTP connections.

Using vCNS for vCloud cell load balancing

We will see how to use the Edge device to configure load balancing for a vCloud environment. Each Edge virtual appliance can have a total of ten uplink and internal network interfaces. In the following setup, we have two vCD cells inside a routed network, and we will use the vCNS to load balance the web portal and VMRC console proxy connections too.

We will use an external IP address from Edge Gateway to load balance the vCD cell. The first vCD cell uses 192.168.0.50 as the web portal IP and .0.51 as the VMRC console proxy IP address. The second vCD cell uses 192.168.0.52 as the web portal IP and .0.53 as the console proxy IP address.

Let's look at how to configure load balancing of vCloud Director using vCNS. You need to go through the following steps to set up load balancing using Edge:

  1. Create a pool of servers.

  2. Create a virtual server.

  3. Enable the Edge load balancer service.

  4. Log in to the vCNS web portal.

  5. Go to the Host and Clusters view, select Datacenter, and click on the Network Virtualization tab.

  6. Click on the Edges link.

  7. Select the appropriate Edge device and click on Actions and select Manage.

  8. Go to the Load Balancer tab.

  9. At this point, you need to add a pool of servers. We will add two pools: one for the vCD web portal and one for the VMRC console proxy.

  10. Click on the green colored + icon. Your screen should look similar to what is shown in the following screenshot:

  11. Name this pool and click on Next. I have named it vCD-Web-80-443.

  12. Select HTTP and HTTPS and set the Balancing Method option to ROUND_ROBIN.

    There are four load balancing methods available in vCNS, as shown in the following table:

    The load balancing method

    Description

    IP_Hash

    This policy selects a server based on a hash of the source IP address of each packet.

    LEAST_CONN

    This policy makes sure that any new connections are sent to the server that has the fewest connections.

    ROUND_ROBIN

    In this policy, each server is used in turns according to the weight it was assigned while it was configured.

    URI

    The left part of the URI is hashed and divided by the total weight of the servers being run. The result determines which server will receive the request. However, this is only applicable for HTTP service load balancing.

  13. Select the default Health Check settings and click on Next.

  14. On the Members screen, add the vCD HTTP service members. In this case, it is 192.168.0.50. Set the Weight to 1 and click on Add.

  15. Repeat step 11 and add the second vCD HTTP address, which in this case is 192.168.0.52. Click on Next once you are done.

  16. Now select the green + icon one more time to add the VMRC.

  17. Give it a name; in this example, I have named it VMRC-443.

  18. On the Services screen, select TCP and Balancing Method as ROUND_ROBIN. Choose 443 as the port and click on Next.

  19. Select the default settings for Health Check.

  20. On the Members screen, add the members of VMRC. In this example, it is 192.168.0.51 and 192.168.0.53.

  21. Click on Next.

  22. On this final screen, review the configuration and select Finish.

  23. Click on Publish Changes to make this effective.

  24. Now go to the Virtual Servers tab where you need to create the load balancer virtual IP (VIP) for these two services (HTTP and VMRC). Click on the green + icon.

  25. On the Add Virtual Server, name the first service, which is HTTP. In this example, I named it "vCloud-HTTP".

  26. Specify the load-balanced IP Address (10.10.10.51) and choose the existing pool (vCD-Web-80-443). Your screen should look similar to what is shown in the following screenshot:

  27. Click on Add.

  28. Click on the green + icon one more time to add the Virtual Server IP for VMRC.

  29. Give it a name. In this example, I named it "vCloud-VMRC".

  30. Specify the load balanced IP address (10.10.10.52) and choose the existing pool VMRC-443.

  31. Click on Publish Changes to make it persistent.

  32. Now go to the pools screen and click on the Enable button to enable the Load balancer service.

Maintaining vCloud using command-line tools

Today, most of the activities that you perform in your vCloud Director cell are done through the command line. A cell management tool has been created to help you manage your vCloud Director. If you want to manage a cell and its SSL certificates or export tables from the vCloud Director database, then this is essential. You need to be the super user on a vCD cell VM to carry out these operations.

Managing a vCloud Director cell includes the following:

  • Quiesce

  • Shutdown

  • Maintenance

  • Status

With the vCloud Director 5.1 cell tool, you can generate self-signed certificates, replace the SSL certificates, and change a forgotten system administrator password. Before vCloud 5.1, you had to use several other tools to do this.

When you plan to upgrade your vCloud Director cell, you should use the cell management tool to gracefully shutdown the vCloud Director cell. However, shutdown is not recommended if you have an active cell and did not quiesce the cell first.

Quiese means that vCloud Director creates a task object to track and manage each asynchronous operation that a user requests. Information about all the running tasks and the recently completed tasks is stored in the vCloud Director database. Due to a database upgrade invalidating this task information, you must make sure that no tasks are running when you begin the upgrade process.

The cell management tool can also be used to suspend the task scheduler so that new tasks cannot be started and then used to check the status of all active tasks. Either you need to wait for the active tasks to be completed, or you can proactively log in to the vCloud Director and cancel the ongoing tasks. If you do not have any tasks running on the cell, you can stop the services.

 

Using vCloud Director shell commands


There are a lot of shell commands that are helpful in maintaining and configuring vCloud Director. This section will explore them.

Sometimes you have to perform maintenance activities on the vCloud Director cell. During this time, you can turn on the maintenance message to let the users know that the cell is in maintenance and cannot be contacted. If you turned on the maintenance message, then the users who try to log in to the cell from a browser will see a message that states the cell is down for maintenance. Also, the users who try to reach the cell using the VMware vCloud API will receive a similar message.

Follow the ensuing steps to show the cell maintenance message to a cloud user during a planned maintenance:

  1. Log in to the vCloud Director cell using root credentials.

  2. Go to the directory by using the following command:

    # cd /opt/vmware/vcloud-director/bin
    
  3. Run the following command to put this cell in the maintenance mode:

    # ./vmware-vcd-cell maintenance
    
  4. When you need to come out of the maintenance mode, run the following command:

    # ./vmware-vcd-cell stop
    

Note

The cell needs to be started after you run the preceding command using service vmware-vcd start.

Let's look at how to quiesce and shutdown vCloud Director using the cell management tool.

The cell management tool can be used to quiesce and shut down a vCloud cell. To do this, follow the ensuing steps:

  1. Log in to the vCloud cell using the root credentials.

  2. First try to see if there are any active tasks being performed by this cell by using the following commands:

    # cd /opt/vmware/vcloud-director/bin
    # ./cell-management-tool –u administrator –p <password> cell –t
    Job count = 5
    Is Active = true
    
  3. Any job count that is more than 0 means there are active tasks on this cell. You need to quiescent the cell now to stop the task scheduler:

    # ./cell-management-tool –u administrator –p <password> cell –q true
    
  4. After this point, check the cell status again using step 2, and if the Job count parameter becomes 0 and Is Active becomes false, then it is safe to shut down the cell by executing the following command:

    # ./cell-management-tool –u administrator –p <password> cell –s
    

Let's look at generating self-signed SSL certificates using the cell management tool. The generate-certs command can be used if you need to generate new self-signed SSL certificates for the cell. Let's execute the following steps to create and retrieve self-signed SSL certificates:

  1. You can run the following command to create the self-signed SSL certificates:

    # ./cell-management-tool generate-certs –o /tmp/cert.ks –w vmware –i "CN=vCD, L=Bangalore, C=IN" –s 2048 –x 90
    

    This example creates the new certificates using the custom values for the key size, issuer name, and a keyStore at /tmp that have the password vmware. This certificate uses 2048-bit encryption and expires 90 days after creation.

  2. If you want to retrieve the recently created self-signed SSL certificates, then use the following command:

    # keytool –storetype JCEKS –storepass vmware –keystore /tmp/cert.ks –list –v
    

Let's look at replacing self-signed SSL certificate using the cell management tool. The certificates command can be used if you want to replace a cell's existing certificate.

Note

If you change certificates of any product that is based on vCD (such as vCAC, Chargeback, and so on), you need to re-establish their connections in order to accept the new SSL certificates.

This command reads the existing certificate location from the responses.properties file under /opt/vmware/vcloud-director/etc/. Let's execute the following steps to replace the cell's certificates:

  1. Run the following command to replace the cell's existing certificates with the just created new self-signed SSL certificate:

     # ./cell-management-tool certificates –s /tmp/cert.ks –w vmware
    
  2. You need to restart the cell services to make this certificate effective by using the following command:

    # vmware-vcd restart
    

Let's look at recovering the system administrator password. You can use the recover-password command to recover the system administrator password, provided that you know the vCloud Director database username and password.

Use the following command to recover the system administrator password:

# ./cell-management-tool recover-password –dbuser vcloud –dbpassword VMware123

Please enter the system administrator username whose password is to be changed: administrator
Please enter the new password:
Reenter the password:
Successfully changed password

For troubleshooting and maintenance purposes, sometimes you stop/start the vCloud Director server service. This is what you have to do from the command line of your vCloud cell.

Let's look at how to manage vCloud services using command-line tools.

To start, stop, restart, and list vCloud process, follow the given steps:

  1. Log in to the cell as the administrator.

  2. To stop the service, run the following command:

    # ./cell-management-tool -u username -p password cell -s
    

    However, I will not recommend this method. You should use vmware-vcd-cell stop first.

  3. To check the status of the VMware vCloud Director service, run the following command:

    # service vmware-vcd status
    
  4. To start the VMware vCloud Director service, run the following command:

    # service vmware-vcd start
    Starting vmware-vcd-watchdog: [ OK ]
    Starting vmware-vcd-cell [ OK ]
    
  5. You may wish to check whether the vCloud process is running. Use the following command to check this:

    # ps –ef | grep –i vcloud
    

    Ensure that the command prompt outputs the process as running, as shown in the following screenshot:

  6. You can switch the service on or off manually in case you don't want an automatic start of the cell when the OS boots. To check the run level information for VMware vCloud Director, run the following command:

    # chkconfig --list | grep -i vmware-vcd
    

Understanding the vCloud support bundle

Logfiles are more important in cases where you are troubleshooting any issues of vCloud Director. VMware has two scripts to capture all of the logfiles in the vCloud Director cell. They are in /opt/vmware/vcloud-director/bin. Let's use the following commands to use the logs:

vmware-vcd-support
vmware-vcd-multi-cell-log-collector

Once you execute this, all of the logfiles from /opt/vmware/vcloud-director/logs will be zipped into a .tgz file and will be saved under the user's home directory. This is a new behavior in vCD 5.5 since vCD 5.1 save the log from where one user runs the scripts.

The first script is pretty straightforward, and you need to run this from each cell to generate the log bundle. However, when you have a bigger environment where multiple cells are connected, then you may wish to run the second support script from any of the servers. This multi-cell log collection process is automated, faster, and less complicated. However, you can run the first script also with the –m option to call the second script.

When you invoke the multi-cell log collector script in one cell, either using the dedicated command or using the –m option with the standard script, a marker file will be created in the transfer directory under $VCLOUD_HOME/data to signal a log collection. At the same time, vmware-vcd-watchdog will check whether the marker file exists or not; if yes, then it will execute the log collection script. The resulting support bundle (named vmware-vcd-support-XXXX.tgz) should be copied into $VCLOUD_HOME/data/transfer/. The filename should contain the UUID cell and/or hostname so that the bundle file for each cell is unique. If this copy fails, the bundle should be left in its normal directory (under logs).

Let's look at how to collect logs for troubleshooting using the support script. To capture single vCloud cell deployment logs and a multi-cell deployment logs, follow the given steps:

  1. Log in to the vCloud Director cell using root credentials.

  2. Run the following command to capture the logs:

    # ./opt/vmware/vcloud-director/bin/vmware-vcd-support
    

    The preceding command will capture the log from just one cell.

  3. Run either of the following commands to capture a multi-cell log:

    # ./opt/vmware/vcloud-director/vmware-vcd-multi-cell-log-collector
    

Configuring alarms and notifications

vCloud Director sends user notifications and system alert e-mails through the SMTP server. You can modify the settings you specified while you created the organization. Today, you have the feasibility to send these notifications to all users in the entire installation, all system administrators, or all organization administrators; for example, if you are planning for a planned maintenance, you can notify the users about it.

If configured, when your datastore free space is too low (out of space condition), vCloud Director sends system alert e-mails. You can configure vCloud Director to send e-mail alerts to all system administrators or to a specified list of e-mail addresses.

As an organization administrator, you can change the settings for both the SMTP and e-mail notifications, or you can keep it as system administrator-defined settings. An organization administrator may also wish to override SMTP settings if an SMTP server is available for organizational use.

Let's look at configuring SMTP alert settings in vCloud Director. To configure SMTP alert settings in vCloud Director, follow the given steps:

  1. Log in to the vCD web portal as a system administrator.

  2. Click on the Administration tab and click on Email in the left pane.

  3. Type in the DNS host name or the IP address of the SMTP mail server.

  4. Type in the SMTP server port number.

  5. If the SMTP server requires a username, select the Requires authentication checkbox and type in the username and password for the SMTP account (this step is optional).

  6. Type in an e-mail address as the sender for vCloud Director e-mails. vCloud Director uses the sender's e-mail address to send runtime and storage lease expiration alerts.

  7. Type in the text to use as the subject prefix for vCloud Director e-mails.

  8. Type in a destination e-mail address to test the SMTP settings and click on Test SMTP settings.

  9. Click on Apply. Your screen should look similar to what is shown in the following screenshot:

Let's look at configuring warning alert settings in vCloud Director.

You can also configure the warning alerts in vCloud Director; for example, if your datastore is out of space, you can set the warning alert threshold. To do this, follow the given steps:

  1. Log in to the vCloud web portal as a system administrator.

  2. Click on the Manage & Monitor tab, and click on Datastores & Datastore Clusters in the left pane.

  3. Right-click on the datastore name and select Properties.

  4. On the General tab, select the disk space threshold values for the datastore.

  5. You can set two thresholds: yellow and red. When vCloud Director sends an e-mail alert, the message indicates which threshold was crossed. By default, the yellow threshold is set at 90 percent and red is set at 95 percent. However, if you increase the datastore size via the backbone, the setting needs to be adjusted.

  6. Click on OK. Your screen should look similar to what is shown in the following screenshot:

vCloud Director sends an e-mail alert to all VDCs where this datastore is attached when the datastore crosses a threshold.

Managing vCenter Chargeback reports

You can generate cost reports using VMware vCenter Chargeback Manager. This will include the cost and utilization information for each computing resource for the hierarchy or entity on which the report is generated. This information is based on the cost configured in the hierarchy and the pricing model selected during report generation.

Let's look at how to generate and archive basic reports. You can use vCenter Chargeback Manager to generate reports for a chargeback hierarchy and also for the entities within that hierarchy.

Also, if you look at the Archived Reports page of the Reports tab, it shows you a table that lists all the reports that are archived in the Chargeback Manager. This archived report includes manually generated and saved reports as well as reports that are generated by report schedules. Let's generate and manage archived basic reports by executing the following steps:

  1. Log in to the Chargeback Manager.

  2. In the Reports tab, click on Create Reports.

  3. Select the required chargeback hierarchy from the drop-down menu on the left pane of the page.

  4. Right-click on the hierarchy or the entity on which you want to generate the report and select Generate Cost Report from the pop-up menu.

  5. Provide the requested report details and click on Next.

  6. On the Report Summary page, select Include resource summary in report.

    You must also select the type of resource summary to be reported. The resource summary can either be complete (default) or basic.

  7. Select the computing resources whose usage and cost details have to be included in the report.

  8. Select Include cost summary in the report to include the summary of costs in the report. The cost summary can be either complete (default) or basic. Select basic.

  9. Click on Next.

  10. On the Details page, select the fixed cost details, usage-related details, and other information to be displayed in the report, and click on Next.

  11. (Optional) on the Attributes page, select Filter the report based on attributes to define attribute filters.

  12. Click on Submit.

    • The report is queued for generation. After the report is generated, it is displayed in vCenter Chargeback Manager.

    • A generated report can be archived and stored in the application. After you generate a report, the application displays the generated report.

  13. Click on the Archive Report icon above the generated report. A dialog that reports whether the action was successful or not is displayed.

  14. Click on OK.

If the report is archived successfully, the report can be accessed from the Archived Reports page.

 

Summary


In this chapter, we discussed the centralized logging facility of vCloud Director. We have also discussed and learned how to configure logging and how to configure vCloud Director for a scalable deployment. We have also learned how you can efficiently use the cell management tool to maintain vCloud Director better. This chapter also focuses on how to use Chargeback Manager for metering vCloud Director resource as well.

In the next chapter, we will focus on how to add vSphere resources to vCloud Director and manage vSphere storage and network resources.

About the Author

  • Lipika Pal

    Lipika Pal is a Technical Lead in Colt Technology Services for Cloud and Virtualization, where she provides users with technical guidance to design, implement, and manage VMware vCloud Datacenter IaaS services, rendering enterprise-class access to on-demand or long-term virtualized resources across UK and Europe.

    She has more than 7 years of expertise in professional services, designing and deploying virtualization solutions, and rolling out new technology and solution initiatives. Her primary focus is on the VMware vSphere infrastructure and public cloud using VMware vCloud Suite.

    One of her other ambitions is to own the entire life cycle of a VMware-based IaaS, especially, vSphere, vCloud Director, vShield Manager, and vCenter Operations. She holds certifications from VMware, Citrix, Red Hat, Cisco, and Zerto. Prior to joining Colt, she was a subject matter expert and an infrastructure architect at fine organizations such as IBM, HP, and Red Hat.

    Browse publications by this author