CloudPlatform 4.5.0.0 Hotfix 06

Who Should Install This Hotfix?

This is CloudPlatform 4.5.0.0 Hotfix 06. This Hotfix is for customers running Citrix CloudPlatform versions 4.5.0.0, 4.5.0.0 Hotfix 01, 4.5.0.0 Hotfix 02, 4.5.0.0 Hotfix 03, 4.5.0.0 Hotfix 04, or 4.5.0.0 Hotfix 05.

CloudPlatform 4.5.0.0 Hotfix 06 also includes 4.5.0.0 Hotfix 01, 4.5.0.0 Hotfix 02, 4.5.0.0 Hotfix 03, 4.5.0.0 Hotfix 04, and 4.5.0.0 Hotfix 05. So, the customers running CloudPlatform 4.5.0.0 can upgrade to this Hotfix directly.

Package Name

CloudPlatform-4.5.0.0_HF_06.zip

Issues Resolved In This Hotfix

This Hotfix resolves the following issues:

Note:

• To view the issues resolved in 4.5.0.0 Hotfix 01, 4.5.0.0 Hotfix 2, and 4.5.0.0 Hotfix 3, see http://support.ctx.org.cn/CTX142338.citrix.

• To view the issues resolved in 4.5.0.0 Hotfix 04, see http://support.ctx.org.cn/CTX142449.citrix.

• To view the issues resolved in 4.5.0.0 Hotfix 05, see http://support.ctx.org.cn/CTX142584.citrix

• CS-44048: Problem: Consecutive cold migration of VMs fail.

  Root Cause: If a VM is cold migrated between the clusters that belong to two different VMware datacenters, CloudPlatform unregisters the VM from the source host and cleans up the associated VM files. CloudPlatform verifies whether a VM is being cold migrated across datacenters using the source ID. In case of consecutive cold migrations, as the source host ID of a VM is NULL and no VM exists, CloudPlatform should skip this verification.

  Solution: Attempt to unregister a VM in another datacenter only if there is a host associated with a VM.

• CS-44023: Problem: VM usage is stopped after out of band migration. The VmSync job does not provide the start event.

  Root Cause: If the old state of a VM is Started and the new state is Running, the VM is in the Started state. In case of migration through Vmotion, the VM state goes from Stopped to Running.

  Solution: Add another conditional check for VmStarted with the old state as either Starting or Stopped and the new state as Running.

• CS-43944: Problem: A template that is copied to a new zone stopped charging after the original template is removed.

  Root Cause: This is due to incorrect query, which does not have the zone filter.

  Solution: Changes has been made to add zone filter while processing the TEMPLATE.DELETE event.

• CS-43923: Problem: Usage job generates usage even if there is an exception while processing usage events. This corrupts the usage data.

  Root Cause: The exception that is raised while processing usage events gets suppressed inside the catch block.

  Solution: Removed the catch block that suppresses the exception.

• CS-43922: Problem: VM.START usage event is logged twice by VM synchronization and VM deployment operations.

  Root Cause: CloudPlatform creates a worker job when a VM deployment operation starts. The VM synchronization operation thread cannot update the VM state as long as this worker job is on queue. This worker job gets deleted after the completion of the VM deployment operation, which, ideally, must not exceed one hour. If the VM deployment operation exceeds one hour, the worker job clean up thread that is configured using the vm.op.cleanup.wait parameter removes this worker jobs from the database. This allows the VM synchronization thread to update the state of the VM. This results in the logging of duplicate VM.START usage event. As a result of this, the copy template operation may consume more than the expected time to complete.

  Solution: If the VM deployment operation exceeds one hour, you must modify the value of the vm.op.cleanup.wait parameter to two hours.

• CS-43748: Problem: Layout issues are observed after logging onto CloudPlatform by choosing Japanese as the language.

  Root Cause: When printed in Japanese, the word 'Default View' available in the Project combo box exceeds the width of the box. The word splits into two lines. Because of this, the other boxes moves down or moves out of the boxes.

  Solution: Increased the custom width value for that field so that words in all languages would fit in the field.

• CS-42586: Problem: When performing listHosts, KVM hosts display the root user credentials in the details block of the returned information.

  Root Cause: While displaying host_details for the KVM hosts, password details are not omitted.

  Solution: Removed password from the host details while creating response for the KVM host listing.

