VMware vCenter Chargeback Manager 2.0 Release Notes

What's in the Release Notes

• What's New in this Release
• System Requirements
• Preinstallation Tasks
• Quick Install
• Upgrading vCenter Chargeback Manager
• Resolved Issues
• Known Issues
• Best Practices

What's New in this Release

The vCenter Chargeback Manager 2.0 provides various new features.

• Automatic Report Scheduler
  In vCenter Chargeback Manager, you can define automatic report schedulers. These schedulers create report schedules for hierarchies and entities that match the criteria specified in the automatic report scheduler. The automatic report scheduler scans all the hierarchies and creates report schedules for the hierarchies and entities that match the specified criteria.

• Charge thin and thick provisioned virtual machines differently
  In this release, you can charge thin provisioned disks and thick provisioned disks differently. By default, thin provisioned disks are charged for the actual usage of the disk. You can override this behavior to charge the thin provisioned disks as thick provisioned in your billing policy.

• Cost variance and cost optimization
  vCenter Chargeback Manager provides a cost variance graph in the report dashboard that lets you analyze the day-to-day change in cost for a selected hierarchy or entity. The graph shows cost data for the last 30 days and that projected for the next 3 months in sets of 30 days each. vCenter Chargeback Manager lists different cost optimization opportunities, such as oversized virtual machines, undersized virtual machines, idle virtual machines, and powered off virtual machines. Cost variance and cost optimization is displayed only for the vCenter Servers that are integrated with VMware vCenter Operations.

• Showback Report
  A showback report lets you analyze how the cost is distributed among the entities based on a specified distribution policy. It is a configurable report that does not include any costs when it is generated. You can specify the total cost, fixed cost, and resource weight in the generated report to obtain the cost for each entity and for each resource per entity. The cost per entity is calculated based on the distribution policy that you select when generating the show back report.

• Apply fixed cost based on virtual machine state
  In vCenter Chargeback Manager, you can now define fixed costs that will be applied on an entity only for the duration for which the virtual machine in the entity is powered on.

• Tier-based storage costing
  vCenter Chargeback Manager lets you define storage tiers and configure cost on the tiers. All the datastores under a tier will be charged uniformly as per the cost configuration settings on the tier. You can also include VM storage profiles in a tier. The storage profiles defined in vSphere are synchronized and the datastores are automatically grouped according to their storage profiles. The cost configuration defined on a profile is applied on all the datastores that match the storage profile. Similarly, the cost configuration defined on a tier is applied to all the datastores or storage profiles added to the tier.

• Support for raw device mapping
  vCenter Chargeback Manager accounts for usage of hard disks that use raw device mapping. The corresponding cost and usage data is reported for the virtual machines that have disks using raw device mapping.

• Complete support for vSphere 5.0 and vCloud Director 1.5
  vCenter Chargeback Manager 2.0 supports the new features introduced in vSphere 5.0, such as VM storage profiles, and that introduced in vCloud Director 1.5, such as support for an SQL Server database.

• Partial support for IPv6
  In this release, vCenter Chargeback Manager supports IPv6 over IPv4 on an experimental basis. You can provide URLs with IPv6 IP addresses when connecting to vCenter Servers, LDAP Servers, vCenter Chargeback Manager databases, and vCenter Server databases. Ensure that the IPv6 IP address is enclosed in square brackets [ ] in the URL as per the standard convention.

• VM Instance Cost support for all hierarchies in vCenter Chargeback Manager
  In vCenter Chargeback Manager 2.0, you can define fixed cost pricing matrices for virtual machines based on vCPU count and memory bundles. Unlike earlier releases, this functionality is now available for all the hierarchies created in vCenter Chargeback Manager.

• Support for burstable billing or 95th percentile billing for the external network traffic in vCloud Director
  You can now calculate the cost for external network traffic in your vCloud Director setup based on the 95th percentile transfer rate. Starting with this release, vCenter Chargeback Manager introduces the external network transmit rate and external network receive rate resources and the Burstable Utilization resource attribute for these resources. You can define a billing policy that has these resource-attribute pair in the expression to calculate the cost based on the 95th percentile transfer rate. vCenter Chargeback Manager calculate the 95th percentile value based on the daily samples. That is, vShield Manager Data Collector runs a job that accounts for the samples for the last 24 hours and computes the 95th percentile value based on these samples.

