CarltonR's Posts

Depending upon your skill level . . . within the Windows VM undertest: Adding virtual lid-close switch to Windows for testing Simulating windows laptop in virtual machine?   or alternatively, just set Windows to Sleep/Hibernate  

Absolutely no problem with installing and running Win Svr 2022, the iso I use was from Microsoft's main public eval site.  It may be helpful for you to provide a tad more information. In the meantime, might I suggest that you try to setup the VM but without linking it to the iso, to start with.  In other words, select 'I will install the operating system later', then select the Guest OS from the pulldown menu page, allocate the appropriate number of processors and memory, and complete the setup.  Once that is done, then go back into the VMs virtual machine Devices settings, select 'CD/DVD (SATA)' and from the 'Use ISO image file' select the Win Svr 2022 iso.  Start the VM and see what happens.

It's not clear as to why you might consider it to be VMware Workstation related . . . but, I'm sure that this can be ascertained.  So, some questions: - What specific Win 32 bit VMs are affected, are they the same OS type/level ? - the patches that are being applied, are they consistent across the VMs OS's ? - Is it a particular patch or groups of patches that are causing this issue ? - Were any software changes made to either the Host OS or VMware Workstation ? - Would suggest reviewing your VMware Workstation log to see if it's picked up anything - for consistency, what is the type and interface of drive being used for the assigned partition given the 'D:' designator ? I assume that before you applied the patches you took a backup.  

Your issue is, is that both VM1 and VM2 have an identical allocated [Ethernet] MAC Address, namely . . . VM1   00-0C-29-1B-F9-BA VM2   00-0C-29-1B-F9-BA Suggest, on both your VMs: 1.  Select the virtual machine and select VM > Settings. 2. On the Hardware tab, select the virtual network adapter and click Advanced. 3. Click Generate to have Workstation Pro generate a new address, take note and verify that it's not being used by any other VM. 4. Click OK to save your changes.

A tad more info might be useful . . . - could you run ipconfig/all [Win] on the host and on two VMs in question, and any others you have running at the same time (ifconfig if Linux) and then post the results. - is the Win 10 laptop connected to a LAN/WAN, if so, what is its setup (IP, subnet, DHCP range, etc.,)

May I suggest that you review the following, which may assist you to resolve your issue . . .  https://communities.vmware.com/t5/VMware-Workstation-Pro/Virtualized-Intel-VT-x-EPT-is-not-supported-on-this-platform/m-p/2930785/highlight/true#M177714 [27th Sep 2022] https://communities.vmware.com/t5/VMware-Workstation-Pro/Intel-VT-x-EPT-is-not-supported/m-p/2921091/highlight/true#M176963 [28th July 2022] https://communities.vmware.com/t5/VMware-Workstation-Pro/Virtualized-Intel-VT-x-EPT-is-not-supported-on-this-platform/m-p/2911083/highlight/true#M175927 [25th May 2022] https://communities.vmware.com/t5/VMware-Workstation-Pro/Virtualized-Intel-VT-x-EPT-is-not-supported-on-this-platform/td-p/2911010 [24th May 2022] https://communities.vmware.com/t5/VMware-Workstation-Pro/Virtualized-Intel-VT-x-EPT-is-not-supported-on-this-platform/m-p/2876898/highlight/true#M172309 [8th Nov 2021 https://communities.vmware.com/t5/VMware-Workstation-Pro/Virtualized-Intel-VT-x-EPT-is-not-supported-on-this-platform/m-p/2875470/highlight/true#M172113 [30th Oct 2021] https://communities.vmware.com/t5/VMware-Workstation-Pro/Virtualized-Intel-VT-x-EPT-is-not-supported-on-this-platform/m-p/2911083/highlight/true#M175927 [25th May 2021] https://communities.vmware.com/t5/VMware-Workstation-Player/Virtualized-Intel-VT-x-EPT-Error/m-p/2819666/highlight/true#M36056 [29th Dec 2020] https://communities.vmware.com/t5/VMware-Workstation-Pro/Virtualized-Intel-VT-x-EPT-is-not-supported-on-this-platform/m-p/2300534/highlight/true#M137799 [18th Oct 2020]

