I am going to post some past discussions on VirtualBox related issues, in case they have any bearing on the situation. Also, it would be helpful to know what Sysprep switch settings you are using. When deployed, does the image still contain the driver library folder?
VirtualBox, like VMWare and Virtual PC, emulates the SMBIOS specification. One of the things the SMBIOS specification includes is a way of determining for a machine a unique identifier - and this identifier is defined, and required to be, *genuinely* unique.
Because for physical machines this is the best - and in fact, just about only - way to reliably determine machine identity, this is naturally the primary identifier used. Therefore, whether for a physical machine (where Dell often to get this wrong and manufacture machines which don't comply with the specifications) or a virtual machine, the uniqueness of this identifier matters.
All the virtualization systems generates UUIDs for VMs automatically; VMWare is particularly clever in that it also generates an ID based on the pathname at which a VM resides, so that when a machine is moved or copied it will detect this when the VM is opened and if you say the VM is copied it will generate a fresh UUID for the contained system to distinguish it from the original.
For VirtualBox, not just VMs but disks have UUIDs attached as well (and those UUIDs are registered at machine scope in the VirtualBox media manager) and so anyone familiar with VirtualBox will inevitably become au fait with the need to refresh/update them as well - unlike VMware none of the UUID-related processes are automatic but need to be scripted.
All this is covered in the VirtualBox manual; since the management system trusts that if an SMBIOS UUID exists that it is unique (unless proven otherwise, for the benefit of Dell systems, where MAC addresses are used as a secondary key to prove that the UUIDs are untrustworthy) and since the MAC addresses are also identical, there is NO WAY for the management systems to know which machine is what unless you ensure that the virtual machines can be reliably given some form of unique identifier.
As per the thread EdT linked, the primary identifier for machines is the SMBIOS UUID. There are still a tiny number of machines (mainly Dells) out there in the marketplace that have been incorrectly manufactured with duplicate UUIDs, but I have not seen any machine at all manufactured in the last 5 years that siomply doesn't have one. So, a good starting point is to determine the SMBIOS configuration of your machines.
[ From memory, I left in a command-line option in the ngctw32.exe option, -uuid or something like that, which printed out the UUID it retrieved; from Windows XP on up, this should be being retrieved via a kernel-level WMI interface or via a similar API introduced in Vista and up. ]
There is, internally to the management system code, a table used for known-bad manufacturers that do not play by the IEEE rules; the VirtualBox adapter definitely deserves to be there, See this; some random company's MAC OUI registration is used instead because basically they never bothered to follow the IEEE rules (or even better, use the specific "privately managed" part of the MAC address space).
While that table of exeptions it's small I did add things over time to it - however, that was done on an as-needed basis and because of the SMBIOS UUID the number of customers affected by this was zero until some time after Symantec had cancelled the GSS product and laid off the original development team.
So, while it's in principle easy to add to the blacklist, in practice you are far better off trying to determine whether your machines do in fact have SMBIOS support and whether their SMBIOS UUIDs are unique
Virtual Box is very messy with its networking components; Virtual Box creates a virtual nic in the host OS when it installs. You can actually see it if you go to Device Manager or run "ipconfig /all" in the command line. I've noticed it does like to go out and grab an IP address even when there's no vm running. The Ghost client is likely getting confused between the virtual nic and the actual nic.
If you really want to confuse the snot out of the console, try installing it on both on a host and a guest os.
I've actually never had reliable luck with msi installers. The console has a remote client install that works beautifully on domain machines, as well as a remote client uninstall. You could try the remote uninstall on the machines that you're having trouble with, to see if it clear your woes out.
Virtual Box only cause this problem with my I7 system, all other system doesn't have this problem; ghost console effectively recognize the NIC as virtual and doesn't use it, like it should
As explained above, this is because the primary key that the Ghost console uses is the SMBIOS unique machine id. As long as the host machine has a valid SMBIOS UUID present, then that will be used instead. As long as SMBIOS UUIDs are present and distinct, NIC MAC addresses are only used as a fallback.
VirtualBox guests mainly cause problems in this respect because VirtualBox's default is to preserve UUIDs of created machines, whereas VMWare quite sensibly watches our for when guest VMs are no longer running on the original system when the guest VM was created, and by default will create a new SMBIOS UUID for the guest (this is the primary function of the "have you copied or moved the virtual machine" prompt when starting a VM in VMWare).
[ Using VirtualBox, ensuring that guest UUIDs stay distinct in the presence of deployed images is awkward, unless you explicitly use the teleporting feature which ensures the -hardwareuuid setting doesn't need to be used or otherwise try and take care of UUID management yourself. ]