• Support for overage charging for org vDCs in the Allocation Pool model of vCloud Director
  In this release, vCenter Chargeback Manager provides the VMware Cloud Director apply overage charge on Allocation Pool vDC property for the Cloud Director Data Collector. This property must be set to true (default value is false) to account for the resource usage over and above the guaranteed reservation in vCloud Director. This is applicable only for CPU and memory. Also, you must use the VMware Cloud Director Overage Allocation Pool Cost Model to account for resource overage. You must, however, modify the cost model to define the base rate and overage rate for the resources.

• New cost models and billing policies for vCloud Director
  This release of vCenter Chargeback Manager introduces two new cost models and billing policies that are made available when you install the Cloud Director Data Collector.

  • VMware Cloud Director Actual Usage Cost Model: This cost model uses the new VMware Cloud Director Billing Policy - Actual Usage. This billing policy lets you calculate cost based on actual resource usage for all resources except count of networks, enabled IPSec VPN tunnel count, and NAT, DHCP, and firewall services. For these resources the allocation values defined in vCloud Director is used.
  • VMware Cloud Director Overage Allocation Pool Cost Model: This cost model uses the new VMware Cloud Director Billing Policy - Overage Allocation Pool. Only for this beta release, the billing policy calculates the overage cost for CPU based on actual usage and that for memory based on allocation. For external network transmit and external network receive the actual usage values are used and for all other resources the allocation values are used.

System Requirements

This section provides information about the supported operating systems, database management systems, and vCenter Server versions. The vCenter Chargeback Manager User's Guide provides detailed information about the system requirements for installing and running the application.

Supported Operating Systems

• Microsoft Windows Server 2003 with SP2 (32-bit and 64-bit)
• Microsoft Windows Server 2003 R2 (32-bit and 64-bit)
• Microsoft Windows Server 2008 (32-bit and 64-bit)
• Microsoft Windows Server 2008 R2 (64-bit)

You can install and run vCenter Chargeback Manager on any supported localized Windows operating system. However, all the labels and text messages in the installer and application user interface (including the plug-in in the vSphere Client) are displayed in English only. The application supports ASCII, extended ASCII, and non-ASCII characters. However, the characters are rendered correctly only if the client machine uses the appropriate fonts and the Web browser supports all the characters. The installer does not support all characters. Ensure that the information entered in the installer contains only the supported characters as specified in the install and upgrade instructions in this release notes and in the vCenter Chargeback Manager User's Guide.

Supported Database Management Systems
vCenter Chargeback Manager supports the Standard and Enterprise edition of the following database management systems:

• Microsoft SQL Server 2008 (x64) (with Service Pack 2)
• Microsoft SQL Server 2008 (Intel x86) (with Service Pack 2)
• Microsoft SQL Server 2005 (x64) (with Service Pack 2)
• Microsoft SQL Server 2005 (Intel x86)(with Service Pack 2)

vCenter Chargeback Manager supports the Standard and Enterprise edition of the following database management systems:

• Oracle Database 11g Release 2
• Oracle Database 11g Release 1
• Oracle Database 10g Release 2
• Oracle Database 10g Release 1

Supported vCenter Server Versions and vCenter Server Databases

• VirtualCenter Server 2.5 Update 3
• VirtualCenter Server 2.5 Update 4
• VirtualCenter Server 2.5 Update 5
• VirtualCenter Server 2.5 Update 6
• vCenter Server 4.0
• vCenter Server 4.0 Update 1
• vCenter Server 4.0 Update 2
• vCenter Server 4.0 Update 3
• vCenter Server 4.0 Update 4
• vCenter Server 4.1
• vCenter Server 4.1 Update 1
• vCenter Server 4.1 Update 2
• vCenter Server 5.0
• vCenter Server 5.0 Update 1

vCenter Chargeback Manager only supports vCenter Server databases that are created in Microsoft SQL Server or Oracle Database. vCenter Chargeback Manager does not support vCenter Server databases created in DB2.

Supported Web Browsers and Flash Player Plug-in

• Microsoft Internet Explorer 7.x, and 8.x
• Mozilla Firefox 4.x and 5.x
• Adobe Flash Player for Windows Plug-in version 10.1
• Adobe Flash Player for Linux version 10.1 (Plug-in for Mozilla Firefox running on Linux Platform)

