Netxus SolutionsDocumentation

Hosting

Entry: /hosting. Hosting owns compute platforms, Hosts, clusters, pools, Service Environments, workloads and recorded placement. Start with the correct Group, CPU/memory capacity and responsible Team. You need the relevant management permission; optional Asset or other peer references require authorized, compatible owner records.

Register a platform and Host

  1. Open Infrastructure → Platforms and choose Register Platform. Record the platform's name, vendor and version.
  2. Open Hosts and choose Register Host. Select the platform, enter the Host name and optional management endpoint, and record CPU capacity and memory in MiB.
  3. Review the saved Host and its lifecycle. Use its Settings to apply a supported state change when appropriate.
  4. If you need clusters or pools, create them under Clusters & pools, add eligible Hosts and set the pool's CPU and memory limits.

Place or move a workload

  1. Open Workloads → Service environments and create the environment with its name, environment class and responsible Team.
  2. Open Workloads and choose Create Workload. Select its Service Environment and the intended eligible Host, cluster or pool, and enter vCPU, memory MiB and any applicable storage GiB.
  3. Review available headroom and submit. Verify the saved placement and capacity figures.
  4. To move an existing record, use its Settings → Move Workload, review the destination and current version, then verify the resulting placement.
  1. Use the permitted Host or Workload reference action to select an existing compatible Asset or other supported resource. Do not create a second identity for the same equipment merely to fill a selector.
  2. Review the authorized links in Related resources and capacity evidence in Capacity & reviews.
  3. Where inventory ping is configured, use the Host's Settings → Monitoring to choose Managed or Unmanaged and inspect its observation time separately from lifecycle.

Blockers and limits: insufficient capacity, incompatible platform/pool membership, retired subjects, stale versions or inaccessible references can prevent placement. The interface's selected state/retirement operations accept up to 100 records and execute individual commands with per-record outcomes; retry only failed items after review. A Hosting record change does not promise that a hypervisor deployed or migrated a real virtual machine. Workloads do not acquire an inferred physical location or ping address, and an old observation is not proof of current availability.

Sync Hosts and Workloads from a connector

  1. Ask the Protected Administrator to approve your vCenter host under Connector hosts.
  2. Open Sync connectors, configure the vCenter, AWS EC2 or Azure Compute connector and enter its secret in the write-only field. Use Test connection, which makes one read-only call and reports success or failure without revealing secrets (6 tests per minute per User per connector type).
  3. Run the sync. Connectors are read-only: they propose Host and Workload creations and updates matched by external ID, and items that disappear are flagged, never deleted.
  4. Review and accept proposals (up to 500 per command). Synced Workloads start unplaced; during acceptance you can place them on a Host, Cluster or Resource Pool, with the same capacity checks as Create Workload.

Limits: a run reads up to 5,000 items and produces up to 4,000 proposals. CPU and memory that a provider does not report show as Not reported, count as zero in capacity sums, and block placement in a Pool or Cluster until you enter them. An accepted CPU or memory change runs the normal capacity check, and a failing proposal stays pending with its reason.

Send feedback on this guide