2020.03.31 – Solved problem in VMware Fusion on Network Adapters

Posted on by

Important Photos are here: https://photos.app.goo.gl/APehWMwK8XH5zuSn6

Overview

I have a problem into VMware Fusion Network Adapter. I found the problem when trying to configure new installed ESX. All networks are blocked, stretch with white collor and I can not change the Network Adapter.

Note: I did not power-on any virtual machine to check if it isn’t active. Till now I focus as what I will write into this page.

Searching the Problem

Problem 1. It seems that the problem on network adapter is on all Virtual Machines. I have discovered on other ESXi installations, for example. The same problem!

Problem 2. Checking on VMware Fusion, out of Virtual Machines I have found the same problem.

Problem 3. This is not the based problem: Checking into Networking file using Terminal and the command sudo vim /Library/Preferences/VMware\ Fusion/networking

I have solved this problem but it not solved problems 1 and 2!

Solution 4 received on email:

I’m guessing it might be a limit on the number of custom vmnets you can create or an error in the config. Can you try emptying the config and see if it fixes the problem with the disabled UI? 

I have seeped only 10 needed networks and delete all other:

VERSION=1,0
 answer VNET_10_DISPLAY_NAME vSphere
 answer VNET_10_HOSTONLY_NETMASK 255.255.255.0
 answer VNET_10_HOSTONLY_SUBNET 10.1.1.0
 answer VNET_10_VIRTUAL_ADAPTER yes
 answer VNET_11_DHCP no
 answer VNET_11_DISPLAY_NAME WAN
 answer VNET_11_HOSTONLY_NETMASK 255.255.255.0
 answer VNET_11_HOSTONLY_SUBNET 198.18.11.0
 answer VNET_11_NAT yes
 answer VNET_11_NAT_PARAM_UDP_TIMEOUT 30
 answer VNET_11_VIRTUAL_ADAPTER yes
 answer VNET_12_DHCP no
 answer VNET_12_HOSTONLY_NETMASK 255.255.255.0
 answer VNET_12_HOSTONLY_SUBNET 198.18.12.0
 answer VNET_12_NAT no
 answer VNET_12_VIRTUAL_ADAPTER yes
 answer VNET_13_DHCP no
 answer VNET_13_HOSTONLY_NETMASK 255.255.255.0
 answer VNET_13_HOSTONLY_SUBNET 198.18.13.0
 answer VNET_13_NAT no
 answer VNET_13_VIRTUAL_ADAPTER yes
 answer VNET_14_DHCP no
 answer VNET_14_HOSTONLY_NETMASK 255.255.255.0
 answer VNET_14_HOSTONLY_SUBNET 198.18.14.0
 answer VNET_14_NAT no
 answer VNET_14_VIRTUAL_ADAPTER yes
 answer VNET_15_DHCP no
 answer VNET_15_HOSTONLY_NETMASK 255.255.255.0
 answer VNET_15_HOSTONLY_SUBNET 198.18.15.0
 answer VNET_15_NAT no
 answer VNET_15_VIRTUAL_ADAPTER yes
 answer VNET_16_DHCP no
 answer VNET_16_HOSTONLY_NETMASK 255.255.255.0
 answer VNET_16_HOSTONLY_SUBNET 198.18.16.0
 answer VNET_16_NAT no
 answer VNET_16_VIRTUAL_ADAPTER yes
 answer VNET_17_DHCP no
 answer VNET_17_HOSTONLY_NETMASK 255.255.255.0
 answer VNET_17_HOSTONLY_SUBNET 198.18.17.0
 answer VNET_17_NAT no
 answer VNET_17_VIRTUAL_ADAPTER yes
 answer VNET_18_DHCP no
 answer VNET_18_HOSTONLY_NETMASK 255.255.255.0
 answer VNET_18_HOSTONLY_SUBNET 198.18.18.0
 answer VNET_18_NAT no
 answer VNET_18_VIRTUAL_ADAPTER yes
 answer VNET_19_DHCP no
 answer VNET_19_HOSTONLY_NETMASK 255.255.255.0
 answer VNET_19_HOSTONLY_SUBNET 198.18.19.0
 answer VNET_19_NAT no
 answer VNET_19_VIRTUAL_ADAPTER yes
 answer VNET_1_DHCP yes
 answer VNET_1_DHCP_CFG_HASH 
 answer VNET_1_HOSTONLY_NETMASK 255.255.255.0
 answer VNET_1_HOSTONLY_SUBNET 192.168.185.0
 answer VNET_1_VIRTUAL_ADAPTER yes
 answer VNET_20_DHCP no
 answer VNET_20_HOSTONLY_NETMASK 255.255.255.0
 answer VNET_20_HOSTONLY_SUBNET 192.18.20.0
 answer VNET_20_NAT no
 answer VNET_20_VIRTUAL_ADAPTER yes
 answer VNET_21_DHCP no
 answer VNET_21_HOSTONLY_NETMASK 255.255.255.0
 answer VNET_21_HOSTONLY_SUBNET 192.18.21.O
 answer VNET_21_NAT no
 answer VNET_21_VIRTUAL_ADAPTER yes
 answer VNET_22_DHCP no
 answer VNET_22_HOSTONLY_NETMASK 255.255.255.0
 answer VNET_22_HOSTONLY_SUBNET 192.18.22.0
 answer VNET_22_NAT no
 answer VNET_22_VIRTUAL_ADAPTER yes
 answer VNET_23_DHCP no
 answer VNET_23_HOSTONLY_NETMASK 255.255.255.0
 answer VNET_23_HOSTONLY_SUBNET 192.18.23.0
 answer VNET_23_NAT no
 answer VNET_23_VIRTUAL_ADAPTER yes
 answer VNET_24_DHCP no
 answer VNET_24_HOSTONLY_NETMASK 255.255.255.0
 answer VNET_24_HOSTONLY_SUBNET 192.18.24.0
 answer VNET_24_NAT no
 answer VNET_24_VIRTUAL_ADAPTER yes
 answer VNET_2_DHCP no
 answer VNET_3_DHCP no
 answer VNET_3_VIRTUAL_ADAPTER no
 answer VNET_4_DHCP no
 answer VNET_4_VIRTUAL_ADAPTER no
 answer VNET_5_DHCP no
 answer VNET_5_VIRTUAL_ADAPTER no
 answer VNET_6_VIRTUAL_ADAPTER no
 answer VNET_8_DHCP yes
 answer VNET_8_DHCP_CFG_HASH 
 answer VNET_8_HOSTONLY_NETMASK 255.255.255.0
 answer VNET_8_HOSTONLY_SUBNET 192.168.197.0
 answer VNET_8_NAT yes

