This section describes software-related limitations and workarounds.
The Oracle Virtual Compute Appliance X3-2 shipment contains a printed copy of the Oracle Virtual Compute Appliance Quick Start Poster. It provides instructions to configure the appliance after initial power-on. The screenshot in step 10-C shows dummy IP addresses for the management nodes, virtual IP and default gateway. Be sure to replace them with three reserved IP addresses and configuration parameters from your own data center network. DO NOT apply the dummy configuration – or any reserved internal address ranges (192.168.4.x, 192.168.140.x, 192.168.40.x) – because that will make the Oracle Virtual Compute Appliance Dashboard and Oracle VM Manager user interface permanently inaccessible.
There is no workaround. Reinstallation is required to return the Oracle Virtual Compute Appliance to normal operation.
Bug 17457001
In the Oracle Virtual Compute Appliance Dashboard, the Network Setup tab becomes available when the first compute node has been provisioned successfully. However, when installing and provisioning a new system, you must wait until all nodes have completed the provisioning process before changing the network configuration. Also, when provisioning new nodes at a later time, or when upgrading the environment, do not apply a new network configuration before all operations have completed. Failure to follow these guidelines is likely to leave your environment in an indeterminate state.
Workaround: Before reconfiguring the system network settings, make sure that no provisioning or upgrade processes are running.
Bug 17475738
As described in Chapter 2, Mandatory Update of Release 1.0.1, the Oracle Virtual Compute Appliance software must be updated before the system can be fully configured. If you change the system password in the Network Setup tab of the Oracle Virtual Compute Appliance Dashboard prior to updating the software, only a subset of the appliance components will accept the password change. To recover from this situation, a complete re-installation of the appliance is required.
Workaround: First, execute the mandatory update procedure. Change the Oracle Virtual Compute Appliance system-wide password only after a successful software update.
Bug 17542460
If you have successfully logged on to Oracle VM Manager and then attempt to log on to the Oracle Virtual Compute Appliance Dashboard, the latter returns an HTTP 404 or Not Found error message. The issue is caused by a shared session ID cookie between both user interfaces. However, both can be viewed simultaneously.
Workaround: Log on to the Oracle Virtual Compute Appliance Dashboard first, then log on to Oracle VM Manager. Both web interfaces can be used side by side.
Bug 17315730
When several users log in to the Oracle Virtual Compute Appliance Dashboard, various error and exceptions may occur. This is caused by the Dashboard initializing its database tables whenever a user logs in. When an additional user logs in, the state of the current user's operations is wiped out, which causes instability.
Workaround: Only one user should be logged in to the Oracle Virtual Compute Appliance Dashboard at any given time.
Bug 17704931
User-configurable network settings are defined in the Network Setup tab of the Oracle Virtual Compute Appliance Dashboard. When you click OK to apply the new settings, the entries in each field are validated. If an invalid entry is found, the network configuration is not updated, even though you may already have confirmed the changes.
Workaround: Verify your entries in each field of the Network Setup tab, make the necessary corrections, and apply the new configuration again.
Bug 17360826
Among the user-configurable network settings in the Network Setup tab of the Oracle Virtual Compute Appliance Dashboard are three DNS fields. When you apply a configuration with multiple DNS entries, you can no longer remove the second or third entry. Also, when you apply a configuration with two DNS entries, you can no longer add a third DNS.
Workaround: Set the values
for DNS with care and double-check them before applying the
new network configuration. If you need to disable the second
or third DNS entry later, replace it in the Network Setup tab
with
0.0.0.0
and apply the new configuration.
Bug 17626460
When updating the user-configurable network settings through the Network Setup tab of the Oracle Virtual Compute Appliance Dashboard, the new configuration may take a long time to load, or is sometimes not applied. As long as the necessary services have not restarted successfully, the management nodes are not reachable at their newly assigned IP addresses. You can verify public network connectivity by attempting to log into the Dashboard at the new address.
Workaround: After applying the new network configuration, wait for the affected services to restart. The settings can only become active after a successful restart. If the services do not restart correctly in approximately 10 minutes, reload the page from the old address and - only as a last resort - reapply the configuration.
Bug 17475229
External time synchronization, based on
ntpd
, is left in default configuration at the factory. As a
result, NTP does not work when you first power on the
Oracle Virtual Compute Appliance, and you may find messages in system logs
similar to these:
Oct 1 11:20:33 ovcamn06r1 kernel: o2dlm: Joining domain ovca ( 0 1 ) 2 nodes Oct 1 11:20:53 ovcamn06r1 ntpd_initres[3478]: host name not found:0.rhel.pool.ntp.org Oct 1 11:20:58 ovcamn06r1 ntpd_initres[3478]: host name not found:1.rhel.pool.ntp.org Oct 1 11:21:03 ovcamn06r1 ntpd_initres[3478]: host name not found:2.rhel.pool.ntp.org
Workaround: Apply the appropriate network configuration for your data center environment, as described in the section Network Setup in the Oracle Virtual Compute Appliance X3-2 Administrator's Guide. When the data center network configuration is applied successfully, the default values for NTP configuration are overwritten and components will synchronize their clocks with the source you entered.
Bug 17548941
When network services are restarted on the master management
node, the connection to the Oracle VM management network (
bond0
) is lost. By design, the
bond0
interface is not brought up automatically on boot, so that the
virtual IP of the management cluster can be configured on the
correct node, depending on which management node assumes the
master role. While the master management node is disconnected
from the Oracle VM management network, the Oracle VM Manager user
interface reports that the compute nodes in the server pool
are offline.
The management node that becomes the master, runs the Oracle VM
services necessary to bring up the
bond0
interface and configure the virtual IP within a few minutes.
It is expected that the compute nodes in the Oracle VM server pool
return to their normal online status in the Oracle VM Manager user
interface.
You should never manually disconnect or restart networking on any node. Manual intervention should only be necessary in rare situations where the master management node fails to connect automatically.
Workaround: If the master
management node does not reconnect automatically to the Oracle VM
management network, bring the
bond0
interface up manually from the Oracle Linux shell. For detailed
instructions, refer to
Oracle VM Server Pool Is Offline After Network Services Restart
in the Oracle Virtual Compute Appliance X3-2 Administrator's Guide.
Bug 17345384
Towards the end of the management node
install.log
file, the following warnings
appear:
> WARNING: > /lib/modules/2.6.39-300.32.1.el6uek.x86_64/kernel/drivers/infiniband/ \ > hw/ipath/ib_ipath.ko needs unknown symbol ib_wq > WARNING: > /lib/modules/2.6.39-300.32.1.el6uek.x86_64/kernel/drivers/infiniband/ \ > hw/qib/ib_qib.ko needs unknown symbol ib_wq > WARNING: > /lib/modules/2.6.39-300.32.1.el6uek.x86_64/kernel/drivers/infiniband/ \ > ulp/srp/ib_srp.ko needs unknown symbol ib_wq > *** FINISHED INSTALLING PACKAGES ***
These warnings have no adverse effects and may be disregarded.
Bug 16946511
Compute node provisioning fails if services on the management node are shut down or restarted during the process. For example, upgrading management nodes involves restarting services. Adding compute nodes to the system must be avoided at such times.
Workaround: When adding a compute node to the environment, make sure that there are no active processes that may interrupt services on the management node.
Bug 17431002
The role of the Node Manager database is to track the various states a compute node goes through during provisioning. After successful provisioning the database continues to list a node as running, even if it is shut down. For nodes that are fully operational, the server status is tracked by Oracle VM Manager. However, the Oracle Virtual Compute Appliance Dashboard displays status information from the Node Manager. This may lead to inconsistent information between the Dashboard and Oracle VM Manager.
Workaround: To verify the status of operational compute nodes, use the Oracle VM Manager user interface.
Bug 17456373
When you attempt to log in to the Oracle Virtual Compute Appliance Dashboard with incorrect user name or password, the Login screen does not display any error messages. The Login screen simply reloads.
Workaround: When the Login screen reloads, log in to the Oracle Virtual Compute Appliance Dashboard using a valid user name and password.
Error messages are displayed correctly when the user name or password field is left blank.
Bug 17535669
The Oracle Virtual Compute Appliance Dashboard contains an Update tab, which allows you to keep track of software component versions, and download and apply updates. When you click the Activate button to start the update process, the Dashboard does not confirm the start, report progress, or inform you that the update has completed. Click the Activate button only once.
In addition, the Dashboard neither allows you to verify whether the update has succeeded or failed, nor does it report the update status of each management node separately.
Workaround: Use the command
line tool ovca-updater to update the
software stack of your Oracle Virtual Compute Appliance. For details, see
Oracle Virtual Compute Appliance X3-2 Software Update. For step-by-step
instructions, see
Update. You can use
SSH to log into each management node and check
/etc/ovca-info
for log entries indicating
restarted services and new software revisions.
Bug 17476010, 17475976 and 17475845
Oracle Virtual Compute Appliance offers built-in backup functionality based on a cron job. The Dashboard user interface currently does not allow the user to modify the backup settings.
For more information about backing up the data on your Oracle Virtual Compute Appliance and recovering after a component failure, user error or full system failure, refer to the Oracle technical white paper entitled Oracle Virtual Compute Appliance Backup and Recovery Guide.
Bug 17347317
In the Network View tab of
the Oracle Virtual Compute Appliance Dashboard, clicking an I/O module port
makes a network selection dialog box appear. The only
available option, "Public", is already selected, but clicking
OK in the dialog box may result in a Java
ClassCastException
. The exception has no
adverse effects.
Workaround: If the Java
ClassCastException
message appears, click
OK to close the dialog box. You can continue working in the
Oracle Virtual Compute Appliance Dashboard.
Bug 17449881
If during provisioning a compute node becomes stuck in an intermittent state or goes into error status, the solution is to reprovision the compute node. The Hardware View tab of the Oracle Virtual Compute Appliance Dashboard has a Reprovision button specifically for this purpose. However, this functionality may become unavailable depending on the provisioning stage that failed. If the Reprovision button does not work, the compute node has likely become stuck after joining the Oracle VM server pool.
Workaround: Remove the failing compute node from the Oracle VM configuration first. Then use the Reprovision button to restart the provisioning process for the compute node in question. In some cases it may be necessary to manually power-on the compute node. For detailed instructions, refer to A Compute Node Fails to Complete Provisioning in the Oracle Virtual Compute Appliance X3-2 Administrator's Guide.
Bug 17430135, 17192103 and 17389234
When a virtual machine is started, it may be assigned to a compute node that has not yet completed provisioning, or is stuck in an initialization state. This is possible because Oracle VM considers every server that joins the server pool as a candidate to host virtual machines. If a compute node fails after joining the server pool, Oracle VM is unaware of the failure. This is considered normal behavior and is not harmful to the physical or virtual environment.
Workaround: If the issue is not resolved automatically by Oracle VM and the virtual machine will not start, you can log into Oracle VM Manager and move or migrate the virtual machine to a correctly operating compute node. For more information, refer to Creating and Managing Virtual Machines in the Oracle Virtual Compute Appliance X3-2 Administrator's Guide.
Bug 17415171
In Release 1.0.1, the default configuration does not allow connectivity to additional storage resources in the data center network. Compute nodes are connected to the data center subnet to enable public connectivity for the virtual machines they host, but the compute nodes' physical network interfaces have no IP address in that subnet. Consequently, SAN or file server discovery will fail.
Bug 17508885