CarltonR's Posts

Security Onion is based on Ubuntu Linux . . . therefore to install Tools, you might like to try these commands (as sudo):       apt remove open-vm-tools-desktop open-vm-tools       apt install open-vm-tools-desktop open-vm-tools  To move files between host and the VM you may need to setup 'Shared Folder' or 'mapped drive'

@kimwoo wrote: There was an initial .NET problem, so it was resolved by deleting .NET AutoCAD 2015 base requirement is '.NETv4.5' so deleting .Net (version not given above) would clause an Error 2908.  So would suggest installing, from Windows Features, an appropriate version, and then moving on from there.    

May I suggest that the first port of call for any investigation are the log files, both the Host OS and VMware. As an aside I assume that the Ubuntu 22.04 is updated to the latest, and your gcc compiler is also to the latest version. Suggested install procedure.   VMware's official compatibility guides: Supported host operating systems for Workstation Pro 16.x, 17.x and Workstation Player 16.x, 17.x (80807) https://kb.vmware.com/s/article/80807 Supported host operating systems for Workstation Pro 12.x, 14.x, 15.x (2129859) https://kb.vmware.com/s/article/2129859

@SecBob wrote: "I knew someone was going to tell me Android isn't supported by VMware . . ." Just because VMware does not officially support an OS/Appliance doesn't mean they won't run, in realty there are many in this camp, as testimony shows.  After all, is this not the technical challenge that is presented, and VMware provides the tool to support this.  

User Support - When Android happens to doze off, then to wake it up . . . one of two methods: i. select the 'menu' key from the keyboard ii. select the 'Send Ctrl+Alt+Del' button on the VMware toolbar. - Assuming no touch screen available, to get to the Apps page on the Android desktop . . . using the mouse, drag up from the bottom of screen.   Post note: Added additional wakeup method [keyboard] (4th March 2023)

Android-86 install instructions . . . works for me: VMware Workstation VM settings OS:             Other – FreeBSD 12 64-bit Memory:    2 GB Storage:    20 GB Network:   Custom – VMnet0 Android Installation Select Yes Select Reboot After rebooting Select the first boot option Press ‘e’ to edit the boot commands before booting Select the first boot command Press ‘e’ once more to edit the boot command for GRUB Press the left arrow key to move the pointer to the left Replace 'quiet' with nomodeset xforcevesa Press Enter when done Press b to boot At the Android splash screen press Alt + F1 At the second Android splash screen press Alt + F1 again At the console prompt, type the following commands:    mkdir /mnt/sda    mount /dev/block/sda1 /mnt/sda        note: /sda1 is a number one, not the letter lowercase 'L'    vi /mnt/sda/grub/menu.lst        note: /menu.lst is a the letter lowercase 'L' not a number one Press i to edit and Replace Change 'quiet' to nomodeset xforcevesa Press Esc key and :w and Enter to save configuration Press :q and Enter to exit Type reboot and Enter to reboot the system Allow to boot to the android splash screen. Then go through the normal Android setup. Note: Would recommend when you get to the 'Select a Home app' select Quickstep        Select Always Notes: 1.  Graphics: if you know what you are doing, then you can add the 'video=WRez x HRez x depth' (depth is optional) parameter after the nomodeset xforcevesa, i.e. video=1280x720.  Selecting an incorrect or incompatible resolution can create some interesting effects. User Support: - When Android happens to doze off, then to wake it up . . . one of two methods: i. select the 'menu' key from the keyboard                         ii. select the 'Send Ctrl+Alt+Del' button on the VMware toolbar.                       - Assuming no touch screen available, to get to the Apps page on the Android desktop . . . using the mouse, drag up from the bottom of screen. References i.   Android-86 site: https://www.android-x86.org/ ii.  Android-86 downloads: https://www.fosshub.com/Android-x86.html.  

I'm not entirety clear as to some of your requirements or terminology, for instance when you say emulator, do you mean running within an existing Ubuntu operating system VM, or as a standalone Android VM ?   If I understand the requirements: VMware Workstation pro 16 Host OS: Unknown VM:  Ubuntu/Android [unclear what this means, refer above]          VM Tools Network: unknown [but not the wireless IoT network]                  VPN [not clear if on the Host, VM or just on the 'VPN halfway across the country'] Purpose: Remote management (VPN, Pill Dispenser, users device) I've used Android-x86 within a standalone VM without any issues.  As an aside, as Android is a mobile operating system based on a modified version of the Linux kernel, is there something specific that is required to remotely manage remote devices ?   Post Note: could you also provide a more detailed description of what 'doesn't work'.  

From research, what I can glen is that what is shown in the Windows Ethernet Status view for VMnet1 and VMnet8 is just a "reported network speed" and can generally be ignored. Quotes from other forum entries: "Virtual NICs do not really have a line speed, since processing is done by the host's physical CPU" [@scott28tt] " . . . networks are only limited by the hosts CPU resources, but anyway, Gbit network is way faster than anything the virtual disks can handle" [@continuum] If you run a local network speed test from Host via appropriate network interfaces and from VM . . . what are you seeing ?

