Skip to main content

ESX And ESXi Compare with Other vendor

ESXi and ESX Architectures Compared

VMware ESX Architecture. In the original ESX architecture, the virtualization kernel (referred to as the vmkernel) is augmented with a management partition known as the console operating system (also known as COS or service console). The primary purpose of the Console OS is to provide a management interface into the host. Various VMware management agents are deployed in the Console OS, along with other infrastructure service agents (e.g. name service, time service, logging, etc). In this architecture, many customers deploy other agents from 3rd parties to provide particular functionality, such as hardware monitoring and system management. Furthermore, individual admin users log into the Console OS to run configuration and diagnostic commands and scripts.

VMware ESXi Architecture. In the ESXi architecture, the Console OS has been removed and all of the VMware agents run directly on the vmkernel. Infrastructure services are provided natively through modules included with the vmkernel. Other authorized 3rd party modules , such as hardware drivers and hardware monitoring components, can run in vmkernel as well. Only modules that have been digitally signed by VMware are allowed on the system, creating a tightly locked-down architecture. Preventing arbitrary code from running on the ESXi host greatly improves the security of the system.

Architectures Compared

VMware ESX [~ 2 GB] VMware ESXi [< 150 MB]

  • VMware agents run in Console OS
  • Nearly all other management functionality provided by agents running in the Console OS
  • Users must log into Console OS in order to run commands for configuration and diagnostics

  • VMware agents ported to run directly on VMkernel
  • Authorized 3rd party modules can also run in Vmkernel. These provide specific functionality
    • Hardware monitoring
    • Hardware drivers
  • VMware components and third party components can be updated independently
  • The “dual-image” approach lets you revert to prior image if desired
  • Other capabilities necessary for integration into an enterprise datacenter are provided natively
  • No other arbitrary code is allowed on the system


Understand the Difference between ESX and ESXi

VMware ESXi is VMware’s most advanced hypervisor architecture. Learn about the differences with the previous generation architecture, VMware ESX:

Capability ESX 4.1 ESXi 4.1 ESXi 5.0
Service Console Present Removed Removed
Admin/config CLIs COS + vCLI PowerCLI + vCLI PowerCLI + vCLI (enhanced)
Advanced Troubleshooting COS Tech Support Mode ESXi Shell
Scripted Installation Supported Supported Supported
Boot from SAN Supported Supported Supported
SNMP Supported Supported (limited) Supported
Active Directory Integrated Integrated Integrated
HW Monitoring 3rd party agents in COS CIM providers CIM providers
Serial Port Connectivity Supported Not Supported Supported
Jumbo Frames Supported Supported Supported
Rapid deployment and central management of hosts via Auto Deploy Not Supported Not Supported Supported
Custom image creation and management Not Supported Not Supported Supported
Secure syslog Not Supported Not Supported Supported
Management interface firewall Supported Not Supported Supported



Compare ESXi to Other Vendors' Offerings

Hypervisor Attributes VMware ESXi 5.0
Windows Server 2008 R2 SP1 with Hyper-V Citrix XenServer 5.6 FP1
Small Disk Footprint

144 MB disk footprint
(VMware ESXi)

>3GB with Server Core installation

~10GB with full Windows Server installation

1GB
OS Independence

No reliance on general purpose operating system
(VMware ESXi)

Relies on Windows 2008 in Parent Partition

Relies on Linux in Dom0
management Partition
Hardened Drivers

Optimized with hardware vendors

Generic Windows drivers

Generic Linux Drivers
Advanced Memory Management

Ability to reclaim unused memory, de-duplicate memory pages, compress memory pages

Only uses ballooning. No ability to de-duplicate or compress pages.

Only uses ballooning. No ability to de-duplicate or compress pages. Does not adjust memory allocation based on VM usage.
Advanced Storage Management

Lacks an integrated cluster file system, no live storage migration

Lacks an integrated cluster file system, no live storage migration, storage features support very few arrays
High I/O Scalability

Direct driver model

I/O bottleneck in parent OS

I/O bottleneck in Dom0 management OS
Host Resource Management

Network traffic shaping, per-VM resource shares, set quality of service priorities for storage and network I/O