Supported VMware Cloud Director Versions

• VMware Cloud Director 1.5

vCenter Chargeback Manager 2.0 does not support any release of VMware Cloud Director prior to VMware Cloud Director 1.5

Supported VMware vCenter Operations Versions

• VMware vCenter Operations 5.0

vCenter Chargeback Manager 2.0 does not support VMware vCenter Operations 5.0.1.

Preinstallation Tasks

Before you install and use the VMware vCenter Chargeback Manager application, you must perform the following tasks:

• Create a vCenter Chargeback Manager database and database user
  You must create a database for vCenter Chargeback Manager to store the application-specific data. Ensure that this database is not configured to be case-sensitive. In addition, you must also create a database user having permissions to create and delete schema, as well as read from and write to the database.
• Set a static IP address on the machine
  You must set a static IP address on the machine on which you plan to install vCenter Chargeback Manager. You can obtain a static IP address from your network administrator. Preferably, obtain and set static IP addresses on all the servers and databases that the application will communicate with.
• Ensure that MSI installation is enabled
  You must ensure that MSI installation is enabled on the machine. If it is not, you must manually install Microsoft Visual C++ 2005 Redistributable Package (x86) before running the vCenter Chargeback Manager installer.
• Check whether the required ports are free
  Ensure that the ports that you specify during the installation are free. While installing vCenter Chargeback Manager, you must specify the port numbers for the HTTP port (default 8080), load-balancer port (default 8009), and HTTPS port (default 443).
• Ensure that port exceptions are configured on Windows Firewall
  If Windows Firewall is enabled, you must set port exceptions for the HTTP, load-balancer, and HTTPS ports on the Windows Firewall. If these exceptions are not set, the application will not be usable.
• Ensure that system time of all the servers and databases are in sync
  You must ensure that the system time of the machines on which you install vCenter Chargeback Manager and vCenter Chargeback Manager database are in sync. If you plan to install a separate data collector on a different machine, then the system time of this machine must be in sync with that of the other machines.
• Ensure that the Windows user has the Log on as a service permission
  If you want to use the Windows Authentication option for the vCenter Chargeback Manager database, you must ensure that the Windows user has the Log on as a service permission. If this permission is not set on the user, the installation fails. Also, the installer must be run in the context of this Windows user.
• Ensure that the SQL Server Browser service is running if you are using a Microsoft SQL Server database and using the database instance name and a dynamic database instance port to connect to the vCenter Chargeback Manager database or vCloud Director database.
• Ensure that the vCenter Chargeback Manager database is case-insensitive.

Quick Install

Download the vCenter-CB-2.0.0-532574.zip file, and extract the contents on to the machine on which you want to install vCenter Chargeback Manager. Do not run the installer from a remote machine. To install vCenter Chargeback Manager:

1. Run the vCenter-CB.exe file.
   The installation wizard is displayed.
2. Click Next on the Introduction screen.
3. Accept the end-user license agreement, and click Next.
4. Provide the path for the installation directory, and click Next.
   Ensure that the installation directory path has at least one directory (for example, C:\vCenterChargeback\) and does not point to just a drive (for example, C:\). If the specified installation directory exists, ensure that it is empty. If the specified installation directory does not exist, the installer will create the directory. Also, the directory path must contain only ASCII characters.
