Additional Issues
General Issues | Installation and Upgrade Issues | User Interface Issues | Documentation Issues
General
- If deploying AIX instances of a virtual system pattern fails due to errors with curl, you can fix the problem by editing the following file on the AIX server:
/0config/0config.sh
and add the following command so that it is the last line in the updateHostsFile function:
netcdctrl -t local -e hosts -f
When a new entry is added into the hosts file on setup, the hosts file is refreshed to ensure connectivity with Workload Deployer. If you make editions to a VM that you want to be part of the image going forward, prepare and capture the instance again via PowerVC.
- The option to specify user SSH keys is not supported If deploying virtual system (classic) on Power regions.
- When creating base images for Hyper-V, make sure that the kernel parameter no_timer_check is set to the kernel boot parameters in the bootloader configuration. Otherwise your image may fail to boot. Some Linux distribution versions may add this automatically when they detect they are running on Hyper-V.
- Deploying Windows instances with cloudbase-init and multiple NICs might fail because Windows operating system does not honor the order of the devices specified at deployment time.
- To resize an instance deployed on an Amazon EC2 region, the instance needs to be in stopped state.
- When creating base images for Windows, after installing Python, add the Python installation path to the PATH system variable.
- After changing the admin password as described in the topic http://www.ibm.com/support/knowledgecenter/SS4KMC_2.4.0.1/com.ibm.sco.doc_2.4/r_how_to_change_the_various_passwords.html, to continue to work with Public Cloud Gateway, you must perform the procedure described in the topic http://www.ibm.com/support/knowledgecenter/SS4KMC_2.4.0.1/com.ibm.sco.doc_2.4/public_cg/config/r_change_keystn_adminpw.html.
- The log file for the Hyper-V Compute Node is on the Hyper-v Server in the c:\Program Files (x86)\IBM\Cloud Manager with OpenStack\Hyper-V Agent\log\ directory.
- Hyper-V limitations:
- Virtual system patterns and virtual system patterns (classic) are not supported.
- Discovery and on-boarding of existing instances into IBM Cloud Orchestrator is not supported for Hyper-V.
- Resizing an instance will temporarily make the instance invisible in Hyper-V manager. It will be re-added once the resize is finished.
- Resizing the disk to a smaller size will result in an error.
- Deploying instances on a SoftLayer region fails if UserId and Password are not specified.
- If you are not able to start or stop the virtual machines and the following error is displayed in the nova-powervc.log file:
"ERROR powervc.nova.driver.compute.manager [-] Exception: Exception: 'NoneType' object has no attribute 'rstrip'"
stop and start the services on the PowerVC region server by using the SCOrchestrator.py command.
- An error might be returned when deploying an AIX machine with an attached disk and the pattern status might be "failed".
The following error is returned as part of the disk attach script:
*** basic validation of input
*** validation done
*** searching for uninitialized disk of size 1GiB
new pvs =
pvtouse=
ERROR : no free pv found of size 1
You can ignore the error because the volume is correctly attached to the machine and the virtual machine is fully functional. The only effect is that the overall status of the pattern is "failed".
- In a VMware region, after deploying a virtual machine, if you rename the virtual machine by using vCenter and then you change the flavor by using the Self-service user interface, the name of the virtual machine is set back to the original name.
- If an image has been imported to Glance with one of the following procedures:
- using the OpenStack command line interface to import disk image to Glance, as described in Adding images to your OpenStack environment;
- using the single disk OVA image that was imported to the Workload Deployer component and the image was checked out to the specified region;
the first provisioning of the virtual machine to the VMware hypervisor might:
- be slow (for example, might take more than 1 hour) when using single image deployment of Workload Deployer patterns;
- fail due to timeout (by default set to 1 hour) for the virtual machine registration phase in the OpenStack when deploying by using Workload Deployer patterns.
The problem does not occur after the first provisioning. If the provisioning fails due to timeout, you can trigger the provisioning manually to allow the transfer of the disk image to the target datastore.
- If a virtual machine is deployed with a virtual system pattern and you stop it from the ASSIGNED RESOURCES > Virtual Machines panel, the virtual machine is automatically restarted by the Workload Deployer component. To stop a virtual machine deployed with a virtual system pattern, perform the action from the PATTERNS > Instances > Virtual System Instances panel.
- For problems with deployment cloud services with additional software, see http://www.ibm.com/support/docview.wss?uid=swg21693715.
Installation and upgrade
- During installation and upgrade, IBM Cloud Orchestrator V2.4.0.1 passwords can contain only alphanumeric characters and underscores. Spaces, hyphens, and other special characters are not allowed.
- Before you upgrade from IBM SmartCloud Orchestrator V2.3.0.x or IBM Cloud Orchestrator V2.4.0 to IBM Cloud Orchestrator V2.4.0.1, ensure that the passwords do not include any special characters, or the upgrade is likely to fail. For instructions about how to change the passwords in IBM SmartCloud Orchestrator V2.3.0.x before the upgrade, see Changing the various passwords (V2.3). For instructions about how to change the passwords in IBM SmartCloud Orchestrator V2.4.0 before the upgrade, see Changing the various passwords (V2.4). It is not necessary to remove the special characters from operating system (OS) passwords.
- During the installation or upgrade, specify passwords that do not contain any special characters.
- After the installation or upgrade, change the passwords to include special characters in accordance with security best practices. For instructions about how to change the passwords after installation or upgrade, see Changing the various passwords (V2.4).
- When installing the central servers, you can specify a new parameter:
OrchestratorPassword= <External DB instance password>
- When installing a Region Server, OrchestratorPassword is required and must be the same for all jobs.
- When upgrading a deployed IBM Cloud Orchestrator environment, you must ensure that the Central Server services are restarted before you proceed to upgrade the Region Server jobs.
- The upgrade does not preserve any customization that are not part of the default configuration. If you manually edited or customized any of the following OpenStack configuration files, back up these files before running the upgrade to preserve your changes. To retrieve your manual changes, go to the pre-upgrade configuration files which are backed up into the following location on each of the servers in the table below: /var/chef/backup/etc/<componentName>/<fileName>.conf-<timestampOfBackup>
For example: /var/chef/backup/etc/nova/nova.conf.chef-20141112145321.465905
| Server | Component | Configuration files |
| Central Server 1 | Ceilometer | /etc/ceilometer/ceilometer.conf |
| Central Server 2 | Keystone | /etc/keystone/keystone.conf
/etc/keystone/keystone-paste.ini
/etc/keystone/policy.json |
| Region Server | Nova | /etc/nova/nova.conf |
| Region Server | Glance | /etc/glance/glance-registry.conf
/etc/glance/glance-api.conf |
| Region Server | Heat | /etc/heat/heat.conf |
| Region Server | Cinder | /etc/cinder/cinder.conf |
| Region Server | VMware Discovery
(VMware only) | /etc/vmware-discovery.conf |
| Neutron Server | Neutron | /etc/neutron/neutron.conf |
- When creating an external database and creating database nodes, note that:
Because both KVM region and VMware region use compute_db, image_db, network_db, orchestration_db, and volume_db, if you decide to install both KVM and VMware regions, you must create these DBs twice with different names.
For example, for compute_db:
ds node-create -t IBM::SCO::Database -p '{Address: 172.16.163.61, User: nova, Password: passw0rd, Name: openstac}' kvm_compute_db
ds node-create -t IBM::SCO::Database -p '{Address: 172.16.163.61, User: nova, Password: passw0rd, Name: openstac}' vmware_compute_db
- Before you upgrade, prepare the installation media and backup your servers.
For VMware-hosted Central and Region Servers, see Taking Snapshots topic in the VMware documentation to take snapshots for Central Servers and Region Servers.
- Dealing with upgrade failures:
If a problem occurs during job-update process and the job status is WARNING or ERROR, run the ds job-show <job ID> command to inspect the details of the job which also include the related error message. If insufficient information is available using the ds job-show command, you must inspect the logs in /var/log/ds/ ds-engine-<job ID>.log for further information. If it is evident that the issue being experienced is down to a mistake in performing the upgrade, you can fix the underlying issue and simply rerun the upgrade again by invoking the ds job-update <job ID> command again.
If, on the other hand, the upgrade job fails due to incorrect configuration and the job is not recoverable then you must be roll back the IBM Cloud Orchestrator servers, correct the underlying issue, and rerun the upgrade.
To roll back the IBM Cloud Orchestrator servers, do the following:
If the Central Server upgrade job failed, roll back all Central Servers. You do not need to roll back the Region Servers because the Region Server upgrade job does not run until the Central Server upgrade jobs are finished successfully. If the Central Server upgrade job has finished successfully, but the Region Server upgrade jobs failed due to incorrect configuration in the upgrade configuration file, roll back the Region Servers that failed to run the upgrade jobs. Then fix the underlying issue and rerun the upgrade again by invoking the ds job-update <job ID> command again.
- The upgrade procedure from 2.3 might fail if the DB2 users use a password that contains special characters. The installation log shows the following error:
Ran su - db2inst1 -c "(db2 'connect to openstac') && (db2 'grant dbadm on database to user dash') && (db2 'connect reset')" returned 4
To solve the problem, perform the following steps:
1. Back up the file <ICO_PACKAGE_PATH>/data/installer/chef-repo/cookbooks/db2-upgrade/recipes/db2-upgrade.rb
2. Edit the file and make the following changes:
- Add the following line before "DB2_DIR = node['db2']['inst_dir'] + 'V' + node['db2']['version']":
require 'shellwords'
- Change the following line:
node.override['db2']['instance_password'] = get_password 'user', node['db2']['instance_username']
to:
node.override['db2']['instance_password'] = Shellwords.escape(get_password 'user', node['db2']['instance_username'])
3. Continue to install the Deployment Service.
- When installing an Hyper-V region, in the http://www.ibm.com/support/knowledgecenter/SS4KMC_2.4.0.1/com.ibm.sco.doc_2.4/t_install_hyperv_usingcmo.html topic, perform the following steps:
- After step 9:
When planning to run with multiple Hyper-V compute nodes make sure all of them are enabled for live migration. For details see
http://docs.openstack.org/icehouse/config-reference/content/hyper-v-virtualization-platform.html
- Instead of step 11:
In c:\Program Files (x86)\IBM\Cloud Manager with OpenStack\Hyper-V Agent\etc\nova\nova.conf, set the following parameters:
force_config_drive=always
config_drive_inject_password=True
- Before the last step:
For multiple region, you must specify the following parameter in c:\Program Files (x86)\IBM\Cloud Manager with OpenStack\Hyper-V Agent\etc\nova\nova.conf:
cinder_endpoint_template=http://<RegionServer_FQDN>:8776/v1/%(project_id)s
- When installing a KVM Region Server with nova network in a high-availability environment, you do not have to specify the nova_db parameter when creating the deployment job.
- When installing a KVM Region Server with neutron network in a high-availability environment, the command to create the deployment job is:
ds job-create -t template_id -P
"RegionServerVirtualAddress=RegionServerVirtualAddress;
RegionServerVirtualHostname=RegionServerVirtualHostname;
RegionServerVirtualNetmask=RegionServerVirtualNetmask;
RegionServerVirtualTieBreaker=RegionServerVirtualTieBreaker; MGMNetInterface=net_interface;
OrchestratorPassword=External DB instance password" -N "saam=saam_nodeid;
kvm_region_server_p=kvm_region_server_p_nodeid;
kvm_region_server_s=kvm_region_server_s_nodeid;
neutron_network_node=neutron_network_node_nodeid;
compute_db=compute_db_nodeid;
image_db=image_db_nodeid; network_db=network_db_nodeid;
orchestration_db=orchestration_db_nodeid;
volume_db=volume_db_nodeid" -
p central_server_job_id
HA-kvm_region-with-compute-neutron-extdb_job
- When installing central servers in a high-availability environment as described in http://www.ibm.com/support/knowledgecenter/SS4KMC_2.4.0.1/com.ibm.sco.doc_2.4/t_install_ha_censerver.html, the following definition applies:
<CentralServer2VirtualAddress>
Is the virtual address to be used for Central Server 2. To achieve high availability, this server is run on two instances. Each instance requires its own IP address. The virtual address is an additional IP address, which is assigned to the active virtual machine of a System Automation for Multiplatforms cluster. If the primary virtual machine fails, the virtual address is moved to the secondary virtual machine, and the secondary virtual machine become the active virtual machine. Applications access the services running on this high availability cluster by using the virtual IP address.
Note: You must create the IP address in the DNS server, there is no need that the virtual machine exists.
- When installing a region server in a high-availability environment as described in the following topics:
the following definition applies:
RegionServerVirtualAddress
Is the virtual address to be used for Region Server. To achieve high availability, this server is run on two instances. Each instance requires its own IP address. The virtual address is an additional IP address, which is assigned to the active virtual machine of a System Automation for Multiplatforms cluster. If the primary virtual machine fails, the virtual address is moved to the secondary virtual machine, and the secondary virtual machine become the active virtual machine. Applications access the services running on this high availability cluster by using the virtual IP address.
- During the upgrade process from 2.4.0 to 2.4.0.1, existing Categories, Actions, and Offerings are not updated to keep the changes that you could have made to these artifacts. If you want to update the artifacts with the changes released in version 2.4.0.1, follow the steps outlined in technote 1693756: Manual steps after upgrading from version 2.4.0 to 2.4.0.1.
User interface
- You are unable to log in to the Administration user interface when a Public Cloud Gateway-only region is installed.
Review technote 1693756: Unable to log in to the Administration user interface when a Public Cloud Gateway-only region is installed for solution.
- Because of an OpenStack limitation, in the Administration user interface, PowerVC hypervisors are always displayed with an active status. This limitation might cause that IBM Cloud Orchestrator tries to deploy virtual machines to an inactive hypervisors.
- Each IBM Cloud Orchestrator user interface URL includes the following specification:
https://central-server-ihs_fqdn
where central-server-ihs_fqdn is the fully qualified DNS domain name of the Central Server where the IBM HTTP Server is installed. In a multiple-region deployment, the IBM HTTP Server is installed on Central Server 2.
In High-Availability Distributed installations, central-server-ihs_fqdn is the host name of the virtual address used for Central Server 2, that is the value specified for the CentralServer2VirtualHostname parameter at installation time. For more information, see Installing the Central Servers.
- The online help in the IBM Cloud Orchestrator user interface opens the IBM Cloud Orchestrator V2.4 documentation topic instead of the V2.4 Fix Pack 1 documentation topic.
To open the correct documentation topic, update the URL to specify "SS4KMC_2.4.0.1" instead of "SS4KMC_2.4.0", as shown in the following example:
http://www.ibm.com/support/knowledgecenter/SS4KMC_2.4.0.1/com.ibm.sco.doc_2.4/c_sw_prereqs.html
Documentation
- In the IBM Knowledge Center topic Virtual system instances (classic) REST API, in the POST /resource/virtualSystems example, the initial part of the request JSON is:
{
"environmentProfile": "/resources/environmentProfiles/1",
"endtime": 1260000000000,
"name": "sample virtual system instance",
"parts": [{
"description": "Deployment manager",
"label": "Deployment manager",
"id": 1,
"cloudid": 81,
"flavor": "m1.tiny",
"ipgroupid": 81,
"ipaddresses":[{
.....
|
Problems (APARS) fixed
Problems (APARS) fixed