And it SOLVED THE PROBLEM!!!

Solution 3 for Problems 1 and 2: Searching for VMware Fusion networking solutions!

–> Solution 3. First Discovery.

I don’t find on internet any solution but my ideea is to reinstall directly VMware Fusion if not world then uninstall and install back Fusion.

–> Solution 3. Second Discovery.

It seems that few days ago I have updated the VMware Fusion to the las version. I have version 11.5.3 and the Release data of this version, VMware Fusion 11.5.3 (for Intel-based Macs), was on 2020-03-24. View days ago, 7 days ….

I do not find a solution for downgrade Fusion so I wait for VMware help or a new upgrade version!

Solution 2 for Problem 2: Open a case for helping me too VMware.

I have opened a case: VMware acknowledges your Support Request # 20113710503 

Solution 1 for Problem 3: From here: https://superuser.com/questions/218262/how-to-get-rid-of-the-warnings-when-opening-a-file-that-has-a-swp-file

This message is actually pretty important if you care about not losing text you’ve potentially not saved. It should not be considered annoying, and should not cause you to hastily delete the swap file or configure vim to run without it.

Any file you edit with vim will have a corresponding swap file while you edit, which vim uses to keep track of changes. When you quit editing a file, vim will automatically discard the corresponding swap file. Therefore, the existence of a swap file, and your attempt to write overtop the original file, should be cause for consideration and appropriate action.