5. Configure the following vCenter Chargeback Manager database-related information, and click Next:
   
   • Database Type: The type of database used to create the vCenter Chargeback Manager database. This can be either SQL SERVER or ORACLE.
   • Database URL: The IP address of the system on which the vCenter Chargeback Manager database is installed along with either the port at which the database listener service is running or the vCenter Chargeback Manager database instance name. The database instance name must contain only ASCII characters.
     For Oracle Database, the database URL can be in any of the following formats:
     
     • <IP Address>
     • <Host Name>
     For SQL Server, the database URL can be in any of the following formats:
     
     • <IP Address>
     • <Host Name>
     • <IP Address>\<Database Instance Name>
     • <Host Name>\<Database Instance Name>
     You can also specify a well formed JDBC URL that starts with 'jdbc' and contains the database name.
   • Database Port: (Optional) The port on which the database service is listening for requests. If the port number is not specified, the installer uses the default port. For an Oracle database, you must specify the TNS listener port if you are not using the default port 1521. For an SQL Server database, specify the database instance port if you are using a static port.
   • Database Name: Name of the database in which vCenter Chargeback Manager stores the application-specific data. For Oracle Database, ensure that you provide the service name and not the SID.
   • SQL Authentication Mode: This option is applicable only for SQL Server database. For an SQL Server database, the authentication type can be either SQL Server Authentication or Windows Authentication.
   • Database Username: The name of the database user. The database user must have privileges to create and delete schema, as well as read from and write to the database. If you select Windows Authentication for SQL Authentication Mode, you must provide the Windows user account name. The user name must be of the form <Domain_Name>\<User_Name>. The user must have the Log on as a service permission.
   • Database Password: Password for the user name that you have provided. If you select Windows Authentication for SQL Authentication Mode, you must provide the password for the Windows user account. Ensure that the Windows user account password does not contain any special characters. The installer might fail if the password contains special characters.
   If the installer successfully connects to the database, the next screen is displayed.
6. Enter the load balancer-related information, and click Next:
   
   • IP Address: Static IP address or the FQDN of the machine on which you are installing the load balancer. Do not use localhost instead of the IP address or FQDN.
   • Admin Email Address: Email address of the server administrator. Ensure that the email address contains only ASCII characters.
   • HTTPS Port: An unused port through which the Apache Server communicates. The load balancer listens on this port for user requests.
   If the specified port is free, the next screen is displayed.
7. Select Install vCenter Chargeback Server, enter IP address and port details for the vCenter Chargeback Manager, and click Next:
   
   • IP Address: Static IP address or the FQDN of the machine on which you are installing vCenter Chargeback Manager. Do not use localhost instead of the IP address or FQDN.
   • HTTP Port: An unused HTTP port through which vCenter Chargeback Manager communicates.
   • Load-Balancer Port: An unused port through which vCenter Chargeback Manager can communicate with the load balancer (Apache Server).
   • Server Instance Name: A user-defined name for the vCenter Chargeback Manager instance. This name is used by the load balancer to identify the instance. Ensure that the instance name contains only ASCII characters.
   If the specified ports are free, the next screen is displayed.
8. Enter a user name and password for the administrative account that will be used to manage the vCenter Chargeback Manager application, and click Next.
   The password must be less than or equal to 24 characters in length.
   Note: If you are using Oracle Database for your vCenter Chargeback Manager database, ensure that the user name for the administrative account contains only ASCII and non-ASCII characters. Extended ASCII characters in the user name is not supported. This restriction is not applicable if you are using Microsoft SQL Server for you vCenter Chargeback Manager database.
9. Select the Install Data Collector option and click Next.
   You must have at least one instance of the data collector that is running and registered with the application for the database synchronization jobs to run.
10. Review the information displayed on the Pre-Installation Summary screen, and click Install.
    The installer starts installing the various components and creating the database schema. If the installation is successful, the URL for accessing the vCenter Chargeback Manager application is displayed.
11. Note this URL, and click Done.
    The installer displays a dialog stating whether you want to generate your own SSL certificate.
12. Click Generate my own SSL Certificate.
    A command window is displayed.
    1. Provide a pass phrase for the default key and press Enter.
       You are prompted to enter the pass phrase three more times. Provide the same pass phrase and press Enter each time.
    2. Provide the required certificate information and press Enter.
       You are prompted to enter the following information:
       • Country Code: A two letter code for the country.
       • State or Province Name: Name of the state or province.
       • Locality Name: Name of the city or town.
       • Organization Name: Name of the organization.
       • Organization Unit Name: Name of the department or organization unit.
       • Common Name: Your name.
       • Email Address: An email address.
    3. Provide the requested extra attributes for the certificate and press Enter.
       You are prompted to enter the following information:
       • A challenge password: A user-defined password.
       • An optional company name: Company name. This is optional and can be left blank.
    4. Provide the pass phrase and press Enter.
       You are prompted to enter the pass phrase again. Provide the same pass phrase and press Enter.
    5. Press any key to complete the process and close the window.
    An SSL certificate is successfully installed.

For detailed install instruction, refer to the vCenter Chargeback Manager User's Guide.