Review these . . . Where is the option to change adapter type? [13th July 2017] https://communities.vmware.com/t5/VMware-Workstation-Pro/Where-is-the-option-to-change-adapter-type/m-p/1396232 Virtual network cards only 100mbs, how to speed up? [8th Feb 2013] https://communities.vmware.com/t5/VMware-Workstation-Pro/Virtual-network-cards-only-100mbs-how-to-speed-up/td-p/845231 Network speed limitation in Workstation [3rd April 2011] https://communities.vmware.com/t5/VMware-Workstation-Pro/Network-speed-limitation-in-Workstation/td-p/2090713 Troubleshooting a slow network connection in VMware Workstation (2019058) [25th Sep 2018] https://kb.vmware.com/s/article/2019058 Configuring Virtual Network Adapter Advanced Settings [31st May 2019] https://docs.vmware.com/en/VMware-Workstation-Pro/17/com.vmware.ws.using.doc/GUID-15BBACE2-44DA-41A3-8355-D2BA8CA4549D.html

Have setup a VMware Workstation [Windows] with two virtualized ESXi (nested) environments, with absolutely no issues, communications work in all directions, including pings between ESXi VMs. Humour me . . . may I suggest that you go back to basics with a minimum setup, confirm its operation, and then incrementally progress from there, one step at a time. So, would suggest: - shutdown ALL VMware Workstation VMs. - reset VMnet0 to default (bridged etc.,). - Setup a VM with only the bridged interface (VMnet0) attached, no other network interfaces, and Install a clean default ESXi, and test. - Setup a second VM with only the bridged interface (VMnet0) attached, no other network interfaces, and Install a clean default ESXi, and test. - Verify that the two VM instances can communicate [ping, etc.,] - Assuming successful, then move on from there, and add one of the Host-only interfaces to one of the ESXi VMs, and test everything again, then add it to the second ESXi VM, test . . . then the next, and so forth. If not successful then investigate before moving on.  

From the information so far provided one possibility may be duplicate network interface settings, possibly a Mac address or two. One thing that is not clear is whether these VMs were 'cloned', 'imported' or created from scratch, I suspect one of the formers.   The basis for this, is that it would appear that the network interfaces are working, namely the Host-only (VMnet2/3) and Bridged (VMnet0) are able to communicate, namely ping every which way, both internal and external devices, including the Win 2022 VM, and an external vCenter being able to manage these VMs . . . but, just not between the ESXi VMs over the VMnet0 network interface.   Now, other possibilities may be that there is a firewall rule in place, but then this would have to be very specific to ESXi ICMP traffic going to only other local ESXi VMs . Another possibly could be a quirk in the VMware Workstation software, but specific to your implementation !   So might I initially suggest . . . - Methodically go through each of the network interfaces (VMnet0, VMnet2, VMnet3) which are presented to the three ESXi VMs (esxi-san-01, esxi-san-02, esxi-san-03) and confirming that there are no duplicate Mac addresses. Suggest using the VMware Workstation app as outlined in the comment/thread above. - I assume that the host names and IPs are unique within the network subnet. - Confirm how these ESXi VMs came into existence ‘cloned’, ‘imported’ or crated from scratch ? - Do you require VMnet1, VMnet4 and VMnet5 ? - One useful investigation tool you might like to consider, is a Network Sniffer.

Could you just confirm the MAC address's for the VMnet0 interface for each ESXi VMs . . . or are they the ones in the 'Mgmt NIC MAC' list above  ?   Post Note: could you also confirm the allocated Mac address for each of the ESXi VMs VMnet0 interface, but this time from within VMware Workstation, as follows: Select the ESXi esxi-san-01 virtual machine and navigate to VM > Settings. On the Hardware tab, select the virtual network adapter for VMnet0 and click Advanced. Take note the Mac address. Repeat for the next ESXi VM (esxi-san-02, esxi-san-03).

Have been following this thread with interest . . . it maybe me, but I don't feel I've necessarily grasped your full implementation. If I understand it correctly you have: - VMware Workstation Pro 17 running on a Win 11 Host. - Three individual ESXi 7 VMs have been created, networks connected as Bridge (VMnet0). - All local Devices on the network can ping the ESXi VMs. - All Host-only configured devices can ping each others IP. - Win 11 Host can ping the ESXi VMs and vice versa. - A created Win 2022 VM can ping the ESXi VMs, and they to it. - vCenter can 'communicate' with the ESXi VMs. - the issue is, is that your ESXi VMs (esxi-1, esxi-2, esx-3) cannot ping each other over the Bridged network [or is it over a Host-only network !]. Assuming this is correct, then a few questions: - How many network interfaces are presented to the ESXi VMs ? - Other then just 'ping' from one ESXi to the other ESXi VMs have you tried any other commands or protocols during your diagnostics investigation to determine the network path taken.  Such as 'traceroute' or ESXi commands such as 'esxcli network ip connection list' or 'esxcli network ip neighbor list' and their various derivatives. - have you tested any other forms of connection between the ESXi VMs ? - Where does the vCenter reside ?