IlDavo's Posts

Supported host operating systems for Workstation Pro 16.x, 17.x and Workstation Player 16.x, 17.x (80807) (vmware.com) indicates that the first Workstation Pro release that officially supports (runs ... See more...
Supported host operating systems for Workstation Pro 16.x, 17.x and Workstation Player 16.x, 17.x (80807) (vmware.com) indicates that the first Workstation Pro release that officially supports (runs on) Windows 11 in version 16.2. Sad news for me, as I'm still on 15.7 and don't yet have company approval to purchase an upgrade... I am wondering if disabling Windows 11's "Memory integrity" feature will: a) Cause other problems with my use of Windows 11 b) Actually permit Workstation Pro 15.7 to run on Windows 11
UPDATE: WITHDRAWING REQUEST FOR GUIDANCE -- DISCOVERED THAT PHYSICAL SSD, ON WHICH I'M ATTEMPTING TO PERFORM DISK CLEANUP HAS VERY LITTLE AVAILABLE SPACE (D'ooh!) Related to old thread: https://comm... See more...
UPDATE: WITHDRAWING REQUEST FOR GUIDANCE -- DISCOVERED THAT PHYSICAL SSD, ON WHICH I'M ATTEMPTING TO PERFORM DISK CLEANUP HAS VERY LITTLE AVAILABLE SPACE (D'ooh!) Related to old thread: https://communities.vmware.com/t5/VMware-Fusion-Discussions/How-long-does-it-take-to-Clean-Up-Virtual-Machine-and-Reclaim/m-p/2157429 Fusion 11.5.7 "Clean Up Virtual Machine" operation has been in a state of "Reclaiming disk space..." for 2 Days & Counting on my Mac Mini (Late 2012) running MacOS Catalina 10.15.7.  The disk on which the virtual machine bundle resides is an SSD.  Total bundle size on disk is approximately 94GB. This seems an unusually long time duration, so I no longer trust that Fusion is actually doing what it says it is doing.  Other threads indicate that "Cancel" will have little effect and will ultimately lead to my having to force close the operation.  Should I continue to exercise (extreme) patience, or should I Force Close the operation and deal with likely resulting virtual disk damage (restore from backup)? Thanks for any guidance.
@orthonin, you're a life-saver! I followed the exact same steps as you indicated, with two minor changes, to resolve Exception 0xc0000005 (access violation) in a Windows 10 VM guest running on... See more...
@orthonin, you're a life-saver! I followed the exact same steps as you indicated, with two minor changes, to resolve Exception 0xc0000005 (access violation) in a Windows 10 VM guest running on a VMware Fusion 11.5.1 host on a MacOS Catalina machine in January of 2020: I found no VMware services running in your step 2, as nothing from earlier VMware tools installations was running in my guest VM, so I replaced your step 2 with a reboot Again, as no VMware services were running in my guest VM, I was able to delete all files in step 4, so I did not need to repeat that step after a reboot Steps I followed: 1. uninstall vmware tools from control panel; 2. reboot 3. delete install directory, eg. c:\Program Files\Vmware; 4. open c:\windows\system32, delete all files of vmware, (every vm* that showed "VMware" as the publisher on mouse-over).  All file deletion attempts succeeded in my case, making your step #6 unnecessary for me. 5. reboot system; 6. copy all files from vmware tools' install cd to  c:\temp, click setup.exe(setup64 for x64) to install. 7. reboot. the problem has been solved. Upon final reboot, I found my friendly VM icon in the system tray and knew I'd overcome the "access violation." Thank you so much, Milton, for taking the time to share what worked for you!  I'd spent hours across several days, chasing VMware.log files I couldn't find, running vm-support.vbs scripts that seemingly ran forever and never reported the directory where they dropped their output and trying to decipher tips in other threads that lead to blind alleys.
Thanks, CQuartetti​, So why do you suppose, in December of 2019, my VMware Workstation 14.1.8 system, running on an all-SSD platform (on which my VM's .vmdk's are also housed) prompts me with... See more...
Thanks, CQuartetti​, So why do you suppose, in December of 2019, my VMware Workstation 14.1.8 system, running on an all-SSD platform (on which my VM's .vmdk's are also housed) prompts me with the exact same "A fragmented virtual disk is affecting the virtual machine's performance.  Defragment the following virtual disk..."  instruction that I should use VMware's VM settings to defragment my vm's virtual disks? It's very hard to resist a clear advisory from your platform-of-choice (VMware) to perform maintenance that it claims will improve performance.
I believe I got past the "An operating system wasn't found" error that c6ten​ reported. Taking a clue from the article at: VMware Knowledge Base ... I inserted: bios.hddorder = "nvme0:0,scsi... See more...
I believe I got past the "An operating system wasn't found" error that c6ten​ reported. Taking a clue from the article at: VMware Knowledge Base ... I inserted: bios.hddorder = "nvme0:0,scsi0:0,ide0:0" ... into my .vmx.  This effectively instructed the VM's BIOS to attempt to book from NVME before SCSI, IDE, etc.  I can only assume that the "default" setting attempts to boot from SCSI (and others) and never attempts to use NVME. See also  https://www.besttechie.com/how-to-convert-vmware-fusion-virtual-sata-disk-to-virtual-nvme-disk/  for a simpler way to convert an existing disk from SATA or SCSI to NVME. I'm far from certain that I've covered all bases, but I hope this helps someone else get farther down the road.
Thanks for your comments re: Acronis, EdP​, Whereas I've experienced countless challenges, using Acronis, I am still using it as my primary, OS-agnostic and virtualization-agnostic archive uti... See more...
Thanks for your comments re: Acronis, EdP​, Whereas I've experienced countless challenges, using Acronis, I am still using it as my primary, OS-agnostic and virtualization-agnostic archive utility. You're correct that I could use any number of file-level backup utilities (including Windows' own) to archive individual files within the VM. Further wila​ notes that simply shutting down the vm and copying the VM's .vmdk files does accomplish a "perfect" copy of the VM's contents.  I would also consider examining wila​'s own vimalin utility (https://www.vimalin.com) as a file-level archive utility, were that my objective. For now, I really want to explore all avenues that might make my Acronis-within-VMware-guest-vm-archive-to-Host-Shared-Folder approach work. ...though I conceded that I've not yet found a path to do so.
HI, wila, You make a sound argument.  I do seek a "bare metal" archive of the contents of my VM.  I do, already, regularly shut down and archive copies of my VMware .vmdk files.  Acronis repre... See more...
HI, wila, You make a sound argument.  I do seek a "bare metal" archive of the contents of my VM.  I do, already, regularly shut down and archive copies of my VMware .vmdk files.  Acronis represents, for me, an extra measure of security, by allowing me to create a machine-agnostic "perfect copy" of the VM's contents that will not require a functioning VMware product or .vmdk virtual disk mounting utility for access (although it will, of course, require functional Acronis or .tib archive file mounting utilities). ...so I really do want to pursue finding a way for the Acronis service to write archives to the \\vmware-host\Share Folders\my-folder-name directory that I've instructed VMware Workstation to share with its guest. Subsequent research has led me to the conclusion that, whereas VMware Workstation offers the userid who's logged into the VM's operating system full read/write access to a shared folder on the host, it does not provide applications or services that are running under other user accounts (such as Acronis backup services) the same access.  Further, because -- per threads I've found on other forums -- VMware's "shared folders" capability is not based on network SMBs, it does not appear possible to grant an account other than the logged-in user access to a host shared folder that the logged-in user can "see." I'd love to be told that I'm wrong on this last point!
So it's been 2 years since ubunonymount attempted to solve the problem I still face, today (2019): Acronis True Image, running in a Windows 7 VMware Workstation virtual machine, will not accept ... See more...
So it's been 2 years since ubunonymount attempted to solve the problem I still face, today (2019): Acronis True Image, running in a Windows 7 VMware Workstation virtual machine, will not accept \\vmware-host\Shared Folders\TIBackupDestination as a "Back up to:" destination.  If I either attempt to browse to \\vmware-host\Shared Folders\ or explicitly enter the full UNC path to the target folder, an Acronis "Authentication Settings" dialog demands a user name and password for folder access. I've specified the userid and password that owns the folder on the VMware host, the userid and password under which the user account can read and write to it from within the VMware guest VM (same credentials, in my case).  I've even granted "Full Control" to "Everyone" on the directory in the host machine's OS. Mapping a network drive in the guest VM doesn't do any good (I've read in other posts that mapped drives aren't supported by other Acronis products, so I'll bet Acronis True Image doesn't support them, either). Creating a symbolic link in the guest VM to the UNC path -- a trick I learned from an Acronis forum post at [SOLVED] Accessing .TIB from vmware-host VM share folder | Acronis Forum -- (mklink /D C:\WriteBackupHere \\vmware-host\Shared Folders\TIBackupDestination) doesn't work (Acronis True Image doesn't even "see" the symbolic directory). I'm out of ammo. Anybody else have a solution?
As I've wasted over a week diagnosing this issue, both on my own and with assistance from VMware Tech Support, I thought I'd share my solution, in case others who use "Wireless Media Gateways" or... See more...
As I've wasted over a week diagnosing this issue, both on my own and with assistance from VMware Tech Support, I thought I'd share my solution, in case others who use "Wireless Media Gateways" or other multi-network-device networking infrastructure encounter similar problems: When I upgraded from VMware Fusion version 10 to 11, my Windows VM's suddenly lost network connectivity.  I'd always run the VM's in "Bridged" networking mode, so that I could access the VM's via their own, individual IP addresses.  As far as I knew, nothing on my Mac or network had changed, in any way, aside from the Fusion version upgrade.  As described, below, I later discovered that an unknown network configuration change had occurred.  I found many accounts in Internet forums, noting that certain previous VMware Fusion releases failed to pass DHCP-assigned addresses to Fusion VM's, and many more accounts advising users to check their router firmware for settings that might forbid associating multiple DHCP addresses with a single network card MAC address.  As it turns out, I was experiencing neither of these issues. The Mac on which I run VMware Fusion is directly-connected via Ethernet to a Media Gateway (Asus RT-AC66R in “Media Gateway” mode).  That gateway, in turn, connects wirelessly to my main router (an Asus RT-AC88U). For reasons I cannot fathom, my Asus RT-AC66R media gateway’s LAN IP address (the address by which the device would be accessed on its LAN side) changed from the value I’d originally assigned to it to a new IP address that was outside of my network’s addressing schemed (the new address was 192.168.x.x, whereas my network uses 10.10.x.x).  Devices connected to this media gateway would therefore be unable to directly address the media gateway.  This change must have occurred at approximately the same time as my Fusion upgrade -- again, I've no idea how or why. I would not expect a LAN IP address change of the media gateway, as described above, to matter to a connected device.  In fact the two physical PC’s and Mac that are connected to the media gateway via Ethernet continued to function, without issue, using IP addresses assigned by DHCP from the main Asus RT-AC88U router.  They were clearly not impacted by the media gateway’s LAN IP address change.  Nevertheless, the virtual machines that I was running on the Mac were definitely impacted.  Whereas they could connect to local network resources and to the Internet when set to use “NAT” networking, they refused to connect to anything when placed in “Bridged” mode. The fix: Re-booting my Asus RT-AC66R (in media gateway mode) caused the Asus RT-AC66R to re-acquire a proper IP address from the main Asus RT-AC88U router via DHCP that was within my LAN’s network addressing scheme.  When this happened, the Windows 10 virtual machines running on my Mac in “Bridged” networking mode quickly attained their own LAN addresses from the main Asus RT-AC88U router via DHCP and regained access to local network resources and to the Internet. I hope the above account saves somebody time that I needlessly spend pursuing numerous "ratholes."
I, too have used VMware Fusion for several years. I, too, have only just begun experiencing pop-ups in my MacOS host environment (macOS Sierra 10.12.5) coming from VMware Fusion (in my case: ver... See more...
I, too have used VMware Fusion for several years. I, too, have only just begun experiencing pop-ups in my MacOS host environment (macOS Sierra 10.12.5) coming from VMware Fusion (in my case: version 8.5.7) reporting that each of two MS Windows 10 Pro (version 1607 build 14393.1198) guest VM's "is attempting to monitor all network traffic, which requires administrator access." I'm not aware of having installed any software in either guest VM that is designed to sniff network traffic, and I'd really like to know what OS services or installed applications might be trying to place my virtual network adapter in "promiscuous mode." I really appreciate @wila 's background information and @Mikero 's diagnosis/research suggestions; however, I'd be truly grateful if anyone who has addressed this issue (@jbreitma and I can't be the only ones?) might share news of any Windows OS services or applications they found caused their Windows guest VM's to generate this VMware popup? Thank you!
Thanks very kindly for your reply, dlhotka! I'm not thrilled to hear that allocating VMware Fusion guests more than 2 CPU cores on a 4-physical-core i7 host Mac is inadvisable -- my Windows 10 g... See more...
Thanks very kindly for your reply, dlhotka! I'm not thrilled to hear that allocating VMware Fusion guests more than 2 CPU cores on a 4-physical-core i7 host Mac is inadvisable -- my Windows 10 guest VMs previously ran much faster and worked better with my process-intensive Adobe Photoshop (inside the VMs), but you would appear to know what you're talking about, as your guidance matches my current experience. Darned shame that the latest Sierra OS apparently contends, so extensively, for CPU resources that my Windows 10 Fusion guests no longer run as well as they used to.  I get the logic that indicates allocating 4 CPU's to guests on a 4 CPU host machine is unwise, but it used to work w/Fusion on previous MacOS releases. This does tempt me to experiment and find out if Parallels encounters the same limitations.
Running Fusion 8.5.3 (4696910) on MaOS Sierra 10.12.2 on Mac mini (Late 2012) with 2.6GHz i7 16GB RAM and all SSD drives. 2 Windows 10 Fusion guests ran just fine for a few months on previous Ma... See more...
Running Fusion 8.5.3 (4696910) on MaOS Sierra 10.12.2 on Mac mini (Late 2012) with 2.6GHz i7 16GB RAM and all SSD drives. 2 Windows 10 Fusion guests ran just fine for a few months on previous MacOS and Fusion releases on same hardware, then applied MacOS updates and Fusion updates at about the same time (I know, unwise...) and Windows 10 guests slowed to an unusable state. Blaming Windows 10, I sought fixes in Windows 10 communities (reducing and then ultimately eliminating Cortana functionality, reducing Windows 10 appearance features, etc.) that seemed to reduce the lag, but eventually, the Windows 10 guests again arrived at an unusable state. I found this thread on communities.vmware.com. I disabled "Accelerate 3D Graphics," turned off "Settings->Advanced->Troubleshooting," and enabled "Hard disk buffering."  No change. "Workaround" that Appears to have Positive Results: I then observed suggestions concerning CPU cores and RAM allocation and changed from: 4 processor cores (of the 8 "CPU core" threads that VMware Fusion "sees") and 8132MB RAM (of the 16384MB available) to 2 processor cores with 8132MB RAM, and the Windows 10 guest become usable! Further results from others who try to diagnose/fix appreciated -- I'm not giving up on VMware, as I rely on symbiosis with VMware Workstation that I run on PC hosts.
Thank you, RustysDad, for sharing what worked for you. I'm about to face the same task, as my VMware Fusion guest VM is stuck in "Suspending..." mode, and VMware Fusion Menu Bar options that wou... See more...
Thank you, RustysDad, for sharing what worked for you. I'm about to face the same task, as my VMware Fusion guest VM is stuck in "Suspending..." mode, and VMware Fusion Menu Bar options that would otherwise allow me to shut the machine down, or even force power off (by holding down the "Option" or "Alt" key) are all greyed out, thus providing no supported way to stop the guest VM. This is unfortunate, as I've a second guest VM, running under the same Fusion instance, that will almost certainly lose integrity when it, too, ceases to run as a result of my having to kill the vmware-vmx process.
Update: Disabled "Put hard disks to sleep when possible" in Apple->SystemPreferences->EnergySaver ("Computer sleep" was already "never" and "Display sleep" was already 45 minutes before Fusion is... See more...
Update: Disabled "Put hard disks to sleep when possible" in Apple->SystemPreferences->EnergySaver ("Computer sleep" was already "never" and "Display sleep" was already 45 minutes before Fusion issues arose -- I've not changed them).  Made no other changes. Both of the Windows 10 guest VM's I'd left running are unresponsive, again, on Fusion 8.5 GUI. Given that my Sierra Mac's sleep is already "never" and I've disabled "Put hard disks to sleep," I don't know of any other settings I can adjust to eliminate factors suspected to cause this error. Makes VMware Fusion entirely-unworkable, now.
I arrived here via Google search as VMware Fusion 8.5  running on MacOS Sierra 10.12 froze and no longer responded to any GUI interactions. Prior to discovering this, I'd been away from my Mac f... See more...
I arrived here via Google search as VMware Fusion 8.5  running on MacOS Sierra 10.12 froze and no longer responded to any GUI interactions. Prior to discovering this, I'd been away from my Mac for over 24 hours. Historically, these 2 Windows 10 guest VM's ran just fine under VMware Fusion on prior MacOS releases -- including VMware Fusion 8.5, to which I'd upgraded prior to upgrading MacOS to Sierra. 2 Windows 10 guest VM's that I'd left running could not be accessed via VMware Fusion 8.5 GUI. I was able to access the Windows 10 guest VM's via Microsoft RDP from a separate workstation, where I was then able to properly shut them down. When I did so, nothing changed on VMware Fusion 8.5 GUI screens that I still had open on my Mac. I then force quit VMware Fusion 8.5 and found that all other MacOS applications still functioned. I re-started my Mac, checked all affected disks with DiskWarrior, started up Fusion 8.5 and my 2 Windows 10 VM's, logged into those VM's and ran Windows checkdisk -- no Windows-reported errors. Left running VM's in identical state to above. 24 hours later, I found VMware Fusion 8.5 and my 2 guest VM's frozen and unresponsive as before. ChrisColotti(VMware): Thank you for your latest report, indicating that this problem is related to "sierra sleep protocol." Unfortunately, I can find no "post below" that you reference in order to read further.
VMware Workstation allows users to configure border colors for guest VM application windows appearing on the host desktop. Does VMware Fusion offer this configuration?  How does one find it?
Aha! Kudos to wila for advising that Mavericks (prior MacOS release) provided its own "maximize" button and  Kudos to dariusd for pointing out new Yosemite functionality (vs. prior MacOS releases... See more...
Aha! Kudos to wila for advising that Mavericks (prior MacOS release) provided its own "maximize" button and  Kudos to dariusd for pointing out new Yosemite functionality (vs. prior MacOS releases) that relocates the "maximize" window function to that of the third, green dot in the upper-left-hand-corner of the application window. As much as I might now appreciate the ability to add a "View Full Screen" button to the VMware Fusion 7.1.0 toolbar, I clearly no longer require it. Problem solved. Many thanks! -david-
VMware Fusion 7.1.0 View->Customize Toolbar allows one to add/remove "Enter Unity" button on Fusion toolbar. Why does it not also offer a "View Full Screen" button to the Fusion toolbar? I cou... See more...
VMware Fusion 7.1.0 View->Customize Toolbar allows one to add/remove "Enter Unity" button on Fusion toolbar. Why does it not also offer a "View Full Screen" button to the Fusion toolbar? I could swear previous Fusion versions provided such a button. Online help documentation speaks of a "Full Screen Button in the Fusion menu bar" in previous releases, but none exists on my Fusion 7.1.0 toolbar. This is quite a hassle, as I keep clicking on the one button that does exist in the traditional normal/maximize windows location (upper right corner), and that's the "Enter Unity" button -- and that's not what I want to see! Thanks, -david-
Immediately after upgrade from VMware Fusion 5.0 to 6.0, bootup of previously-fully-operational Windows XP SP3 guest (I did not "upgrade the virtual machine" to a new version) and subsequent VMwa... See more...
Immediately after upgrade from VMware Fusion 5.0 to 6.0, bootup of previously-fully-operational Windows XP SP3 guest (I did not "upgrade the virtual machine" to a new version) and subsequent VMware Tools auto re-install (I did not initiate the re-install, VMware did), I got the error, "VMware Tools Core Service has encountered an error and needs to close...". When I acknowledge this dialog, the VMware Tools tray icon that had previously appeared disappeared. I did a "repair" install of VMware Tools and rebooted the guest XP machine. Same error. Checking Services, I found the VMware Tools service was still running. I re-started it. Checking the Event Log, I found the following in the Application Log: Event Type: Error Event Source: VMware Tools Event Category: None Event ID: 1000 Date:  9/14/2013 Time:  6:54:04 PM User:  NT AUTHORITY\SYSTEM Computer: [removed] Description: [critical] [vmsvc:Glib-GObject] file ..\..\..\gobject\gsignal.c: line 3062: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed I re-started twice more as advised by ranjeets. VMware Tools service continues to run ("Started" in Services and executable's still running in Task Manager). New messages appeared in my Application Log after the two service re-starts: Restoring network configuration (event ID 258) Not restoring network configuration for adapter with MAC address xx:xx:xx:xx:xx:xx. The device ID for this adapter is unchanged. (event ID 270) Restored network configuration (event ID 271) Issue currently unresolved.
Bless, you, bgertzfield for providing instructions on how to find the "var" folder tree in Finder! I'm incredulous at the number of FAQ and community threads that leave out this vital informatio... See more...
Bless, you, bgertzfield for providing instructions on how to find the "var" folder tree in Finder! I'm incredulous at the number of FAQ and community threads that leave out this vital information!