Upgrading vCenter Chargeback Manager

You can upgrade an existing vCenter Chargeback 1.5 or later setup to vCenter Chargeback Manager 2.0. Refer to the vCenter Chargeback Manager Installation and Upgrade Guide for detailed instructions.

Resolved Issues

This section lists the issues that have been fixed in this release.

Report Management Issues

• Report displays usage and cost for a shared virtual machine under each parent multiple times
  If a virtual machine is shared among multiple parent folders, then the report displays cost and usage for this virtual machine, as per the attribution percentage defined, under each shared parent folder multiple times. This issue is fixed in this release.

• Scheduled reports are not generated if the user is deleted
  If a user is deleted from vCenter Chargeback Manager, then the report schedules created by this user fail to generate reports as per the defined schedule. vCenter Chargeback Manager displays an error and logs an exception corresponding to the report generation failure. This issue is fixed in this release.

• Error displayed when fetching archived reports
  When you try to fetch a report that was generated and archived by a user whose user ID is deleted from vCenter Chargeback Manager, the application fails to retrieve the report and displays an error stating that the object cannot be retrieved. This issue also occurs for scheduled reports that are archived where the reporting schedule was created by a user that no longer exists in the application. This issue is fixed in this release.

• Report generation schedule fails with an invalid XML error
  When generating a reporting schedule, if the recurrence range is shorter in duration than the recurrence pattern, then vCenter Chargeback Manager fails to create the schedule and throws an error similar to the following:
  Incoming XML is invalid.
  This issue is fixed. You can now successfully create schedules that have a recurrence range shorter than the reporting duration. For example, you can create a quarterly report schedule on September 28 with an end date of October 2 and all other values set to default. In this case, a report for the quarter July to September is generated on October 1. However, if the end date of the schedule is set as September 30, then the schedule is not triggered because it does not exist in the system on October 1 and, therefore, no report is generated.

• Unable to access an archived report generated by a report schedule
  If a user is given some privileges on a report schedule, he can access the report schedule but not the reports generated and archived by the schedule. vCenter Chargeback Manager does not implicitly assign the user any privileges for the reports generated by the schedule. This issue exists only for users who are not creator of the report schedule but have been assigned some privileges on the report schedule. This issue is fixed in this release. vCenter Chargeback Manager automatically assigns the Dependent Resources Update or Dependent Resource Read role to the user on the dependent resources. See the vCenter Chargeback Manager User's Guide for more information on these roles.

• Report generation fails with entity not found error
  If you backdate a hierarchy after adding a newly created vCenter Server entity to a hierarchy, which contains vCenter Server entities that were synchronized during the first run of the data collector synchronization jobs, then the newly created vCenter Server entity is also backdated by three months. Therefore, when you generate a report on this entity, vCenter Chargeback Manager throws an entity not found error. Also, if you generate a report on any of the parent entities of this entity, the report excludes this entity from the report. vCenter Chargeback Manager does not display or log any message stating the entity was excluded from the report. This issue is fixed in this release of vCenter Chargeback Manager.

• Report generation schedule is automatically changed
  If vCenter Chargeback Manager stops running and is restarted, all the reports generation schedules that were set to run during the period that the application was not running are immediately started. Also, these report generation schedules are automatically updated to run at this new time. For example, suppose you have created a report generation schedule that generates a daily report at 6:00 PM. If the application stops running at 4:30 PM, and you restart vCenter Chargeback Manager at 9:00 AM the next day, the report that had to be generated at 6:00 PM the previous day is generated at 9:00 AM instead. Also, the corresponding schedule is updated automatically to run at 9:00 AM everyday. This issue is fixed in this release. Report schedules that failed to trigger due to a vCenter Chargeback Manager down-time, are not triggered immediately after vCenter Chargeback Manager is restarted. The report schedules will generate report only during the next run after the vCenter Chargeback Manager service is restored.

Cost Management Issues

• Costs and usage reported is different as compared to that reported in the reports generated before upgrade
  After upgrading to vCenter Chargeback Manager 2.0, the costs and usage data reported might differ from that reported for the same duration and on the same entity before upgrade. This is due to some accuracy-related fixes in vCenter Chargeback Manager 2.0. In earlier releases, samples collected from vCenter Server were wrongly considered by treating their sample time as end time of the sample and the time zone to be the local time zone of the vCenter Chargeback Manager server. vCenter Chargeback Manager fixes this issue by reading the sample time correctly and considering the time zone as GMT.

