I can only imagine that that's because of networking. Both host and guest propably have the same mac address. So the Server confuses the two.
Unfortunately not, the virtual machine is generated a unique MAC address, and this has been tested in both Shared and Bridged mode. As I mentioned in the parent post, however, Parallels does pass the same Serial Number, which is likely the problem.
The same serial number of what? The OS or the LanRef Agent?
He probably means "computer serial number".
We haven't used Parallels in a while but I never had a problem with them using the same LANrev UUID as the host. Looking at some existing Parallels VMs, they appear to have a unique serial that contains "parallels" in the serial.
2 of 2 people found this helpful
Each time the LANrev server receives a heartbeat/inventory it uses 2 pieces of information to determine if it needs to create a new device entry or merge the info with an existing device entry. Note that the computer serial number is not used by LANrev in anyway to distinguish between different devices.
1. The 1st item is either the hardware unique device ID, which might be the "Hardware UUID" in system profiler. Older devices don't have this so the MAC address of fastest network adapter is used, which is usually the ethernet adapter.
2. The 2nd item is the agent serial number.
New agent serial number + new unique device ID/MAC address => new device entry added
New agent serial number + existing unique device ID/MAC address => data merged with existing device entry (agent probably reinstalled)
Existing agent serial number + new unique device ID/MAC => new device entry added (computer was probably reimaged with agent serial number intact, command sent to agent to generate a new agent serial)
Existing agent serial number + existing unique device ID/MAC => data merged with existing device entry
So your problem is either your VM shares either the unique device ID or MAC address with the physical host the VM is on. You've already stated the latter is not the case so it's probably the former. I attempted to take a look at this but only ended up more confused.
I've got 3 different Parallels VMs for 10.8, 10.9, and 10.10. All 3 of them have the LANrev agent installed and the VM host also has the agent installed. The 10.8, 10.10, and VM host keep playing musical chairs with the same computer entry. The 10.9 system for some reason has its own computer entry that is never shared with the other devices. Not sure what's different about it. All of them have different primary MAC addresses and different "Hardware UUID", which is the "Unique Computer ID" in LANrev. So by all accounts they should all show up as unique device entries since they all have different hardware IDs and MAC addresses. Frankly I'm a stumped at this point.
1 of 1 people found this helpful
Turns out the problem was due to the computer serial number as you've guessed. The protocol I described above has changed in LANrev to take into account the device serial number. This coupled with a change in Parallels to use the same device serial for VM as the host has led to the problem you're seeing. You would have to adjust the serial number for your VM to make it different for your physical host to resolve this issue.
Unfortunately, this appears to be the correct answer... however this is obviously not an ideal solution.
The problem is indeed that Parallels has begun using the Macintosh host computer serial numbers for the guest VMs, however, rolling out the boot flags to every single VM in the wild is absolutely not a workable solution.
We have a similar issue when we boot from a portable drive, in that the Agent ID on the portable hard drive is merged with the "proper" Agent ID on the internal drive, which prevents packages from being delivered until a full inventory has taken place.
It sounds to me that unless the fingerprinting is improved, the ultimate solution is to disable merging of computer records, and allow us to take care of the cleanup of stale records on our own.