Lacks similar capabilities

Lacks similar capabilities
Performance Enhancements

AMD RVI, Intel EPT large memory pages, universal 32-way vSMP, VMI paravirtualization, VMDirectPath I/O, PV guest SCSI driver

Large memory pages,
4-way vSMP on Windows
2008 and Windows 7 VMs only

No large memory pages, no paravirt guest SCSI device, Requires inflexible SR-IOV
Virtual Security Technology

VMware VMsafe™
Enables hypervisor level security introspection

Nothing comparable

Nothing comparable
Flexible Resource Allocation

Hot add VM vCPUs and memory, VMFS volume grow, hot extend virtual disks, hot add virtual disks

Only hot add virtual disks

Nothing comparable
Custom image creation and management

VMware Image Builder allows administrators to create custom ESXi images for different types of deployment, such as ISO-based installation, PXE-based installation, and Auto Deploy.

Nothing comparable

Nothing comparable
Auto Deploy

vSphere Auto Deploy enables faster provisioning of multiple hosts. New hosts are automatically provisioned based on rules defined by user.

Requires in-depth setup in Systems Center Configuration Manager

Nothing comparable
Management Interface Firewall

ESXi Firewall is a service-oriented and stateless firewall that protects the ESXi 5.0 management interface. Configured using the vSphere Client or at the command line with esxcli interfaces.

Nothing comparable

Nothing comparable
Enhanced Virtual Hardware

32-way virtual SMP, 1TB virtual machine RAM, Non hardware accelerated 3D graphics, USB 3.0 device support, Unified Extended Firmware Interface (UEFI).

4-way virtual SMP only, 64 GB RAM per virtual machine

8-way virtual SMP only, 32 GB RAM per virtual machine

Comments

Popular posts from this blog

Docker Container Management from Cockpit

Cockpit can manage containers via docker. This functionality is present in the Cockpit docker package. Cockpit communicates with docker via its API via the /var/run/docker.sock unix socket. The docker API is root equivalent, and on a properly configured system, only root can access the docker API. If the currently logged in user is not root then Cockpit will try to escalate the user’s privileges via Polkit or sudo before connecting to the socket. Alternatively, we can create a docker Unix group. Anyone in that docker group can then access the docker API, and gain root privileges on the system. [root@rhel8 ~] #  yum install cockpit-docker    -y  Once the package installed then "containers" section would be added in the dashboard and we can manage the containers and images from the console. We can search or pull an image from docker hub just by searching with the keyword like nginx centos.   Once the Image downloaded we can start a contai

Remote Systems Management With Cockpit

The cockpit is a Red Hat Enterprise Linux web-based interface designed for managing and monitoring your local system, as well as Linux servers located in your network environment. In RHEL 8 Cockpit is the default installation candidate we can just start the service and then can start the management of machines. For RHEL7 or Fedora based machines we can follow steps to install and configure the cockpit.  Following are the few features of cockpit.  Managing services Managing user accounts Managing and monitoring system services Configuring network interfaces and firewall Reviewing system logs Managing virtual machines Creating diagnostic reports Setting kernel dump configuration Configuring SELinux Updating software Managing system subscriptions Installation of cockpit package.  [root@rhel8 ~] #  dnf   install cockpit cockpit-dashboard  -y  We need to enable the socket.  [root@rhel8 ~] #  systemctl enable --now cockpit.socket If firewall is runnin

Containers Without Docker on RHEL/Fedora

Docker is perfectly doing well with the containerization. Since docker uses the Server/Client architecture to run the containers. So, even if I am a client or developer who just wants to create a docker image from Dockerfile I need to start the docker daemon which of course generates some extra overhead on the machine.  Also, a daemon that needs to run on your system, and it needs to run with root privileges which might have certain security implications. Here now the solution is available where we do not need to start the daemon to create the containers. We can create the images and push them any of the repositories and images are fully compatible to run on any of the environment.  Podman is an open-source Linux tool for working with containers. That includes containers in registries such as docker.io and quay.io. let's start with the podman to manage the containers.  Install the package  [root@rhel8 ~] # dnf install podman -y  OR [root@rhel8 ~] # yum