The issues discussed in this section are specifically related to VM instances.
One reason a VM instance can be in an error state is that you tried to install a VM instance that is a different architecture from the host system. In this case, you might not receive an error message that specifically indicates an architecture mismatch. To avoid this problem, make sure you correctly set the architecture property of the image when you upload the image to the glance image store. When you use Horizon to upload an image, you must set properties on the image after the upload. Alternatively, you can use the command line to upload the image and set property values in one glance image-create command. See Preparing Images for the Glance Repository for an example.
Some of the information that OpenStack reports about a VM instance does not match the information that Oracle Solaris reports about the corresponding zone. Information displayed in Horizon or displayed by the nova command might not match information displayed by the zoneadm command or other Oracle Solaris commands.
The name of a VM instance as shown in Horizon or as shown by the nova list command is the name that you assigned when you created the instance, such as example-instance. The name of the zone shown by the zoneadm list command is similar to instance-00000001. Use the nova show command to determine which zone is associated with which VM instance. In the nova show output, the value of the OS-EXT-SRV-ATTR:instance_name property is the name of the zone, and the value of the name property is the name of the VM instance.
The UUID of a VM instance as shown in Horizon or as shown by the nova show command does not match the UUID of the same zone as shown by the zoneadm list -p command. The UUID that the zoneadm command shows is a different identifier from the identifier used for Nova.
The number of VCPUs for a VM instance as shown in Horizon is the number of capped CPUs that are virtualized only to the extent of how many fractional CPUs can be used by the instance. This number does not provide observability inside the instance of what was capped. The psrinfo command reports the dedicated CPUs allocated to the zone.
The amount of memory for a VM instance as shown in Horizon might be different from the amount of memory that the prtconf command shows when you are logged into that VM instance. Horizon shows the amount of memory specified by the flavor used to create the VM instance. The prtconf command reports all of system memory.
The amount of storage for a VM instance as shown in Horizon might be different from the amount of storage shown when you are logged into that VM instance, unless the VM instance is a non-global zone using Zones on Shared Storage (ZOSS).
On certain occasions, you might encounter error messages related to incorrect credentials which prevent you from issuing service commands. For example, when issuing a glance command, the following error message might be generated:
Invalid OpenStack Identity credentials.
The root cause of this message can be different each time. Thus, you must examine the logs to restrict the possible causes. With the glance service as an example, see the contents of the Glance SMF service logs. The /var/log/glance/api.log might report the following:
WARNING keystonemiddleware.auth_token [-] Authorization failed for token
If you have set Debug = True and Verbose = True in the glance configuration files, more details are provided in the /var/svc/log/application-openstack-glance-glance-api:default.log such as the following:
DEBUG keystonemiddleware.auth_token [-] Received request from user: user_id None, project_id None, roles None service: user_id None, project_id None, roles None __call__/usr/lib/python2.7/vendor-packages/keystonemiddleware/auth_token.py:821
You can explore the following areas to resolve the issue.
Check your service configuration files to ensure that the relevant parameters are correctly defined.
Check that the global shell variables for the service are correctly. For the Glance service, for example, the following variables should be set:
OS_USERNAME=glance
OS_PASSWORD=service-password
OS_TENANT_NAME=service
OS_AUTH_URL=http://$CONTROLLER_ADMIN_NODE:5000/v2.0
If the command continues to fail with the same error messages reported, you might need to re-create the service user to generate new credentials. Study the following example:
# export OS_USERNAME=keystone # export OS_PASSWORD=service-password # export OS_TENANT_NAME=service # export OS_AUTH_URL=http://$CONTROLLER_ADMIN_NODE:5000/v2.0 # keystone user-list
From the output of this command, note the ID number of the corrupted service user. You would delete that user and then recreate it with the correct credentials:
# keystone user-delete user-ID # keystone user-create --name glance --password service-password # keystone user-role-add --user=glance --tenant=service --role=admin