Just thouht I'd drop by and see if there was any answers to this. About a week and not a single thing. This type of response was why I swapped products. Unfortunately doesn't look like much has changed. Sad to see Fusion in such a decline. At least their are alternatives.
This is a user-to-user forum. While VMWare participates here, there's no guarantee of a response.
For what it's worth, I (and hundreds of my colleagues) run VM's off external SSD's all the time without issue. It's likely something unusual with your setup rather than a defect in Fusion.
well the only thing installed on the mac is mojave a nd fusion. I can run the VM not a problem but closing the VM fusion first stops responding and then ultimately takes the rest of the MAC down. This is with a samsub s5. I'll try a different drive but with regards to it being some thing else there is nothing else installed.
Oh and I uninstalled fusion 11, manually deleted all references to it in library etc and reinstalled it and it still does not shut run properly when running on extenral SSD. I've also tried the same with a different product and that works flawlessly.
Well i see 11.0.1 is out. prior to upgrading i tested a VM sitting on an external SSD and when closing fusion down resulted in a beach ball and needing to power down the machine.
Install 11.0.1 and fire up exactly the same vm on the same disk and when closing Fusion it no longer causes a beach ball.
Seems the update fixes this at least for myself as it seems others reported no such problem at all.
Spoke too soon. For some reason a day later the same old crash behaviour on shutting down a machine.
To revert to everyone else does not have a problem and noting when these same machines are local they work fine I figured its probably to do with the format/partiton of the drives. These are NTFS drives and I'm using tuxera. To prove the point I did a complete new installation of nothing but VMWare and tuxera. Sure enough the same issue occurs but with the fresh install I also get some additional error messages that tell me tuxera is not responding. Use a non-NTFS drive and everything is fine. I've lodged the issue with user. In case anyone is interested I tried 2016, 2017 and 2018 versions of Tuxera and they all have exactly the same issue on a 2017 MAC. If I try on a MAC Air it works fine. Guess the MAC hardware and Tuxera are not compatible. Will wait for my support response as Tuxera advertises that its compatible with VMWare. Except for VMWare their is no problem reading and writing to the drive that's NTFS. Just to prove the point I tried paragon and it worked fine on the same MAC.
Thanks for the insight and assistance.
Hm, what if the user suspends the VM and waits for it to finish before quitting Fusion?
NTFS drivers have a long and sordid history on MacOS. Data loss and corruption, performance issues, and frequent breakage with OS updates. Do you have a specific need to use NTFS? If it's just sharing with PC's, use exFAT instead (and just make sure you have good backups).
Yes Exfat works but reliability and corruptibility is an issue given that there is no journaling. I learnt the hard way with expat that its simply way too easy to break it without too much effort at all.
I'll give it a try after finishing work. Note that its not existing fusion that cause the beachball but shutting the VM Down. Fusion then waits for tuxera to return I guess, which it never does and fusion never shuts. I'll see what happens if the VM is suspended. It may work.
No disagreement on exFAT's dangers (hence my comment about backups), but NTFS on OSX isn't exactly safe either. Given the two, exFAT and backups are probably the less risky option. In any case, you've definitely narrowed down the cause.
Good to hear you nailed down the reason.
This one had me puzzled as having VMs on an external disk has been my default work environment for a few years, so I know that it used to be very reliable.
When I want to share VMs between Windows and Fusion nowadays I use FAT.
Yes I am aware of the 4GB max filesize limit, but my VMs are usually small enough for the disk slices to not go over the limit when using a split disk type of setup.
As long as your virtual disks are under 128GB and as long as you use the split disk configuration for those disks then that works fine with FAT.
For VMs with larger disks, or have a monolithic configuration I tend to use the network for that.
I understand that this might not be for everyone.
Wil| Author of Vimalin. The virtual machine Backup app for VMware Desktop Products
| Vimalin : Automated backups for VMware Fusion and VMware Workstation Professional
| More info at https://www.vimalin.com
| Twitter @wilva
| VMware Wiki at http://www.vi-toolkit.com
Just an update.
Tuxera have confirmed that their software causes a kernel lock when shutting down a VM. Simple answer becomes tuxera and Fusion are 100% incompatible on a 2017 MAC with Mojave or High Sierra. The web site details are obviously incorrect in this regard. No date for correction.
As a consequence I tried paragon NTFS as an option. However, this has a problem that after using the NTFS drivers that if you let the MAC goto sleep that when you wake up the MAC that the video is consequentially corrupted and that you need to power off the machine to get control back. Bug confirmed with paragon.
So, it seems the most popular and available NTFS drivers all have issues and no one can provide dates when they will function correctly.
So, ultimate answer i'm afraid is to go to a different format drive.
Seems like i'm testing software for companies. At least Tuexera has offered a refund. I aplaud them on that. Paragon was only trial so no issues.
Thanks for closing the loop. Not really unexpected given the long history of issues with NTFS drivers on OSX, but surprising that they didn't post the incompatibility on their web site.
If you can, use split VMDK files and go FAT32 - I've had pretty good luck with that over the years. If it's exFAT, either use WIla's backup program or carbon copy cloner to make regular backups....had the pain.
FWIW, I'd avoid APFS, particularly if you use time machine (or at least make sure you exclude the entire drive from it). Time machine now uses APFS snapshots for backups, which are triggered on the entire drive (ignores excluded folders). That means that VM's are snapshotted, which normally isn't an issue if the TM volume is connected as those are released as soon as the backup completes. However, if you're working remote from the TM volume, local snapshots continue to accrue and consume available disk space. I've run into situations where I can't copy large files to the internal drive without first purging the snapshots.