Avanti supports multiple instances running on a single host system, with one emulated Alpha per configuration file and one Avanti process per file. Files containing multiple Alpha systems are rejected. To migrate an old multi-system file, create a separate configuration for each Alpha, preserve its required session definitions, and check file paths and host port assignments for conflicts.

Version 5.1.0 no longer provides configurable internal Ethernet segments. If Alphas in an older multi-system configuration communicated through one, connect each virtual NIC to an appropriate common external Ethernet network after splitting the systems into separate configuration files. Check that every guest NIC has a unique MAC address on the resulting Ethernet network, including addresses assigned by DECnet, and that guest network addresses do not conflict. If the old network was isolated, use an appropriately isolated external network rather than unintentionally exposing it to the production LAN. Verify communication between all former peers before putting the split configurations into service; using the same host adapter is not by itself proof that the adapter, driver, and network pass traffic between them.

Each Avanti instance requires the following:

•One host CPU

•A unique configuration file

•Sufficient units remaining in the installed host-wide license pool

Running another Avanti instance on the same host carries no separate base license charge. Optional-feature units used by concurrently running instances are drawn cumulatively from the installed host-wide pool. Avanti requires that one host CPU be dedicated to the host O/S.  Thus, a 4-core system could conceivably support three instances of Avanti. Use of hyperthreading is not recommended, as it may introduce instability to the emulator.

Suspending or pausing an instance does not release its claimed units or dedicated cores. Normal shutdown returns those resources; if an instance exits without completing cleanup, Avanti reclaims its claim when a subsequent database check confirms that the owning Windows process has exited. A new startup performs this check before requesting resources. If Windows does not permit Avanti to establish whether an owner is still alive, the claim is retained to prevent double allocation; stop the affected instances, including service instances, before restarting them if resources remain unavailable.

Each new instance requiring units must fit within the currently installed valid key's capacity after subtracting every running instance's claim. Replacing a key does not add its capacity to that of the previous key. A lower-capacity replacement cannot interrupt running instances, but prevents new paid starts if their combined claims would exceed that lower capacity. A rejected start leaves the existing claims and capacity counters unchanged. Zero-unit starts neither require a key nor change the paid capacity.

The periodic heartbeat and process-cleanup checks use elapsed host uptime, independently of calendar-clock adjustments. After a long suspension or host sleep, a due check runs without replaying every missed interval. A live process retains its claim regardless of the time elapsed.

Running multiple virtual Alphas under Avanti requires robust host hardware.  Sufficient CPUs, additional memory, and a fast I/O bus will be required to achieve adequate performance.  The following table provides minimum host system configuration guidelines.