T10:55:03.826-08:00| vmx| I125: Cannot open file "/Library/Preferences/VMware Fusion/vsphereFeatures/techPreview.cfg": No such file or directory. T10:55:03.826-08:00| vmx| I125: DictionaryLoad: Cannot open file "/Library/Preferences/VMware Fusion/vsphereFeatures/techPreview.cfg": No such file or directory. Yeah, understand that this is a VMWARE ISSUE NOT A MICROSOFT ISSUE!!! And what I mean by that is that there isn't anything wrong from the Windows end, but from the VMware end! VMware developers intentionally program this into all older versions of VMware in an attempt to force you to purchase another version of VMware!!! That kind of shady programming should be illegal! Fortunately, this can be bypassed using the Readiness Tool instructions in my previous post, but understand this will never be "patched" because the VMware developers intentionally put this into the code to begin with!!! So much for their "good" reputation, am I right?Ĭontents of ~/Documents/Virtual Machines.localized/loquat.vmwarevm/vmware.log Rather than doing this, VMware should release a patch to fix that.Īnd now for my rant. I am quiet sure that this can't actually be legal forcing (because if we don't upgrade our OS will have security wholes because we can not update our OS) users to pay for this upgrade. I bought my Licence for VMware Workstation 14 last year and I think that VMware shouldn't charge people for making their software compatible (to the exact User System) by buying the upgrade. I think it is ludicrous to force people to upgrade from 14 pro to 15 pro. Activated Storage I/O Control now and set policies for all VMs - let's see if it changes something moved VMs back and fort, and had no issuses - So i'm more and more thinking my issues are not directly network related, but related to the datastore. No Faillover (as it's only one physical nic).ĭid some general testing now, enabled vMotion, and stuff. Promiscious Mode, Forged Transmissions, Mac Changes - all disabled Settings (exactly the same across all layers/levels, hosts)
Portgroup 1 - VM (just a bunch of 'client' VMs) Portgroup 2 - VMKernel (just the the one VMKernel NicĭNS: local DNS servers (should not having an effect, as I'm adressing the problematic sservice explicitly via IP Portgroup 1 - VM (just the SQL server VM) between the hosts - it's just a networking cable between the nics of the hosts. Seems like my 'explanation' wasn't as clear as It seemed to meĭirectly connected: I mean, there is no switch/hub/etc.