vApp create operation failed on first start AND access is via MMG/NAT with a message indicating that the resource is not reachable.

• MMG is not permitting access to its management interface. Confirm that the Platform Manager server has access to management side of MMG. See caution box in NAT with MiCloud Management Gateway (MMG).

• The VLAN-ID is not a member of the MMG's Trunk Group.

Review MMG configuration and VLAN ID.

vApp create operation failed. After uploading the VMDK, you see the error: "Timeout waiting for start completion"

Platform Manager is unable to connect to the Virtual Machine (VM).

From the VMware vSphere console, login to the VM and confirm that it has IP addresses on all expected interfaces. If any IP addresses are missing, open the /var/log/messages folder, and search for the phrase “some other host already uses address”. This phrase indicates an address conflict. If no IP conflict is found, confirm that: 1) Platform Manager is in the same network as the VMThe resource blueprint defines the new machine’s Remote Networks property. 2) The MSL remote networks on the VM will allow the Platform Manager network to connect.

vApp create operation failed. When you look at the vSphere console for the new VM, you see a blue MSL screen with an interface error or the error message: "An error occurred during restore".

IP address conflict.

See the solution for the previous problem, above.

vApp create operation failed. You see the error message: “failed due to OAuth error”

IP address conflict.

Platform Manager was unable to connect to the VM. Confirm that it has started. Look at the VM console via VMware vSphere console. See IP address solutions above. Confirm that the server has properly started. Open /var/log/messages and work back from the bottom. Confirm that PostgreSQL (psql) started.

vApp create operation failed from blueprint that has an MSL golden database. You see an error message like: OAuth, unable to login to server at xx.xx.xx.xx. Confirm that MSL password is correct.

OR

After uploading the VM image, start fails with a message like

VMware: Power on virtual machine failed VMware: Start failed, oria-mivbx-4464_mivbx87 not reachable @10.46.31.187

Incorrect MSL admin password in the blueprint.

OR

The MSL restore did not occur, either due to restore failure or AMC licensing failure. If there is an AMC licensing failure then the restore may not complete.

The MSL admin password that was entered in the resource blueprint is not the same as the MSL password that is in the golden database. After the restore, the MSL password will match the one in the restored db.

For a given blueprint, all platform instance creation attempts fail with a message like "Failed to start MiXML session. Login failed: MissRC-Failed-in-ICP".

When creating Resource Blueprints for MiVB type resources where you are supplying a golden database. In that golden database there is a system account that management software will use to log into the running MiVB instance. That account's user name and password need to be supplied in the resource blueprint. If these credentials are incorrect then login attempts will fail.

Make a new blueprint with correct credentials.

Error observed when deleting platform instances. "AmcException, AMC Access denied for server retirement/deletion" or "access denied for override".

Your AMC account needs to be a 'service provider' type. If it is not then you will experience failures when deleting ARID records and thus the platform instance delete will fail.

When you get a set of AMC API credentials you should verify them by creating and then deleting a platform instance.

Contact Mitel.

Platform instance create failures when creating instances in VMware with host-not-found failures that refer to a local fqdn VMware address. You may also see tomcat log messages like app-rm java.lang.IllegalAccessException: Class com.vmware.vim25.ws.XmlGen cannot access a member of class java.rmi.RemoteException with modifiers "private static final"

The server hosting Platform Manager must be able to resolve any FQDN names that may be emitted by VMware's vSphere server. For example
res-esx55-32.v.local-vcenter.com

To do this, you will need to configure corporate DNS settings on the MSL server that is hosting Platform manager.
Platform manager MSL server-manager>Configuration>Domains Coporate DNS settings.

Platform Instance creation of MiVB-X type systems fail at ESM validation stage.

On the MiVB-X, the MSL {host}/server-manager/Configuration/Networks page, the trusted networks need to include any management networks that require access to MiVoice Business System Admin Tool. Platform Manager connects to ESM so its IP (or network) must be listed in the networks table of the MiVB-X golden db. On MiVB-X, see MSL=>server_manager=>configuration=>networks.

Make a new golden db with updated networks configuration.

MiVB_MI tenant actions initiated via Platform Manager may fail with a message like "Failed to STOP resource on server dp100. There is a started background transaction (id=174106 verb=create created=2016-11-08 13:08:19) for this instance (id=62212 tenant20)"
where the start date of the transaction precedes the MiVB-MI server restart time.

If the MiVB-MI server reboots while doing a long running activity that was initiated via Platform Manager, then any future tenant actions initiated via Platform Manager may fail.

The workaround is to manually cancel the transaction over on the MiVB-MI server via its CLI command 'mcdshowtransactions'.

For example:

[root@da2 ~]# mcdshowtransactions -c 174106

Where 174106 is the transaction id displayed in the PM message.

Platform instance creation fails at cluster stage with a message like

CLUSTER PROGRESS 145757 > [sysIP=10.40.235.190]: SDS Sync has failed

The MiVoice Business instance does not have a Media Server connected.

Verify that a Media Server instance is connected to the MiVoice Business instance at the address listed as SYSIP.

vApp create operation failed on first start with a message similar to:

"VMware: Start failed, MslRest: OAuth error".

Incorrect date/time on Platform manager or on the target virtual machine. A difference of a few minutes could cause security negotiation failures.

If the time is incorrect on the target VM, check the time on the VMware host computer for that VM. Correct if necessary.