Difference between revisions of "Funtoo:User Services/VMware Overview"

Revision as of 07:15, February 16, 2022

Funtoo Linux is starting to use some VMware products for internal services. This page is here to document various general things related to VMware products.

ESXi vs vSphere vs vCenter

You have probably heard of VMware ESXi -- the free (as in beer) version of VMware's hypervisor. VMware has started to transition to a new name which is VMware vSphere Hypervisor. Sometimes you may see this listed as "VMware vSphere Hypervisor (ESXi)".

VMware's product naming can be confusing, so this change is probably a good thing. You may have also heard of something called "vCenter". Let's look at how ESXi, vSphere and vCenter relate to each other. Think of "vSphere" as an umbrella, which contains the following components:

vSphere
- Hypervisor (aka ESXi)
- vCenter

User Interfaces

VMware vSphere Hypervisor (aka ESXi) provides its own web user interface, which has basic functionality for managing virtual machines on that particular host. In contrast, vCenter provides a more feature-rich web user interface. The catch is that vCenter requires a paid license, whereas the ESXi web interface can be used with a 'free' license. vCenter provides many conveniences for managing a virtual environment, and also serves as a building block for VMware's other commercial offerings.

ESXi Deployment

When deploying ESXi (aka 'vSphere Hypervisor'), it's strongly recommended to secure the management port using a VPN such as WireGuard VPN. It's also highly recommended to enable the NTP service, and deploy a DNS server for the management interface, for both resolution of local VMs that may be deployed, as well as allowing ESXi to resolve the NTP server. For vCenter, an internal DNS server is required, whereas for ESXi it is only highly recommended.

ESXi Upgrades

The easiest way to perform ESXi upgrades is via the ssh console. This command can be run to browse for the latest updates to ESXi:

user $ ssh root@esxi-host.mgmt
root # esxcli software sources profile list --depot=https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml
Name                              Vendor        Acceptance Level  Creation Time        Modification Time
--------------------------------  ------------  ----------------  -------------------  -----------------
...
ESXi-7.0U2c-18426014-standard     VMware, Inc.  PartnerSupported  2021-08-24T00:00:00  2021-08-24T00:00:00
ESXi-7.0U2c-18426014-no-tools     VMware, Inc.  PartnerSupported  2021-08-24T00:00:00  2021-08-04T11:40:25
ESXi-7.0U2d-18538813-standard     VMware, Inc.  PartnerSupported  2021-09-14T00:00:00  2021-09-14T00:00:00
ESXi-7.0U2d-18538813-no-tools     VMware, Inc.  PartnerSupported  2021-09-14T00:00:00  2021-08-27T10:33:50
ESXi-7.0U2e-19290878-standard     VMware, Inc.  PartnerSupported  2022-02-15T00:00:00  2022-02-15T00:00:00
ESXi-7.0U2e-19290878-no-tools     VMware, Inc.  PartnerSupported  2022-02-15T00:00:00  2022-01-31T07:40:31
ESXi-7.0U3c-19193900-standard     VMware, Inc.  PartnerSupported  2022-01-18T00:00:00  2022-01-18T00:00:00
ESXi-7.0U3c-19193900-no-tools     VMware, Inc.  PartnerSupported  2022-01-18T00:00:00  2022-01-12T00:03:42

This command can take up to a minute or so to produce output, but will show an exhaustive list of updates that can be installed. Some of these updates require that the ESXi server be placed into "maintenance mode" (via web UI) prior to the update being applied.

To apply a specific update, a command like the following can be run:

Note

Name resolution and outbound Internet access from the management network must be functioning for this to work. The "standard" upgrade is recommended.

root # esxcli software profile update -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml -p ESXi-7.0U2d-18538813-standard

After the update is applied, the host must generally be restarted, and then can be moved out of maintenance mode via the web UI.

VMware Licensing: The "Processor"

Commericial VMware products require licenses. These licenses center around the definition of "processor". In VMware terminology, a "processor" is a physical CPU (one per socket), capped at 16 physical cores.

Let's look at an example of how this plays out in reality. Assume you have a vSphere/vCenter "32 Processor" license, and you have one server. This server has two of the following physical CPUs in it:

Intel(R) Xeon(R) Gold 6230 CPU @ 2.10GHz

Each of these processors has 20 physical cores, and 40 hyper-threaded cores. So -- is the "32 Processor" license sufficient for your purposes?

It turns out that the answer is "yes, it is more than enough." Let's do the math and see how this licensing works. We have two physical processors in our server, but they are more than 16 physical cores each. A license for Intel CPU socket 1 is covered by a single VMware processor license, but leaving 4 remaining cores since each VMware license only covers up to 16 per license. Another license for Intel CPU socket 2 is covered by a single VMware processor license, leaving another remaining 4 cores uncovered. We can then cover these leftover "extra" cores from each Intel Processor -- 8 physical cores in total -- with a third single processor license. This means that our single 40-core/80-thread server just used up 3 of our 32 Processor licenses for vSphere/vCenter.

LXD Compatibility

If you are planning to deploy LXD on a virtual machine, then you will likely be using Linux bridging for your containers. If you are mapping this bridge into a VMware virtual switch, then you will need to enable "promiscuous mode" on the VMware virtual switch in order for the bridging on the Linux VM side to work properly. Once this is done, any LXD containers bridged into the vSwitch will be able to communicate with other devices outside the VM itself as expected.