As a Type 2 Hypervisor, Workstation Pro runs as an application on top of a full Operating System like Windows 10 or Ubuntu Desktop and claims compute and hardware resources from the parent OS, then allocates those resources to the VMs you create.
Type 2 compute workflow
- Hardware > Windows HAL (Windows OS) > Workstation Pro > Virtual Machine
Type 1 compute workflow
- Hardware > ESXi > Virtual Machine
Type 2 Hypervisors (like Workstation Pro) differ from Type 1 Hypervisors (Like ESXi) in that Type 2 Hypervisors must “ask” the host OS for resources, whereas Type 1 Hypervisors allocate hardware resources directly to the VMs.
Why I use Workstation Pro
VMware workstation is an ideal platform for development, support and lab environments. Not only is it convenient and affordable, but it is the most full-featured of the VMware Hypervisor platforms available.
Additionally, users of VMware vSphere 6.5 have found it either impossible or unreliable to deploy Virtual Appliances from the vSphere Web Client (ESXi Only), and so Workstation Pro has become the preferred choice for creating and deploying Virtual Appliances in OVF or OVA format
You can read my earlier write-up of VMware Workstation Pro 12 for background and system requirements
Installing VMware Workstation Pro 14
Getting VMware Workstation Pro 14 doesn’t even require a login
Installing Workstation Pro 14 follows accustomed Windows Installer procedures
Accept and Next
Choose the Enhanced Keyboard Driver and Next
Decide if you want to Check for Updates and if you want to be part of the VMware CEIP, then Next
Choose if you want shortcuts, then: Next
Wait for 30-40 seconds
Save any open data and Reboot
Configuring Workstation Pro
Be sure to start VMware Workstation Pro as an Administrator, or you will not be able to access the virtual network editor
I always start in trail mode and add my license key later.
And here is Workstation Pro 14
Workstation Pro Virtual Networks
Before you build any VMs, you will probably want to adjust the properties of the virtual networks (VMnet (s)) to which you can assign VMs.
Let’s say that your home/office network is 192.168.10.0/24 and your workstation has an IP of 192.168.10.102, just like mine.
When you build your VMs in Workstation Pro, you will have three basic options for networking:
Host-only network (VMnet) has no external connectivity and VMs are entirely isolated, but may share connectivity with other VMs on the same Host-only VMnet. You may have more than one Host-only VMnet, which is isolated from other VMnet(s)
NAT creates a Network Address Translation network (VMnet) within your PC or Workstation where VMs may have connectivity to the rest of your network and the world, but use the IP address of your PC or workstation to do so. The VMs running behind NAT are to your home/office network what devices you run behind a router at home are to the Internet.
Bridged VMs will be a part of your home/office network and will receive DHCP Addresses if there is a DHCP Server configured to offer an IP, or may be assigned static IP addresses. The disadvantage to Bridged is that if you accidentally assign an IP that is in-use, you will create a conflict. Moreover, in some environments, just a few VMs may exhaust a DHCP pool and leave others without connectivity.
Open the Virtual Network Editor as Administrator (it is required to open as Administrator to edit Virtual Networks)
Here you can see that the NAT (VMnet8 in my case) network will have a Subnet Address of 192.168.118.0
It’s possible to set any Network (“Subnet IP”) / Mask (“Subnet mask”) combination you choose for NAT, or even create new VMnet Networks. For my purposes, 192.168.118.0/24 is just fine.