• The end time for a one-time fixed cost applied on an entity is reported incorrectly
  You have applied a one-time fixed cost on an entity for different time periods and propagated the cost to the child entities. Also, one or more child entities under this entity have been moved within the parent entity's branch after the one-time fixed cost was applied. Now when you generate a report on this entity, the end time for the one-time fixed cost might be reported incorrectly for all the entities under the parent entity. This issue is fixed in this release.

Known Issues

The known issues in this release are listed in this section. Workarounds, if any, are provided in the issue description.

Hierarchy Management Issues

• vCenter Chargeback Manager does not show the status of the virtual machines
  This release of vCenter Chargeback Manager does not show the status of the virtual machines in the chargeback hierarchy and vCenter Server hierarchy. All the virtual machines in the hierarchies have the same icon and do not indicate whether they are powered on, suspended, or powered off. Also, the vCenter Server hierarchy displays all the virtual machines, including the ones that are suspended or powered off. This, however, does not affect the usage and cost calculation. The usage statistics that are used by vCenter Chargeback Manager to calculate the costs are tracked by vCenter Server and stored in the vCenter Server database.

• Changes to a chargeback hierarchy are not reflected in the concurrent user sessions
  Hierarchy creation, deletion, and renaming operations performed by a user are not automatically reflected in concurrent user sessions. The concurrent users must log out and then log in again to see these changes. Any other change to the chargeback hierarchy, such as adding or deleting an entity, might not reflect immediately in the concurrent user sessions. After a change is made to the chargeback hierarchy, the hierarchy must be manually refreshed in the concurrent user sessions. Users can refresh the chargeback hierarchy by clicking the refresh button next to the chargeback hierarchy or by loading another chargeback hierarchy and then reloading the chargeback hierarchy. The refresh button appears only if vCenter Chargeback Manager detects changes to the chargeback hierarchy.

• Re-added virtual machine does not have the cost information configured on it
  If you delete an ESX host from a vCenter Server, all the virtual machines belonging to the ESX host are deleted from the chargeback hierarchy. After re-adding the ESX host to the vCenter Server, you can add the virtual machines on this ESX host back to the respective chargeback hierarchies in vCenter Chargeback Manager. However, any entity-specific cost configuration set on the virtual machines prior to deleting the ESX host from the vCenter Server is lost. You must, therefore, migrate all the virtual machines on an ESX host before removing the ESX host from the vCenter Server.

Cost Management and Configuration Issues

• Storage cost for non-compliant virtual machines is calculated using the rate factor set on the datastore
  For non-compliant virtual machines, vCenter Chargeback Manager uses the rate factor set on the datastore in which the virtual machine resides. If the datastore is grouped under any storage profile or tier, then the rate factors defined on the profile or tier is used. The rate factor for the profile configured on the non-compliant virtual machine is not used.

• Incorrect costs reported if resource allocation and fixed costs are set with a start time lesser than the hierarchy creation time
  If resource allocation and fixed costs are set on the hierarchy root node with a start time that occurs before the hierarchy creation time, then the report includes the costs incurred before hierarchy creation time if the reporting period start time also occurs before the hierarchy creation time. For example, you have created a hierarchy on February 1. You then set a fixed cost on the hierarchy root node starting from January 1 although the hierarchy is created only on February 1. Now, if you generate a report on the hierarchy with the reporting period start time as January 1, then the report includes the fixed cost from January 1 to January 31 in the report even though the hierarchy was created on February 1.
  This issue occurs only for allocation units and fixed costs set on the hierarchy root node. The workaround for this issue is that you set resource allocation units and fixed costs on the hierarchy root node with a start time equal to or greater than the hierarchy creation time. Or generate a report on the hierarchy where the reporting duration has a start time equal to or greater than the hierarchy creation time.

Report Management Issues

• Scheduling archived reports fails with an error post upgrade
  After upgrading to vCenter Chargeback Manager 2.0, when you schedule reports that were archived before upgrading the application, the schedule operation fails and vCenter Chargeback Manager displays an error. Reports created and archived post-upgrade can be successfully scheduled.