The two scenarios presented in the message (E325: ATTENTION Found a swap file) are actually quite common: (1) either another vim program is editing the very same file you’re trying to edit (it could actually be another person – in which case it really wouldn’t make sense to just blindly delete the swap file – or it could be you in another terminal window or tab), or (2) a previous vim session crashed (most often this happens when you’re editing remotely, and the network session is severed – in which case the vim session was not exited normally, and the .swp file remains behind; another example of this second scenario is that you’ve accidentally closed the terminal window or tab that had an active or backgrounded vim session).

When I encounter this message I first think about whether I am editing this file in another terminal window or tab, as I normally operate with several terminal windows with several tabs each:

If I realize that I am editing in another place, and can return to it, I then press the q key to (Q)uit this additional session, and return to editing via the original vim session.

Sometimes if I am not entirely sure, I (Q)uit and then run jobs to verify whether I am running vim in the exact same terminal; if nothing comes up, I run ps -ef | grep vim  to check whether I am running vim elsewhere (i.e. in another terminal window or tab). The point is, I always try to resume editing via the original vim session.

If I am certain that I cannot return to the original editing session, and I am still presented with the following options, then I press r to (R)ecover.

Swap file ".notes.swp" already exists! [O]pen Read-Only, (E)dit anyway, (R)ecover, (Q)uit, (A)bort:

Pressing r, you will see a message like this:

Swap file ".notes.swp" already exists! 
"notes" 18L, 46C 
Using swap file ".notes.swp" 
Original file "/private/tmp/notes" 
Recovery completed. Buffer contents equals file contents. 
You may want to delete the .swp file now. 

Press ENTER or type command to continue

If, on the other hand, I am no longer faced with those options, because I am at the shell prompt, then I run vim with the -r option, as follows:

vim -r /Library/Preferences/VMware\ Fusion/networking

The resultant message will be similar:

Using swap file ".networking.swp"
 Original file "/Library/Preferences/VMware Fusion/networking"
 Recovery completed. You should check if everything is OK.
 (You might want to write out this file under another name
 and run diff with the original file to check for changes)
 You may want to delete the .swp file now.
 

 Press ENTER or type command to continue

Either way, press ENTER to continue, and you will see your file.

  • Note: If Vim has doubt about what it found, it will give an error message and insert lines with “???” in the text. If you see an error message while recovering, search in the file for “???” to see what is wrong. You may want to cut and paste to get the text you need.
    • The most common remark is “???LINES MISSING”. This means that Vim cannot read the text from the original file. This can happen if the system crashed and parts of the original file were not saved.
    • That said, I have never seen those ??? marks, so this must be a truly rare occurrence.

Next, save (i.e. write) the content to another file (usually I just append “2” to the end of the original file name):

:w networking2
  • Errors I have :
    • Using Command :w networking2 : “networking2″ E212: Can’t open file for writing
    • Using Command :w : E45: ‘readonly’ option is set (add ! to override)
    • Using Command :w! : “networking” E212: Can’t open file for writing
  • But I continue to some next …

OK: Next, force-quit this vim session:

:q!

NO: Next, compare the two files:

diff notes notes2

OK with using networking no networking2: If the diff returns nothing, that means there is no difference, and it is safe to remove both the swap file and the second file:

rm .networking.swp networking2 -> his model
rm .networking.swp networking  -> what I use
 rm .networking.swp networking
 override rw-r--r--  root/wheel for .networking.swp? Enter 
 override rw-r--r--  root/wheel for networking? Enter

OK: At this point, open the original file and proceed as if there had never been a problem:

vim networking

If the diff returns something, that means the original file (via the swap file) had changes that, thanks to the recover, have been saved to the second file.

NO: Since those changes are captured in the second file you are safe to delete the swap file and overwrite the original file with the second one:

rm .notes.swp
remove .notes.swp? y

mv notes2 notes
overwrite notes? (y/n [n]) y

OK: At this point, open the original file and proceed as if there had never been a problem:

vim networking

This seems like a lot of work, but once you get used to the workflow it takes like 20 seconds max.

This does not solved my problem!

I use restart MacBook Pro, I check and see the same problem into VMware Fusion and I use vim command where I open the file I see this and use i:

W10: Warning: Changing a readonly file

But I do not think I have a problem …. I go farther with searching on internet Solution 2.