Versions Compared

Old Version 1

changes.mady.by.user Ribbon Communications

Saved on

compared with

New Version Current

changes.mady.by.user Ribbon Communications

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Add_workflow_for_techpubs
AUTH1UserResourceIdentifier{userKey=8a00a0c85fd202bb0160132c449a0026, userName='null'}
JIRAIDAUTHSBX-75414
REV5UserResourceIdentifier{userKey=8a00a02355cd1c2f0155cd26cb8305e9, userName='null'}
REV6UserResourceIdentifier{userKey=8a00a02355cd1c2f0155cd26cb8305e9, userName='null'}
REV3UserResourceIdentifier{userKey=8a00a02355cd1c2f0155cd26cdcd0ab1, userName='null'}
REV1UserResourceIdentifier{userKey=8a00a0c85f4199b1015f7e6edda9000a, userName='null'}



Info
titleNote

Due to a current issue with RHEL 7.5, the following procedure must be run once on any compute hosts where SWe instances which require multi-queue virtio interfaces will be deployed. These steps enable such instances to spawn. The procedure confirms that the failure to spawn is due to the underlying RHEL 7.5 issue and then provides steps to work around this issue.

  1. Spawn an SBC SWe instance which requires multi-queue virtio interface support. The instance will fail to come up.
  2. Log into the compute host as the root user.
  3. Change to the directory: /var/log/audit
  4. Open the audit.log file and confirm that the following denial is reported by SELinux:
    avc:  denied  { attach_queue }
  5. Use the following commands to update the local policy of SELINUX to allow spawning of instances with multi-queue enabled:
    audit2allow -a -M attach_queue
    semodule -i attach_queue.pp
  6. Retry spawning a multi-queue virtio interface instance. The instance should now come up.

After you have prepared your OpenStack environment (refer to Pre-Instantiation Requirements of OpenStack) and developed a Heat template for your SBC SWe deployment (refer to Developing a Heat Template), you can use standard OpenStack methods to instantiate an SBC SWe instance. You can use OpenStack Heat commands or you can use the OpenStack Horizon dashboard to create the SBC instance. Refer to OpenStack documentation or documentation from your OpenStack provider for information on deployment using Heat.

Regardless of method, during orchestration you must specify the name of the template file you want to use to create your instance. If the template file does not provide an acceptable default value for any of the parameters specified within the template, then you must provide those values when you instantiate. You can provide these values in an environment file that you identify along with the template file when you instantiate. Otherwise, the values can be provided on the command line when you create the instance or entered in the GUI screen presented when you use the Horizon UI to launch an instance. The exact parameters you are required to provide or the fields that appear on a GUI screen depend on the parameters defined in your template. 

Info
titleNote

Make sure all your NICs are physically plugged in (link light on) before spawning VM instances. Otherwise, an incorrect port mapping may occur (logical to physical), and your SBC may not function properly.

 If you are instantiating an SBC cluster, you can view the status of the nodes in the EMS GUI

Spacevars
0model3
UI after they register with the EMS
Spacevars
0model3
:

  1. Log on to EMSonto
    Spacevars
    0model3
    .
  2. Click Network > Cluster Management > View Node Status. The Cluster Management / View Node Status window displays. 


Caption
0Figure
1EMS - View Node Status Window

Image Modified


Warning
titleWarning

Once an N:1 Redundancy Group (RG) is created, you must not delete any instances from the RG using the OpenStack dashboard GUI. In this case, you must remove the RG and create a new one.

 


Include Page
SBXDOC120:_media_outage_SweSBXDOC120:
_media_outage_Swe

 

pagebreak