• Report includes the usage and cost information for secondary virtual machines
  If you enable fault tolerance on a virtual machine after the data collector has synchronized the vCenter Chargeback Manager inventory for the first time after installation, the report might include usage and cost information for the secondary virtual machines corresponding to the fault tolerance-enabled virtual machine. However, this cost and usage data included is for a very negligible time frame.

• Reports for a vCenter Server user might not contain the correct entities
  A report scheduled for a vCenter Server user might contain the usage and cost details for entities on which the user does not have permissions. The report might also exclude some entities on which the user has permissions. There is currently no workaround for this issue. However, reports might be generated correctly for the vCenter Server user whose credentials are used to add the vCenter Server to vCenter Chargeback Manager.

• Inconsistent usage and cost data reported
  If you generate a report that considers the actual resource usage for a billing period including the past 24 to 36 hours from the report generation time, the usage data and cost included in the report might be inconsistent. This inconsistency might occur if vCenter Server has not completed the statistics roll-up or the data collector has not synchronized the rolled-up statistics in the vCenter Chargeback Manager database.

• Cost variance graph in the report dashboard includes an extra day of costs for non-prorated fixed costs
  If a non-prorated fixed cost is set on a entity, then the cost variance graph for this entity includes the fixed cost for t + 1 days, where t is duration for which the cost is set on the entity. However, this issue does not occur in the cost reports.

Internationalization Issues

• Errors displayed while accessing vCenter Chargeback Manager from a localized version of Windows Server 2003
  In this release of vCenter Chargeback Manager, some errors might occur when you access the application from a Web browser on a localized version of Windows Server 2003 operating system. You should access vCenter Chargeback Manager from a Web browser on any operating system other than Windows Server 2003. There are currently no workarounds for this issue.

Other Issues

• vCenter Chargeback Manager shows duplicate datastore entries
  If a datastore is shared by more than one ESXi host and each ESXi host is added to different vCenter Servers, after adding these vCenter Servers to vCenter Chargeback Manager you can see the datastore listed multiple times in the vCenter Chargeback Manager UI. Let us consider a datastore is shared by two ESXi hosts and each of these are added to different vCenter Servers. You add both these vCenter Servers to vCenter Chargeback Manager. When you select DataStores on the Edit Infrastructure Cost page of the Configure Cost tab, this shared datastore is listed twice.
  You must ensure that you perform the same set of action on both these datastores entries in vCenter Chargeback Manager. That is to say, you must set the same rate factors on both the datastore entries and keep them under the same datastore tier always. Else, the corresponding cost and usage data reported might be inconsistent or erroneous. Also, if the datastores are appearing under different storage profiles, as a best practice ensure that the storage profiles are grouped in to the same datastore tier.

• The Hosts & Clusters and VMs & Templates Synchronization data collector jobs fails with an error
  You have added a vCenter Server, which does not have any datacenters, to vCenter Chargeback Manager. When you add the first datacenter to the vCenter Server, the Hosts & Clusters and VMs & Templates Synchronization data collector job fails and logs an error similar to the following:
  ERROR impl.HibernateVCenterBaseDAOImpl:
com.vmware.vim.vcenter.chargeback.dao.impl.HibernateVcEntityRelationDAOImpl@b3319f
org.hibernate.PropertyValueException: not-null property references a null or transient value:
com.vmware.vim.vcenter.chargeback.dto.CbVcEntityRelation.cbVcEntityByVcParentEntityId
  Workaround: Restart the Data Collector service.

• Correct reservation values are not reflected for expandable vApps and resource pools
  For expandable vApps and resource pools, the memory and CPU reservation values reflected in vCenter Chargeback Manager might differ from the actual reservation values as shown in vSphere Client. vCenter Chargeback Manager shows the last explicitly set reservation value for expandable vApps and resource pools. To ensure that the correct values are reflected in vCenter Chargeback Manager, you must edit the settings for the vApp or resource pool in vSphere Client and save the current reservation values.

