.. _create_a_new_VM_using_the_platform-install_OVA: Create a New VM Using the Platform-Install OVA ---------------------------------------------- .. index:: web;web service .. index:: security;security update .. index:: voss;voss cleardown .. index:: voss;voss upgrade_db .. index:: log;log follow .. _12.5(1)|VOSSUC-19270: .. _19.1|VOSSUC-19270: .. _21.1|VOSS-837: .. note:: If an OVA file is not available for your current release, you need to obtain the most recent release OVA for which there is an upgrade path to your release. The steps below show the common setup of a *single node* from the OVA file - either for the purposes of: * a standalone installation If an OVA file is not available for your current release: 1. Obtain and install the most recent release OVA for which there is an upgrade path to your release. 2. Apply the Delta Bundle Upgrade steps for the current release to the OVA to upgrade it. * a node installation during multinode installation - see :ref:`notes-on-multinode-installation` If an OVA file is not available for your current release: 1. Obtain and install the most recent release OVA for which there is an upgrade path to your release. 2. Apply the Delta Bundle Upgrade steps for the current release *to the cluster* to upgrade it. Refer to the *Upgrade Guide with Delta Bundle*. * or during a failover recovery If an OVA file is not available for your current release: 1. Obtain and install the most recent release OVA for which there is an upgrade path to your release. 2. Add it to your cluster. Use the same configure options in the table below as were applied to the lost node. Note that the node version mismatch in the cluster can be ignored, since the next upgrade step aligns the versions. 3. Apply the Delta Bundle Upgrade steps for the current release *to the cluster* to upgrade it. For details, refer to the *Upgrade Guide with Delta Bundle* and to the specific scenario Disaster Recovery steps in the *Platform Guide*. The steps will therefore be followed either once or multiple times during installation - in accordance with the required topology. The downloaded OVA file is imported into VMware vCenter Server. Only one OVA file is used to deploy all the functional roles. You choose the specific node ``role`` when the installation wizard is run. 1. Log in to vSphere to access the ESXi Host. #. Choose **File > Deploy OVF Template**. #. Choose Source, browse to the location of the .ova file, and click **Next**. #. On the Name and Location page, enter a Name for this server. #. On the Deployment Configuration page, select the appropriate node type. (Refer to the list at the ``role`` option below.) #. Choose the resource pool in which to locate the VM. #. Choose the data store you want to use to deploy the new VM. #. Choose the disk format to use when deploying the new VM. * For non-SSD-based drives in production environments, "thick provisioning" is mandatory. Thick Provision Eager Zeroed is recommended. * For SSD-based drives, "thin provisioning" is supported. #. On the Network Mapping, choose your network on which this VM will reside. #. Do not select Power on after deployment. #. On the Ready to Complete page, click **Finish** to start the deployment. #. After the VM is created, select the CD ROM configuration and verify the **Connect at Power On** check box is enabled. Also, verify the memory, CPU, and disk settings against the requirements shown in either the Standalone System Hardware Specification or Multinode Cluster Hardware Specification section in the Install Guide. #. Power on the VM. #. Configure the options in the installation wizard: .. tabularcolumns:: |p{2cm}|p{2cm}|p{9cm}| +--------+---------------+--------------------------------------------+ | Option | Option name | Description | +========+===============+============================================+ | 1 | IP | The IP address of the server. | +--------+---------------+--------------------------------------------+ | 2 | netmask | The network mask for the server. | +--------+---------------+--------------------------------------------+ | 3 | gateway | The IP address of the network gateway. | +--------+---------------+--------------------------------------------+ | | | The DNS server is optional. Ensure that | | 4 | DNS | the DNS server is capable of looking up | | | | all hostnames referred to, including NTP | | | | server and remote backup locations. | +--------+---------------+--------------------------------------------+ | | | The NTP server is mandatory to ensure | | 5 | NTP | that time keeping is accurate and | | | | synchronized among nodes in the same | | | | cluster. | +--------+---------------+--------------------------------------------+ | 6 | boot password | Enable boot loader configuration password. | | | | See the example below. | +--------+---------------+--------------------------------------------+ | 7 | hostname | The hostname, not the fully qualified | | | | domain name (FQDN). | +--------+---------------+--------------------------------------------+ | | | Note: only WebProxy, Application and | | | | Database nodes are used for a modular | | | | architecture installation. | | | | | | | | | | | | * A WebProxy role installs only the | | | | front-end web server together with | | | | ability to distribute load among | | | | multiple middleware nodes. | | | | * An Application node is the main | | | | transaction processing engine and | | | | includes a web server which can | | | | operate by itself, or route | | | | transactions from a web node. | | 8 | role | * A Database node provides persistent | | | | storage of data. | | | | * A Standalone node consists of the | | | | Web, Application, and Database roles | | | | on one node. | | | | * A Unified node consists of the Web, | | | | Application, and Database roles on | | | | one node. On installation, the system | | | | needs to be clustered with other | | | | nodes and the cluster provisioned. | | | | * A General node used for M2UC, NBI. | +--------+---------------+--------------------------------------------+ | | | The system's geographic location (data | | | | center name, city, country that a | | 9 | data center | customer can use to identify the system | | | | location). You cannot change this setting | | | | once set. | +--------+---------------+--------------------------------------------+ | | | Platform password must be at least eight | | 10 | platform | characters long and must contain both | | | password | uppercase and lowercase letters and at | | | | least one numeric or special character. | +--------+---------------+--------------------------------------------+ .. note:: On a fresh installation, if you run the install on a network with a DHCP server and encounter an error: "Error: DNS server is either invalid or cannot be reached on the network" you can enter a valid DNS server address to continue the installation. Once all details are entered, installation will commence. When installation is complete, the system will reboot. Since all services will be stopped, this takes some time. Notes on Passwords and Security ............................... The default security protocol for the web server is TLSv1.2. Password protection can be enabled on the VOSS Automate boot loader configuration from the install wizard upon first install and also from the CLI - see the topic on System Boot Passwords in the Platform Guide for commands to enable, disable or reset the boot password. .. important:: The boot password is non-recoverable. The console example below shows the ``boot password`` configuration output: :: (1) ip (199.29.21.89) (2) netmask (255.255.255.0) (3) gateway (199.29.21.1) (4) dns (199.29.88.56) (5) ntp (199.29.88.56) (6) boot password (disabled) (7) hostname (atlantic) (8) role (UNDEFINED) (9) data centre (earth) (10) platform password (UNDEFINED) Select option ? 6 Valid passwords must contain: at least one lower- and one upper-case letter, at least one numeric digit and a special character eg. !#@$%&^* Password: Please enter platform user password: Please re-enter password Password: NOTE: The system boot password is now set for user platform. When the boot password is set, the wizard will show: :: (6) boot password (*****) .. _notes-on-multinode-installation: Notes on Multi-Node Installation ................................ According to the multi-node deployment topology and specification, the `role` of each VM installation is as indicated below. * For each WebProxy instance, create a new VM using the platform-install OVA. For `role`, select **(3) WebProxy**. Specify the appropriate data center (Primary/DR site) for each WebProxy instance. * *Standard Topology only*: For each Unified instance, create a new VM using the platform-install OVA. For `role`, select **(2) Unified**. Specify the appropriate data center (Primary/DR Site) for each Unified instance. The following Unified nodes are required in the cluster: * One Unified node as the Primary node at the Primary site * One Unified node as the Secondary node at the Primary site * Two Unified nodes as the Secondary nodes at the Disaster Recovery (DR) site Note: * For a six Node Multi Cluster deployment there are; two Unified nodes (one Primary and one Secondary) and one WebProxy node at the Primary site, and two Unified nodes (both Secondary) and one WebProxy node at the DR site. * For an eight Node Multi Cluster deployment, there are four Unified nodes (one Primary and three Secondary) and one WebProxy node at the Primary site. Two Unified nodes (both Secondary) and one WebProxy node are at the DR site. * *Modular Architecture Topology* The following nodes are required in a typical Modular Architecture cluster: * One Application node as the Primary node at the Primary site * One additional Application node at the Primary site * One Database node as the Primary Database node at the Primary site * One additional Database node at the Primary site * One Application node at the Disaster Recovery (DR) site * One Database node at the Disaster Recovery (DR) site .. note:: For a typical Modular Architecture cluster there is one WebProxy node at the Primary site and one WebProxy node at the DR site. For each *Database* instance, create a new VM using the platform-install OVA. For `role`, select **(2) Database**. Specify the appropriate data center (Primary/DR Site) for each Database instance. For each *Application* instance, create a new VM using the platform-install OVA. For `role`, select **(2) Application**. Specify the appropriate data center (Primary/DR Site) for each Application instance. Also refer to Multinode Installation section in the Install Guide. Detailed configuration can be applied from the Command Line Interface (CLI). Use **network help** or **network** for details. For example, domain can be configured using **network domain add **. For a geo-redundant deployment, the ``data center`` information entered in the wizard is equivalent to the location information. Finalize the Installation ......................... When the installation of the OVA is complete, a sign-in prompt for the platform user is displayed. The system is ready for use. Connect to newly deployed server CLI as the platform user. The login message would for example looks the same as below: :: Last login: Wed Nov 2 11:12:45 UTC 2016 from thwh on pts/6 Last failed login: Wed Nov 2 11:19:53 UTC 2016 from iza on ssh:notty There were 2 failed login attempts since the last successful login. host: dev-test, role: webproxy,application,database, load: 0.21, USERS: 3 date: 2016-11-02 11:19:57 +00:00, up: 14:19 network: 172.29.253.14, ntp: 172.29.1.15 HEALTH: NOT MONITORED database: 31Gb Failed logins: 2 since Wed Nov 02 11:19:53 2016 from iza mail - local mail management keys - ssh/sftp credentials network - network management backup - manage backups voss - voss management tools log - manage system logs database - database management notify - notifications control schedule - scheduling commands selfservice - selfservice management diag - system diagnostic tools system - system administration snmp - snmp configuration user - manage users cluster - cluster management drives - manage disk drives web - web server management app - manage applications security - security update tools If the user failed to log in prior to a successful login, the count, date and origin of the attempts are shown as ``Failed logins``. A successful login resets this login count. Run **app status** and ensure the services are all running and reporting the correct version before continuing. .. note:: Return to Multinode Installation, Standalone Installation or Failover step to complete the overall installation or failover recovery procedure.