hummmm . . . it would appear that the registry change only works when upgrading from Win 10 to Win 11, rather then Win 11 to Win11.  In addition, booting from an external image also does not have the desired effect (error message: upgrade option isn’t available . . . using installation media). With a bit of research I did find this on elevenforum.com [excerpt below] which I have tested, and it worked, so you might like to give it a go. Overview - Disconnect from the internet before attempting to upgrade an unsupported device to 22H2. - Replace appraiserres.dll with a dummy file of zero length. - During Win 11 setup checks, select updates as 'not right now'. Procedure i. Disconnect the workstation/VM from the internet ii. Replace the appraiserres.dll with a dummy file of zero length. Make a 'New Text Document' on your desktop, rename it appraiserres.dll, and put that in place of the original one. Note: you cannot change this file if using an ‘expanded’ iso, or any protected media, if this is the case then just copy the content to another location on the workstation/VM to be upgraded, and modify and run from there. iii. Run the Win 11 22H2 setup.exe iv. From the setup menu select 'Change how Setup downloads updates'    and on the next window select 'Not right now' v. Then, continue to install as per normal . . . As this relates to Microsoft then would suggest that if you have any further queries then would suggest heading over to the good folks at elevenforum.com for further assistance. Notes and Observations As an exercise I ran through the upgrade with only changing the appraiserres.dll file with a dummy file of zero length . . . and ignored the 'disconnect from the Internet' and the 'Change how Setup downloads updates', and all worked without these two steps.  It may be down to the particular setup/configuration of the Win 11 which is being upgrade, so select the option which best suits your environment.