• vCenter Chargeback Manager displays the disconnected hosts and orphaned virtual machines
  vCenter Chargeback Manager does not distinguish between connected and disconnected ESX hosts. Therefore, vCenter Chargeback Manager displays the disconnected hosts and orphaned virtual machines and accounts for the same in generated reports. Also, vCenter Chargeback Manager does not display the state of these ESX hosts and virtual machines. If a ESX host is disconnected from a vCenter Server and added to another vCenter Server, and both the vCenter Server instances are added to vCenter Chargeback Manager, then vCenter Chargeback Manager will display a duplicate entry for the ESX host. That is, vCenter Chargeback Manager will display an ESX host entry corresponding to the disconnected host and another corresponding to the host connected to the second vCenter Server. As a result, vCenter Chargeback Manager accounts for the disconnected host CPUs and orphaned virtual machines in vCenter Chargeback Manager licensing.

• vCenter Chargeback Manager throws an error when deleting vCenter Server
  When you delete a vCenter Server whose entities are added to a hierarchy, vCenter Chargeback Manager shows a dialog box asking whether you want to retain the entities or delete them from vCenter Chargeback Manager. If you choose to delete the entities, then an error message similar to the following is displayed:
  vCenter Server 'vcId' or it's 'Hosts & Clusters and VMs & Templates Synchronization' job is not found.
  However, the delete operation is successful. This error message is displayed only if the vCenter Server hierarchy is displayed in the Manage Hierarchy tab when the vCenter Server is deleted. You must close all the relevant error dialog boxes displayed to continue normal functioning of vCenter Chargeback Manager.

• Unable to download and install the vCenter Chargeback Manager plug-in from the Plug-ins Manager window of the vSphere Client
  This is a vSphere Client issue. Restart the vSphere Client and accept the vCenter Chargeback Manager SSL certificate. This might rectify the issue if the vSphere Client is able to communicate with vCenter Chargeback Manager. If the vSphere Client and vCenter Chargeback Manager are on different network domains, this issue might persist.

• vCenter Chargeback Manager instance is not recognized as a part of the cluster
  If you have a two-instance cluster and the first vCenter Chargeback Manager instance fails due to some reason, all the requests currently being served by the first instance are moved to the second instance. After the first instance is restarted, if the second instance fails, the requests handled by the second instance are not moved to the first instance. That is, the failover does not happen because the second instance does not recognize the first instance as a part of the cluster. A workaround for this issue is to restart all the vCenter Chargeback Manager instances in the cluster. This issue also occurs for clusters with more than two instances. If any of the vCenter Chargeback Manager instances fails and is restarted, that instance starts serving user requests but is not recognized by the cluster until other instances are restarted.

• The version of the vCenter Chargeback Manager plug-in in vSphere Client is not updated after upgrading to vCenter Chargeback 1.5
  After upgrading to vCenter Chargeback 1.5 from vCenter Chargeback 1.0.1, vSphere Client reports the plug-in version as 1.0.1 when you check the version from Plug-ins > Manage Plug-ins. Although the plug-in is upgraded, the plug-in version is reported incorrectly. However, the plug-in version is reported correctly when checked from Tools > About in the plug-in.

VMware Cloud Director Data Collector and vShield Manager Data Collector Issues

Some of the following listed issues are common for both the VMware Cloud Director Data Collector and the vShield Manager Data Collector.

• If the VMware Cloud Director database has a large history of chargeback events, the processing of the events might take a long time to complete.

• If VMware Cloud Director, vShield Manager instances, vCenter Chargeback Manager instances, and the corresponding databases and data collectors are not in the same timezone, then the data collectors might fail to process the events.

• A virtual machine added to the VMware Cloud Director setup is reflected in the corresponding vCenter Chargeback Manager hierarchy only if the lifetime of the virtual machine is greater than the frequency of the event processor job of VMware Cloud Director Data Collector.

• If chargeback events are not processed because of a failed vCloud Director data collector instance, then the entities in the hierarchy might not be charged correctly and consistently.

Best Practices

This section lists few best practices for using vCenter Chargeback Manager.

• If you are upgrading a vCenter Server added to vCenter Chargeback Manager, then stop the corresponding data collector service before upgrading vCenter Server. Restart the data collector after successfully upgrading the vCenter Server
• Do not use the administrator accounts of vCenter Server and vCloud Director and their corresponding databases when integrating with vCenter Chargeback Manager. Create separate application and database users with appropriate privileges for integration with vCenter Chargeback Manager.