I assumed it was something slightly different since in the case of physical machines, I've already explained the process in detail some 50 or 60 times here on the forums. The principles are of course exactly the same regardless of whether we're talking a virtual host or guest.
There is no Machine UUID involve
You need to establish that. Your *physical machines* should also have a unique SMBIOS machine UUID; these days, most manufacturers get this right but part of why I've had to repeatedly explain this so many times over the years is that a few do not. This was more common in years past but even today there is a small residual set of machines which do not have SMBIOS UUIDs.
If your physical machines do not have a unique SMBIOS UUID (either because it's absent or because they are manufactured incorrectly and not unique) then the only identifier available to Ghost is physical MAC addresses. In that case, if the list of physical MAC addresses inside the machines, then the Ghost server simply cannot be sure what the true identity of a machine is, and so the machines end up being overlapped.
Now, the Ghost client uses every programming technique available to distinguish between physical adapters and virtual ones, and as special code for for VMWare - since VMWare obey the IEEE specifications and have a unique MAC address OUI assignment registration, the virtual NICs running in the host are filtered.
However, some third-party software VPN adapters, some manufacturers of 3G nics, and VirtualBox do not correctly obey the MAC address assignment rules. The 3G NIC manufacturers tend to be the worst, because they have OUI assignments yet do not honour the specifications and manufacture devices which all have identical MAC addresses. VirtualBox and third-party software VPNs are more problematic because it's not clear whether they actually own they OUI assignment - according to the IEEE registry, they use an OUI assigned to "Cadmus Computer Systems" - and as such it's never been clear whether this should be added to the virtual-host MAC blacklist table inside GSS or not.
That said VirtualBox has rarely been a problem in hosts since the MAC address is generated at install time and exists in the registry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002bE10318} - in one of the subkeys under there will be a subentry for the virtual NICs with a "MAC" value containing the address the driver returns to the network stack on the host machine.
[ As another note, anyone who has used VMWare or VirtualBox extensively will be familiar with the subtle problems the host virtual adapters can cause at the IPv4 level. If you have two physical hosts with non-routed virtual NICs assigned to the same IPv4 subnet, the hosts advertise their host-only IPv4 address as part of their workgroup-level NetBIOS name registrations.
This means that the two machines will then often have no workgroup connectivity; an attempt to send from one to another will often try the private host-only IP address first and tries to contact the machine via that. Since that machine has the exact same IPv4 host-only network, it tries that and ends up failing to contact the machine. In order to resolve this, it's necessary to ensure that machines containing virtual hosts use distinct IP address ranges for their host-only virtual network adapters so that when selecting a common IP network to communicate on, the hosts always select a real network rather than one with no connectivity. ]
Now, it may be that in your case the hosts do actually have distinct SMBIOS UUID assignments, but you need to establish whether they do or not as the first step to diagnosing your problems.
For an unknown reason, the computer was there but the Ghost System Tray juste crash with error:
This error report in the event log doesn't contain any useful information; instead, all the GSS management components contain error-trap code which writes a full memory mini-dump along with a human-readable stack trace to the files NGERROR.DMP and NGERROR.TXT respectively before passing things along to the default Windows Error Reporting handler.
To determine the cause of a fault, it's necessary to supply the content of the .TXT file at least, which indicates where exactly in the program the fault occurred, which usually indicates what the underlying cause is (and in the rare cases where a fault is new, the .DMP file can be analysed inside Visual Studio to inspect the complete program state at the time it failed and from that divine the cause).