• CS-42386: Problem: Storage XenMotion fails after applying CloudPlatform 4.5.0.0 HF 5.

  Root Cause: Storage motion of VM across clusters/XenServer-pools fails in a clustered Management Server configuration. In XenServer storage motion, the migrate_receive command is being sent to the destination host followed by the migrate_send command to the source host. The storage and network details of the destination host will be passed to the source through the migrate_send command. While migrating across clusters, the source and the destination resources are separate objects. To pass this information across resources, need to send separate migrate with storage receive and send commands to the resource. In a clustered Management Server setup these commands may have to be forwarded to another Management Server as the resource may be owned by it. In such a case, the serialization of the command and the answer objects fails as it does not understand the xapi storage and network objects.

  Solution: Ensure that the xapi objects are serialized/de-serialized in the resource layer as it is aware of the object types.

• CS-42385: Problem: Network usage is not reported as per aggregation range occasionally. It gets accumulated to next period data.

  Root Cause: In a cluster Management Server setup, Management Server with maxId is supposed to run the aggregation task. If a Management Server that is not designated to run the job holds the lock for a longer time, Management Server designated to run the job will wait for lock and eventually timeout. This results in the aggregation task not being run for that schedule.

  Solution: Modified the code such that the Management Server designated to run the aggregation task (Management Server with maxId) acquire the lock.

• CS-42282: Problem: Root administrator cannot update/modify the network from an account in another domain.

  Root Cause: The list NetworkId API call returns empty response enev after passing the ID of the network. this is because the network is not owned by the administrator of the Root domain.

  Solution: Added listall=true to the list API.

• CS-42216: Problem: Random failure of list VM at scale when the VM has resource tags.

  Root Cause: If a VM that the List VM API fetches from the user_vm_view is destroyed and, later, a response generation occurs for the destroyed VM, the database query to fetch resource tag details from resource_tag_view returns empty. This is because the resource tag has already been deleted from the database as part of the VM destroy operation. Because there is no check for this condition in the resource tag fetching code, the exception occurs.

  Solution: Resource tag query based on ID may return a record or null if the record is deleted. Added a check handling null scenario.

• CS-42030: Problem: When XenServer is upgraded from version 6.2 to version 6.5 in CloudPlatform, security group rules are not correctly updated with the vif details on VM restart. Due to this vm ingress/egress traffic is blocked.

  Root Cause: On VM restart, when security group rules are get deleted with old vif and added with the new vif details. Issues with Python in XenServer 6.5 cause truncating the target in the IPtable rule.

  Solution: Update the vmops to update the rules correctly.

Note

The CopyScriptstoHosts.py script, which is automatically called as part of hotfix installation, copies the vmops file to all the XenServer hosts. You do not need to manually copy the vmops file to the XenServer hosts anymore.

Known Issues In This Hotfix

This Hotfix contains no known issue:

MD5 of the HotFix

Verify the MD5 of downloaded HotFix CloudPlatform-4.5.0.0_HF_06.zip: 35d4720c7614e27cc9dc311667abc69e

Installing the Hotfix

Before Installing

The attachment to this article is a .zip file. It contains the hotfix update package. Use the following steps to install this update. As with any software update, please back up your data before you apply this hotfix.

1. Stop all Usage Servers if running. Run this command on all Usage Server hosts:

   # service cloudstack-usage stop

2. Stop the Management Servers. Run this command on all Management Server hosts:

   # service cloudstack-management stop

Citrix recommends you to perform this step even in test installations. Performing this step will assist with debugging if you face any issue.

3. On the MySQL master, backup the MySQL databases.

   In the following commands, it is assumed that you have set the root password on the database, which is a CloudPlatform recommended best practice. Substitute your own MySQL root password.

   # mysqldump -u root -p<mysql_password> cloud > cloud-backup.dmp
   # mysqldump -u root -p<mysql_password> cloud_usage > cloud-usage-backup.dmp
   # mysqldump -u root -p<mysql_password> cloudbridge > cloudbridge-backup.dmp
   

   Note: Backup the cloud_bridge database if this database is installed in your environment.

Installing the Hotfix

