I just installed WPlayer 16 on my Win 10 Pro laptop and created a VM which runs CentOS 8. I need to configure the VM with a static IP number so that I can take it on the road. How can I make that happen? I've only found info out on the web on how to do it for WPro using a utility that doesn't seem to be available in WPlayer.
You mean how to do port forwarding on your VMware Host, right? (Assigning a static IP happens, of course, on the guest side). VMware Workstation Pro has a GUI for this.
There is this other, very recent thread, discussing how to have VMware Workstation Pro network configuration functionality on a Player. The solution was to install VM Pro, you can use it for 30 days without a license for evaluation. After that, the Utility is still available for your use.
(I'm listing the other thread here, because it is not self-evident: "vEthernet adapters cause VM to not have connection on startup".)
Yes I installed Pro and configured VMnet0 to bridge to my laptop nic (top of attached Pic). I then updated my now static IP'd VM to use the Custom VMnet0 config.
However, I don't see where I can assign a subnet address and the host connection column shows a dash, so it's not connected. When I went back into the VNE, now it shows a subnet of 192.168.174.0 (bottom of attached Pic), that is until I hit change settings, then it reverts back as in the top, which is confusing. That 174 subnet is unreachable on my laptop so I don't know where that setting even came from.
I also don't see VMNet0 listed in the ipconfig /all output, even after rebooting my laptop. I do see/have seen VMnet1 and VMnet8 and I can ping them just fine. Neither VMnet1 and VMnet8 get me out the internet however from the guest VM. I don't see anywhere else to configure VMnet0, enable it, etc.
I found a sample network config diagram for VMnet0 at https://docs.vmware.com/en/VMware-Workstation-Pro/16.0/com.vmware.ws.using.doc/GUID-AB5295E7-7EFC-4B... but I don't see the virtual network adapter anywhere.
This should be doable whether you're using Pro or Player, at least it has been for me on a Linux host. Do you have a file called dhcpd.conf in a folder called vmnet8? This is where I setup permanent leases for my guests.
I don't remember the exact details of port forwarding in VM Pro, and thus cannot follow all the aspects of your question, but ...
... the idea of that is that when a request comes to your laptop to use a server port of Apache (which I gather you want to get done), it will be forwarded to a VM with a certain NAT address.
The VM static IP is set in the VM, as the OS has it. Typically ipv4 address. There you set subset and gateway (which is the key to get into internet). If in doubt what to have there, check them first when you have them set automatically. Your static IP needs obviously to be outside the range of DHCP. You can have google DNS there, as secondary or tertiary, to make sure that DNS always works (126.96.36.199) . In *buntu there is a GUI for setting up networking.
Thus, this port forwarding does nothing to your Internet connection from the VM. You will use NAT, because no other networking makes sense in this case (if you use Bridged, you don't need port forwarding and host-only is exlusive to Host). Your VM ip needs to be within NAT address space, otherwise networking doesn't work under the Host. Your Host address space can be whatever when you do port forwarding using the Host name, which doesn't change when the Host is put into some other network. When you have a static ip on the VM, you don't need to reserve anything in the DHCP server (that functionality is for corporate use with DHCP servers servicing a large number of PCs, where the number of available IP's is the problem and quick management is desired when client PCs keep on changing).
I hope this matches what you are trying to do.
I figured it out finally. To make this work, I used the nmtui tool and created a new ethernet adapter on my CentOS 8 VM of type Bridge, using the same static IP number I gave to the VM (borrowed from VEA VMnet8). The default adapter ens33 is set for dhcp.
So now my VM ip addresses are as follows:
192.168.210.68 192.168.42.101 # the 192.168.42 subnet is from VEA VMnet8.
The 1st one is from my wifi dhcp and the 2nd one is the static IP.
For the VM network adapter setting, I set it to Bridged (Automatic) and restarted the VM. Now I can access the VM from my laptop using the static IP number and it can access the internet for yum/dnf work.
I need to now confirm that works on the road next and then see what happens in 29 days when the WPro trail expires.
Thanks for your help.
Thanks, but no that file doesn't exist on my VM or my laptop. I did find a way to make it work however, I just posted a solution. Sounds like there's more than 1 way to make it happen.
Great that you got it working.
For NAT networking:
However, for clarity: When VM is set to static IP, as its OS has it, you can ALWAYS access the VM from the Host using that static ip-address. (Even if it is not static, you can still access with ip-address, but you need to know it, even if it changes in a reboot).
You can also access the VM, always from the Host, with the VM computer name, IF the Host knows the name-ip resolution. You can ensure that it does, on Windows OS, with editing of "hosts" file and rebooting after the edit. For some traffic a two-way traffic is required, but you do not ever need to edit VM "hosts" file, because the VM always knows the Host.
You can also access a VM, from other NAT VMs, if you bring the name-ip resolution to each VM, by editing the Host file to include all the computers in the mix (sometimes, I use a mix of 3-4 NAT VM computers, which need to find each other within applications and databases and IIS). Just remember that a two-way traffic may happen even if it feels like one way, only ... thus, the name resolution both ways.
My previous explanation of port forwarding was about accessing a NAT VM for the outside, not from the Host. With the Host, you don't need to do anything in order to find the VM with the static ip-address. Just have the static ip-address in NAT address space and configure it correctly.
Thanks for the help and networking knowledge. I'm just a database guy.
So it works fine for at least 2 locations and I'll try a 3rd tomorrow. Shouldn't be a problem. The kicker in all of this is that I didn't need to download and run the VNE app. I had set VMnet0 to bridged mode and selecting my laptop NIC. I just restarted the VM and it works fine. So the only thing that I've done is turn the VMnet8 adapter into a switch/router, for lack of a better term. Then adding a new network adapter on the VM to point gateway ip number to 42.0 and the ip address to 42.101. On the VM, the only reference to the static ip number is in the new network adapter that I created.
I haven't needed to make any changes in Win 10 so far so I'll leave it alone for now. All I need to do is downgrade back to Player and uninstall virtualbox.
If I repeat the same steps on my app server VM 2, I'm assuming I'll get the same results. I guess I won't need to NAT the two.
Figures that the Windows software would use a different name (C:\ProgramData\VMWare\vmnetdhcp.conf)
Here's a link that should give you exactly what you want - http://www.milasbowman.com/howto/2015/07/setting-up-dhcp-reservations-on-vmware-workstation/. Even though the article is old, it should still apply. The main config info is near the bottom of the page.
Glad that it works for you - which I think is the main thing and I think you got something from your experiment.
Since you expressed a further interest in this, I want to clarify.
To my understanding, you just want to access your VM from your host, using IP-address, and not dependent on which network your laptop is (correct me if I'm wrong), or if it is in Wireless or Wired networking.
For that to happen, you would not have to do anything, just use delivered NAT networking of VMware. Because you wanted to use Bridged, you created your own NAT, successfully - it isn't a switch, since that is passive equipment - nor is it a router, since that is reserved for much more complicated functionality - but it is Network Address Translation, NAT.
By using NAT, you would have got some primitive security, because your NAT VM cannot be found, by default, from the outside network. Since you use Bridged with your VM, you are connection to "some other network on the road", which you may not be familiar with. Since your VM is a server, a very well known Apache server, it's not a good thing in principle - you need to take extra measures for protecting it. Well, this is perhaps speculative, because you have your own networking arrangements in play.
For a static address of a computer, that is obviously is a matter of that particular computer. This functionality is the basis of any computer targeted for a network (Windows 3.1 wasn't, since that everything is directly for networking, generally speaking). You have two other choices:
- configure DHCP so that it doesn't change the address on reboot, for example in 20 days. This may be required with some licensing software in order to prevent licenses to get stuck in a reboot situation.
- reserve addresses in DHCP server. This is when IP-addresses are scarce, which is never the case in a single computer environment
One extra thing, as mentioned NAT would work right out of the box in your situation. However, when VMware software is updated, network address space will more than likely change - it doesn't always and if you ask me, it never should when updating the software. In that case, you NAT VM will stop working, because your static address is not within the VMware NAT address space. For correcting that, you have two choices.
- change the address space of NAT. That happens from VMware Workstation Pro network configuration, as discussed how to have that.
- change the static address of the computer. That is perhaps the simplest way, very quick to carry out.
I use the first one, because I have several VMs in NAT, which need to see each other. I also sometimes copy/move ALL of them to another environment, like from a Windows laptop to a Linux workstation, and because I have the same address space for NAT on both computers, they will work right away without doing anything (just use a reliable way to copy).
I hope this clarifies further about other possibilities, which you may or may not be interested in.
Thanks for the link. All of the file creation steps can be skipped in the current versions, but the rest of the steps helped out. It turns out the 2nd ethernet adapter I created on the VM guest failed Saturday. After goi thru the link steps, I think it's because the 1st address to assign was .128, and I had assigned .101. Once I updated it to .101 for the lower address, I switched the VM adapaters to NAT and all is well. When I created the 2nd and 3rd VM's, it assigned .102 and .103 respectively, which is perfectly acceptable.
So yes, I needed to install VNE to at least find the lower/upper address range so as to not wind up out of bounds.
Kevin - from the 805
Yes, the scenario you describe at the top is what I'm striving for. As I just mentioned in another reply, the upshot of trying to do it my way failed in the long run. On Saturday, everything failed. So I dropped the VM guest ethernet adapter I created and switch my VM's to NAT. The failure of the original config I think was because I was assigning an address (.101) outside of the VMnet8 lower address setting of .128. Without using VNE, I don't think I would have figured that out, as I didn't see the upper/lower addresses documented anywhere. If I understood NAT more than I do now, I would have had not cared what addresses I wanted. I only cared about them not changing as I move around. As a bonus, there was no need to make any manual config file changes on the guest VM.
Lessons learned and hopefully rememberd.
OK, very good.
As for address range, typically in NAT, address range starts from .100 or in your case .128. Upper limit might be .199, typically not over .200.
When you use static address, you need to give an address which is not within automatic range What the range is, you can check as you did or just check what is that DHCP gives for the first computer. Or you don't need to check, if you just give a number between .3 and .99, because those typically are not within the automatic range. NAT happens (in many cases by default) in all kinds of boxes that you use with an Internet connection. Most people like to get the address automatically and that comes from DHCP into an area reserved for home use, like 192.168.x.x. Nobody in basic use, uses the external address (WAN) that an ISP operator gives you - that is the box's own address towards the outside world. VMware NAT is basically the same, just another layer. ISP's address that you get, is also a NAT address within ISP's own boxes - they do not give a real Internet address to you, unless you pay extra money for it. That kind of real Internet address would be directly accessible from everywhere in the world and if your server wouldn't be very well protected, worms would eat it very quickly. There are obviously many different possibilities in the entire workflow that I described - I just explained what seems to be the most common case, relevant to your workflow.
There is typically no need to do anything in any configuration file. There is a GUI for network config. I'm including here the GUI for Ubuntu Studio, the latest version. With desktop OS's, there is always a GUI. Like explained before "Ifconfig" or a GUI selection "Connection Information" will show you the contents of those fields. Typically, the box address is .1, DNS is also .1 and subnet mask is 255.255.255.0 . (You can also have DNS 188.8.131.52 as secondary or tertiary to ensure that names work in Internet, even if ISP's name server goes down or your box doesn't rely names for you.)
I hope this explains further.
The matter that I explained before, was about naming services not working on your laptop towards VMs. That is a result of copy-VMs. If you don't have any, you don't need to worry about it. Just "ping VM's name" the VM from the Host to find out, typically it works straight away. But since you are using tcp/ip addresses, this doesn't matter anyway.
Still, if you want to configure VMware DHCP-server somehow, then the above does not match. In that case, you probably have to redo the exercise with each VMware update. I'm not sure, because I never want to configure software, if it isn't necessary. I always configure first things that I manage myself, like the contents of each VM. When you configure software, you loose the portability of VMs between systems and OS's. Also OS upgrades may have an effect on this, depending on the OS. These may not be valid considerations in your case, but for me changing software behavior when it isn't necessary, is like asking for trouble. I prefer using delivered Management Tools that have been there forever. But in the end, this is a matter of taste.