FusionAccess ITA Deployment: Archived Walkthrough and Release Checks

This translates a third-party FusionAccess deployment walkthrough, not a release-specific Huawei installation procedure. ITA means IT Adapter: Huawei’s architecture description says it provides administrator interfaces and interacts with HDC and the virtualization platform. The source’s broader “brain” description should not replace the individual component roles.

The source leaves its exact FusionAccess build and package names unspecified. Its EulerOS 2.3, generic install_fa script, fa-ita.service, PostgreSQL example, file paths and port 8088 were not verified as a single supported Huawei deployment. Preserve them as source examples below; obtain the exact product’s official installation guide and signed release packages before adapting the workflow. Huawei’s English installation course describes a version-specific automatic installation tool.

1. Plan and create the management VM

In FusionCompute, create the VM for the intended FusionAccess component role. The source selects EulerOS 2.3 64-bit, recommends thin allocation for a resource-limited test environment and mentions thick/lazy-zeroed allocation as an alternative. Verify the supported OS image, VM sizing, storage format and deployment topology for the actual release; these choices do not independently guarantee performance.

Map component IPs, VLANs, gateway and DNS before creating the VM. Attach its NIC to the planned reachable service/business network. If management and service planes are separate, use the release’s topology rather than inferring that one generic VLAN is always correct. Allocate the required static address and hostname, for example fa-ita-01, and confirm inter-component reachability.

1.1 Obtain and present the installation media

The source says four packages are needed but does not identify their exact filenames or checksums. Obtain the matching release set from Huawei support; do not substitute an unverified shared-drive bundle. It describes the FusionCompute VM Configuration → optical-drive workflow, using File or Shared Directory to present the media.

The source further describes selecting several files and having them packaged into an ISO. Confirm that the installed FusionCompute version supports the intended media workflow; do not assume arbitrary package files are automatically a bootable installer. Verify that the correct ISO is attached and keep Tools media distinct from component software media.

2. Install the supported OS and base network

The source opens a VNC console, boots its EulerOS installer and selects Install EulerOS. It describes a Chinese-language installer and automatic partitioning for /, /home and swap. Follow the release’s required partition sizes and supported layout; an unspecified automatic layout is not evidence of sufficient database/log capacity.

Set the planned static IP, subnet mask, gateway, DNS and hostname. Use the credentials issued or configured for the actual deployment and store them through the approved credential process. No sample or default password is reproduced here. The source estimates 10–15 minutes for OS installation; that duration is only anecdotal.

After reboot, inspect failed checks instead of ignoring them merely because a login prompt appears. Determine whether each failure blocks the release’s component installation or expected services.

2.1 Install the matching FusionCompute Driver Tools

The source selects Install Tools for the VM, attaches the tools media and mounts the identified optical device. Its examples, with the accidental trailing bash markers removed, are:

mkdir -p /mnt/cdrom
mount /dev/sr0 /mnt/cdrom
cd /mnt/cdrom

The source also mentions /dev/sr1. Identify which device actually contains the intended tools ISO; do not blindly switch devices on a mount error. It gives ./install or sh install.sh as possible script names. Use the package’s actual README and supported script/options rather than accepting all prompts without review.

Reboot if the validated tools procedure requires it, then detach its media through the appropriate Tools/optical-drive action. Verify the guest network with ip addr or the available legacy ifconfig tool and test the intended gateway/service destinations. A successful ping alone does not prove the application is installed.

3. Source component-installer workflow

The source mounts the component-media ISO separately:

mkdir -p /mnt/iso
# Replace the device with the verified component-media device
mount /dev/sr1 /mnt/iso
cd /mnt/iso
ls -l

It then names ./install_fa as an example installer and describes a graphical or text wizard. That filename is unverified; use the official release installer. The proposed wizard collects the local service IP, chooses New Installation or Expansion, checks OS resources/dependencies and configures the required component/database topology.