1. Unzip the hotfix file:

   # unzip CloudPlatform-4.5.0.0_HF_06.zip

   The following files have been included:

   • cloud-api-4.5.0.0.jar
   • cloud-core-4.5.0.0.jar
   • cloud-engine-orchestration-4.5.0.0.jar
   • cloud-engine-schema-4.5.0.0.jar
   • cloud-engine-storage-snapshot-4.5.0.0.jar
   • cloud-framework-jobs-4.5.0.0.jar
   • cloud-plugin-hypervisor-vmware-4.5.0.0.jar
   • cloud-plugin-hypervisor-xenserver-4.5.0.0.jar
   • cloud-server-4.5.0.0.jar
   • cloud-usage-4.5.0.0.jar
   • cloud-vmware-base-4.5.0.0.jar
   • vmops
   • dictionary2.jsp
   • index.jsp
   • chosen.css
   • chosen.css.gz
   • cloudstack3.css
   • cloudstack3.css.gz
   • chosen.jquery.js
   • chosen.jquery.js.gz
   • network.js
   • network.js.gz
   • projects.js
   • projects.js.gz
   • zoneWizard.js
   • zoneWizard.js.gz
   • detailView.js
   • detailView.js.gz
   • projectSelect.js
   • projectSelect.js.gz
   • messages.properties

2. Change directory:

   # cd CloudPlatform-4.5.0.0_HF_06

3. Run the following to replace the files on the Management Server.

   # ./install-patch.sh

4. You will be prompted with an interactive interface with the following options:

   1. List the latest installed HotFix on this server
   2. List the HotFix to be installed
   3. Install this HotFix
   4. List restore points
   5. Restore from available restore points
   6. Quit

   [1-6] >

   Choose 1 to view current patch level of your system.
   Choose 2 to view the Hot Fix to be installed.
   Choose 3 to install Hot Fix.
   Choose 4 to view the available Restore points.
   Choose 5 to restore from available restore points.

5. Install the Hotfix.
   After the successful installation of the Hotfix, "Installed hotfix ..." message is displayed.

6. Repeat the above steps on each Management Server node except step #3 in the Before Installing section. Backing up databse is a one-time activity.

Post Installation Procedure

1. Start the first management server and wait until the successful completion of database upgrade. You can verify the completion of DB upgrade either by querying the database directly or by verifying the log statements from Management Server. On successful completion of the database upgrade, you can view log statements similar to "Upgrade completed for version 4.5".

   # service cloudstack-management start

2. Start the remaining Management Servers.

3. Start the Usage Servers that you have stopped. Perform this on each Usage Server host.

# service cloudstack-usage start

4. Log on to the CloudPlatform UI as administrator, and check the status of the hosts.

   All hosts should come to the Up state, except those that you know to be offline. You may need to wait 20 or 30 minutes, depending on the number of hosts.

Troubleshooting:

If logon fails, clear your browser cache and reload the page.

Special Instructions for Customers Upgrading Directly from CloudPlatform 4.5.0.0

Note

This applies to the users who are upgrading to a Hotfix release for the first time.

• Apply the following to zones that meet the following three conditions:

  • ??
    • Zones are created after installing or upgrading to 4.5.0.0 and before installing any hotfixes.
    • Are using XenServer hypervisor.
    • Created with more than one traffic name label with traffic going through multiple NICs.
  • Reedit XenServer traffic label attribute for public, guest, management, storage networks to match the labels already defined on the hypervisor host under zones.
  • Restart System VMs, Virtual Routers, and guest VMs under zones.

• To stop/start the System VMs, Virtual Routers via the command line, use the following cloudstack-sysvmadm script.

If the value of integration.api.port is not set to 8096, you must set the value to 8096 and restart the Management Server before you run the following command. Enabling integration.api.port will enable unauthenticated API access. So, you must either disable it or provide limited access to it through firewall rules:

# cloudstack-sysvmadm -d <DB IP address> -u cloud -p <password> -s -l <location-log-file>

<DB IP address> is the IP address of the cloud database server. If you have not specified this, localhost is used by default.

Also, you can specify any location to collect the logs. Default location is cloud.log under current directory.

For accessing help, run: cloudstack-sysvmadm –h