Are you saying that you are unable to connect any USB devices to a VM, I assume that they work on the HP laptop, if so, then suggest checking . . .  - that the USB devices are showing up in the connection selection on the VMs ? - is the VMware USB Arbitration service/process running ?       [you've not indicated which operating system you are using for the Host] . . . or, have I misunderstood your question !

When you say that you "reinstalled" VMware Workstation Pro . . . was it that you installed it over the copy that was already installed, or uninstalled it and then installed afresh ? In addition, did you install/update the compiler ?   sudo apt install build-essential

Recommendations, observation and yup, sorry more questions . . . 1. "no VMs natively created by Workstation, yet. What would be a quick VM to create" [@GB10]  Try Win 10 (first test the VMware Workstation without VMTools, and then with, to see if the GUI/.vmx retains the network setting after shutting down the VM) 2. "Same issue for all 3 VMs downloaded from ESXi server" [@GB10] - what where the file types that were copied to their own folder on the Workstation host ? - and how did you setup the VMs within VMware Workstation ? One additional thing, could you humor me and uninstall VMTools from one of the ESXi migrated Windows VMs.  Clearly having first secured a backup of the VM before doing so, and then test.

As @RDPetruska says, this is not normal . . . just to try and get a broader understanding of the issue, I have a few questions.   - You say that the VMs were moved from an ESXi server, are you seeing the same issue for VMs that were originally created 'natively' within VMware Workstation.  In other words, is this unique to the migrated ESXi VM or are you seeing this issue across the board ? - In the original question you mention 'a VM' but further down, when explaining the original source being from an ESXi server you refer to 'VMs'.  Assuming that more than one VM was moved is this occurring for all that were moved . . . or was this just a 'keyboard' mistype. - How did you import the ESXi VM into VMware Workstation and which files were used ? - as a matter of interest, what is the VMware Workstation Hosts OS ?   Post Note: other information that may well be helpful. - what is the VM Guest operating system and its function ? - is VMware Tools currently installed on the VM ? - and, are there any plugins/scripts that have been added to VMware Workstation ?

@johnjohn33333 wrote: any advcie? Well yes, don’t use Host-only if you wish to connect the VM to the wider network, use either NAT or Bridged. In addition, your second screen capture appears to be conflating two different windows, one of which obscures the other, so if you are using a VPN, then for the time being turn it off.  Do any of your other VM's have network issues ? Would suggest . . .   Prerequisites:      - The Win 10 Host has access to both the local network and the Internet      - All VPN's are disabled      - Set the Win Svr 2016 VM Hardware - Network Adapter to NAT      - The Win Svr 2016 network is configured to use DHCP   Checks:      - [Host, Win 10] confirm the network settings using ipconfig/all command ?      - [VM, Win Svr 2016] confirm the network setting using ipconfig/all command ?      - [VM, Win Svr 2016] If the above look correct, then try ping/tracert the following:              localhost; DHCP allocated default gateway; Win 10 host IP; network routers default address.        

For completeness.    Shared Folder for a Virtual Machine Prerequisites: Verify that the virtual machines use a guest operating system that supports shared folders. See Guest Operating Systems That Support Shared Folders. Verify that the latest version of VMware Tools is installed in the guest operating system. Verify that permission settings on the host system allow access to files in the shared folders. For example, if you are running Workstation Pro as a user named User, the virtual machine can read and write files in the shared folder only if User has permission to read and write them. [https://docs.vmware.com/en/VMware-Workstation-Pro/16.0/com.vmware.ws.using.doc/GUID-D6D9A5FD-7F5F-4C95-AFAB-EDE9335F5562.html]

@-Jim- @ wrote: "but this is not unrelated to VMWare" Agreed in one sense, in that VMware is interacting with the VM, however my comment regards Local vs. Domain still stands. What you have to bear in mind is that when a Windows device is added to an AD Domain then the policies are derived from it.  It may be the case that VMware is attempting to configure the mapped drive but either does not have the appropriate permissions or that the AD polices being applied are overriding this, but to confirm this would require additional research.  You could add the local policies to AD Domain account policies, or as suggested just map it through AD (assuming Windows based VMs) or map it when logged into the AD authenticated VM. There is also the niggling question of permissions, to map a drive you have to have permissions to the shared area otherwise it will fail.   @-Jim-  wrote: "There is no note or caveat that says "Sometimes this won't work (i.e.: if the machine is a member of a domain)" VMware can't know how you setup the VM, it just sees an Operating System and attempts to configure it as best it can.   Post Note: Have you attempted to reinstalling VMware Tools on the Guest VM when it is logged into the AD Domain ?

Just to clarity, is this what you describe . . .  As part of your investigation, I would suggest you divide the problem into manageable chunks to confirm [and exclude] where the issue may or may not reside.  For example, is it a VMware Workstation or pfSence related problem, do the various individual subsystems operate correctly (VMs, Virtual Networks, WAN, pfSense/DHCP, etc.,). So would suggest first of all, checking that the Host Only VMs are working as expected.  So start with giving the connected Win 10 VM devices for the time being, fixed IPs within the same subnet (or alternatively, or in addition to, temporality enable the VMware DHCP on the Virtual Host Only Networks), and then confirm that they can communicate with each other and the pfSense VM.  Then do the same for the FreeBSD VM. Then, if this all works out, return the VM's back to DHCP to focus on the pfSense DHCP services.  For this I would suggest reviewing the relevant pfSense documentation to provide a bit more focus on where the issue may reside. I'm assuming that the pfSense VM is successfully picking up a DHCP allocated IP from your WAN [Bridged] network ?  

@KazeEnji wrote: Every time I try to boot my guest with Intel-VT enabled, I get this error: VMware Workstation does not support nested virtualization on this host. Suggest reviewing: Virtualized Intel VT-x/EPT is not supported on this platform https://communities.vmware.com/t5/VMware-Workstation-Pro/Virtualized-Intel-VT-x-EPT-is-not-supported-on-this-platform/m-p/2930785/highlight/true#M177714 VMware Workstation does not support nested virtualization on this host https://communities.vmware.com/t5/VMware-Workstation-Pro/VMware-Workstation-does-not-support-nested-virtualization-on/m-p/1864220/highlight/true#M110963

Try this . . .    sudo nmcli networking on Then rerun 'ip addr' and confirm that 'eth0' changes:    . . . state DOWN group default qlen 1000    . . . state UP group default qlen 1000 if so, then check internet access  

Local and Domain accounts are different accounts, and therefore have different profiles . . . there are a number of ways you could map the drive, but would suggest doing so within AD so that the mapped drive is loaded wherever that particular Domain account is used, assuming that this is your goal.   As an aside this is unrelated to VMware Workstation, and all to do with Microsoft Windows Operating Systems and Active Directory.