It seems that few people have needed to reinstall the host virtual adapters (or at least if they did, they just resorted to reinstalling VMWare instead of just the adapters), so it’s no surprise that there are very few references to fixing it. Fortunately, it has come up and a solution does exist.
What you need to do is to use the vnetlib utility (it should be in the VMWare installation directory).
Someone on the VMWare forums has attempted to document the vnetlib command and another tried to use it to add the host virtual adapters.
Ulli Hankeln has done an even more through job of documenting vnetlib at his Sanbarrow site (which basically, is the online VMWare bible). He also lists a few other ways to manage the network settings.
Anyway, what you can do is to manually reinstall the adapters by using the add adapter argument to vmnetlib, and then managing all the settings, but it’s much easier to just reinstall the VMWare network services:
> vnetlib.exe -- install devices
Information about a host can leak to a guest in a number of different ways. VMware (and virtualization products in general) provide protection against many things. While it is unlikely to be able to provide a complete isolation environment, it probably does a pretty good job. For example, some virus researchers use VMware to provide a safe environment to study the behavior of malware.
Host information can leak to the guest:
- if the guest directly executes instructions that the virtualization layer does not intercept.
- if the guest can observe network traffic directly on the same network segment as the host.
- if the guest can communicate to the outside world and probe back to the host.
Your primary concern appears to be about the first method of leakage, though you should be sure to protect against the other mechanisms as well.
VMware (and other hypervisors) provide virtualization by intercepting what are considered to be sensitive instructions. Sensitive instructions would either reveal to the guest information about the host, or allow the guest to escape the containment of the virtualization layer. For example, the instruction that modifies the page table base (which controls memory access) must be detected by the virtualization layer, intercepted, and replaced with a "safe" version of that instruction that preserves the illusion of virtualization.
To provide the illusion of a separate machine from the host, instructions that reveal identifying information about the host (such as serial numbers, MAC addresses etc) are also virtualized. In VMware, these things can be set in the vmx file. This stuff is well understood and presumably safe.
Sometimes, there are trade-offs about what is exposed, such as the CPUID instruction, which recent versions of VMware provide some "protection" against. (See VMotion and CPU compatibility for many details about CPUID virtualization.) When executed as a privileged instruction, this can be trapped and emulated, but it can also be executed as a native instruction which may expose some (presumably uninteresting) information to the guest.
However, the guest can also passively learn other information about the host. For example, by probing memory timings, the guest can get information the size of various caches. The ability to learn about other guests (or the host) via timing and other vectors ("side channels") is an area of active research. In October 2012, researchers discovered that it is in fact possible to extract cryptographic keys from other VMs. This may be quite scary and the limits of what can be discovered and how to protect against this are not yet fully clear.
The best way to be fully secure is to isolate your machine via air gap from the rest of the world. Then it does not matter what the malicious software learns because it can not communicate that information to anyone. When you are done, wipe the machine. Using a tool like VMware makes this wiping and state recovery easier because the machine state is encapsulated in a set of files.
Best Answer
Disabling the vmware service will stop it, because you are disabling the communication between the guest and the host. The sleep signal sent from the OS (which is where it originates) is translated through vmware tools, to a pause command. Stopping the service will also compromise all the features of vmware tools like freeing up the memory and other important aspects of running the vm in vmware and performance of the host will suffer.
To solve your problem, go to power settings in windows (right click desktop > personalise > screen saver > power management) and change when your computer goes to sleep. that is all is happening, the default settings for windows 7 is to sleep after 30 mins. This is being sent to the host via vmware tools, which is why disabling the service worked. but that is a real bodge, just change it to 'never' sleep/always on.