The original proposes globally stopping/disabling firewalld and setting SELINUX=disabled. Those commands are not presented here as installation prerequisites: apply the exact vendor-supported firewall/SELinux policy and required ports for the release. A generic walkthrough does not justify disabling the host’s controls.

The source suggests installing a local PostgreSQL database for small/test systems. Do not select an arbitrary database from that claim; FusionAccess component and database choices are release-specific. Supply the supported database endpoint and privately configured account through the validated installer. Keep the required credentials out of command examples and public documents.

Review the resulting configuration before starting installation. The source gives 20–30 minutes as an estimate, then follows the installer’s completion/reboot instructions. Neither elapsed time nor absence of many red log lines proves success; verify the documented result and inspect actual errors.

3.1 Verify the actual services and portal

The source checks systemctl status fa-ita.service and systemctl status postgresql.service if a local database is installed. Those names are illustrative and not confirmed for every FusionAccess release; find the actual supported service names and health checks.

It also illustrates https://<FA_ITA_ADDRESS>:8088. Use the portal protocol/port in the actual release guide. A reachable login page verifies only part of the service path. Authenticate with the deployment’s issued account, complete any mandatory first-login credential change and run the component-initialization wizard required by that version.

For the source’s 8088example, netstat -tlnp | grep 8088 or ss -tlnp | grep 8088 can illustrate checking a local listening socket. An absent listener is not fixed by merely opening a firewall. The source’s systemctl start fa-ita.service must likewise be adapted to the real service, if applicable.

4. Time, database, certificates and backup

Time: synchronize ITA, database, HDC, WI and related templates against the deployment’s approved time source. The source aims for under one minute of skew; use the release’s real tolerance. Its conditional chrony example edits /etc/chrony.conf, adds a server such as server <APPROVED_NTP_SERVER> iburst, restarts/enables chronyd and checks chronyc sources. Confirm the installed time service and verified synchronization state.

Database: when using a supported external/HA database, configure its endpoint and private credentials through the documented mechanism. The source guesses a path such as /opt/fa-ita/conf/db.properties; it is not established as the actual configuration file. Apply/restart only as instructed by the exact product guide.

TLS: verify the portal’s certificate and hostname. Replace certificates through the supported component procedure where required. The source’s .crt/.key and Tomcat server.xml references are generic examples; do not publish private-key material or treat bypassing an unknown certificate warning as deployment verification.

Backup: before configuring large desktop pools and policies, use the release’s supported configuration/database backup and tested recovery procedure. The source calls this a configuration snapshot/export and mentions System Maintenance or Backup/Restore menus. It is distinct from a hypervisor snapshot, whose consistency and support must be evaluated separately.

4.1 Troubleshooting areas retained from the source

Symptom	Source investigation, qualified for the actual release
Installer stops or reports an error	Inspect the actual installer logs. The source suggests /var/log/fa_install.log or /tmp, then searches for ERROR/Failed; these paths are unverified. Check disk capacity, package dependencies, connectivity and port conflicts.
Portal unavailable	Verify intended URL/port, listener, service state, routing and allowed firewall policy. The source suggests /opt/fa-ita/tomcat/logs/catalina.out, which is an unverified path, not a universal FusionAccess log location.
HDC or other component communication fails	Verify service IPs, names, ports, certificates and component registration. The source suggests a telnet port probe; use a supported connectivity test and do not transmit credentials through it.
Desktop/task operation fails	Review the actual task history, error code and component logs against the matching Huawei troubleshooting guide. A working portal alone does not validate end-to-end desktop delivery.
License/component prerequisites incomplete	Verify required license, WI/HDC and virtualization-platform initialization for the exact deployment. The source says licensing and later components can affect service use; it does not provide a complete validated installation package or component topology.

Translated and adapted from TechGuru’s source article under CC BY-SA 4.0. Release-dependent and unverified example names are identified above; credential literals and unsupported blanket advice were removed or qualified. This document does not claim that an installation has been performed.