Vmware Vshield zone firewall blocks traffic between VM and V switch

I configured a vShield Zones firewall rule to block traffic between virtual machines on the same vSwitch but traffic is not being blocked

Details

vShield Zones blocks traffic according to trust zones. A trust zone is a set of two ore more networks that are seperated by a Layer 3 or Layer 4 device. For vShield Zones to block traffic, the traffic must be routed between two separate networks. If the traffic is between two virtual machines on the same vSwitch, the vShield agent protecting the vSwitch detects the traffic, but cannot block the traffic because the traffic does not leave the vSwitch.

Solution

To block traffic between virtual machines on the same vSwitch, you can separate the virtual machines by using different subnets, such as different VLANs. When VLANs are used, the traffic must exit the vSwitch to the network device that handles the VLAN identification. After VLAN identification is complete, the traffic is routed back to the vSwitch, and can then be blocked by the vShield agent.
Labels: ,

Removing VEM400-200906002-BG from an ESXi Host

Details

The Cisco patch VEM400-200906002-BG should only be installed along with ESXi400-200906401-BG, and only if you are using the Cisco Nexus 1000V product. Installing the patch on ESXi hosts without the Cisco Nexus 1000V can have unpredictable results.

Solution

If you have accidentally installed VEM400-200906002-BG use the vSphere CLI to verify that the bundle is installed and then remove the bundle.
To remove VEM400-200906002-BG from and ESXi host
  1. Use the vSphere CLI to query the target host for installed bundles.

    vihostupdate.pl --server 10.21.170.40 --username root --query

    If the bundle is installed, the output of the query command will be similar to the following:

    ---------Bulletin ID--------- -----Installed----- ----------------
    VEM400-200906002-BG 2009-07-08T14:18:56 Cisco Nexus 1000
    ESXi400-200906401-BG 2009-07-08T14:18:56 Updates Firmware
    ESXi400-200906402-BG 2009-07-08T14:18:56 Updates Tools

  2. If you see the listing for VEM400-200906002-BG, use the vSphere CLI to remove the bulletin using the following command:

    vihostupdate.pl --server 10.21.170.40 --username root -B VEM400-200906002-BG --remove

    If the command completes, you should receive the following output:

    Removed bulletin from host successfully.

  3. Run the query again to verify that the VEM400-200906002-BG bundle has been removed.

    C:\Program Files\VMware\VMware vSphere CLI\bin>vihostupdate.pl --server 10.21.170.40 --username root --query

    The output of the query command will be similar to the following:

    ---------Bulletin ID--------- -----Installed----- ----------------
    ESXi400-200906401-BG 2009-07-08T14:18:56 Updates Firmware
    ESXi400-200906402-BG 2009-07-08T14:18:56 Updates Tools
Labels: ,

VMotion CPU Compatibility - Migrations Prevented Due to CPU Mismatch - How to Override Masks

Vmotion migration preventing due to CPU Mismatch

Details

This article provides overriding VMotion CPU compatibility restrictions between ESX Servers.

Solution

If you have recent Intel 45nm Core 2 CPUs and were directed to this article by a message in VirtualCenter, refer to VMotion errors between different Intel 45nm Core 2 revisions (1008315) before continuing.

By default, VirtualCenter only allows migrations with VMotion between compatible source and destination CPUs. This article provides information about when it is appropriate to override CPU-compatibility constraints, how to override them, and provides links to additional information and resources. Topics include:

Background

Compatible CPUs for VMotion purposes means that source and target CPUs must have the same manufacturer (Intel or AMD) and be members of the same basic processor family, Pentium 4 or Core, for example. Within a given processor family, the source and target CPUs must also have certain common and extended features implemented (or not implemented, depending on the specific feature) for VMotion to succeed.

To determine if the source and target CPUs meet VMotion requirements, VirtualCenter compares the target CPU to a default bit mask definition. The default bit mask has evolved with each version of VirtualCenter to support (or preclude) VMotion migration given a specific set of CPU features. For example, the VirtualCenter 1.x bit mask does not flag the NX (Intel) or XD (AMD) bits, but the VirtualCenter 2.x bit mask does.

At the same time, manufacturers (Intel and AMD, specifically) continually improve their CPUs, releasing new features that may or may not be compatible with VMotion.

To circumvent VMotion’s CPU-compatibility checking for a specific feature or extended feature, you can modify the default bit mask. The bit mask-modification process (sometimes referred to in various VMware documents as “relaxing” a particular constraint) varies according to VirtualCenter Server version and ESX version.

A full discussion of the underlying components and how VirtualCenter Server and ESX Server host systems handle them is beyond the scope of this article. For more information, see CPU Compatibility Masks and Configuring Virtual Machines in the Basic System Administration Guide. Another useful resource is the technical paper on VMware VMotion and CPU Compatibility.

For specific information about Intel and AMD CPUs and VMotion compatibility, see:

For simplicity sake, modifications to the default bit mask for CPU compatibility for VMotion are also referred to simply as masks, typically identified by the CPU feature—for example, the SSE3 mask in this and related KB articles 1991 and 1992.

Scope of Modifications

The process of modifying VMotion compatibility settings depends on the VirtualCenter version and the ESX Server host system running the virtual machines. Also varying by VirtualCenter Server version and ESX Server version, is the scope of modifications to the default bit mask, as follows:

  • VirtualCenter 1.x—Modifications to the default bit mask apply to all ESX Server 2.x hosts being managed by VirtualCenter.
  • VirtualCenter 2.x with ESX Server 3.x—Modifications must be made on a per-virtual-machine basis using the VI Client.
  • VirtualCenter 2.0.1 Patch 2 (and later) with ESX Server 2.x or ESX Server 3.x—Modifications are made at the VirtualCenter Server level but can be defined by processor manufacturer, by version number, and other criteria.
  • VirtualCenter 2.5.x (and later)—Modifications to the CPU mask must be made while the virtual machine is powered off due to a risk of application or guest operating system instability.
  • VirtualCenter 2.5.0 Update 2 (and later)—Adds support for Enhanced VMotion Compatibility(EVC). EVC masks are applied before per-virtual-machine masks and global VirtualCenter server masks.

CPU Identification Tools

To obtain information about a host system’s CPU, you can use the appropriate vendor’s tool or VMware’s CPUID tool, depending on the system:

This KB discusses modifying the default bit mask in several different environments.
Warning : VMware does not support or recommend modifying the VMotion constraints for CPU extended features because of the risk of application or guest operating system failure after migration.


VirtualCenter Server 1.x

VirtualCenter Server 1.x bit mask applies to all virtual machines on the ESX Server 2.x host system. VirtualCenter Server 1.x uses a locally stored text file, config.ini , for configuration information.

Modifying the Default Bit Mask

To modify the default bit mask for all ESX Server 2.x hosts managed by VirtualCenter Server 1.x, make the changes to the VirtualCenter Server’s configuration file (config.ini ). The process of editing the config.ini file is generally the same (regardless of CPU vendor):
  1. Log in to the VirtualCenter Server as an administrator.
  2. Navigate to the VirtualCenter configuration directory. By default this directory is C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter
  3. Open the config.ini file in a text editor.

    Note: If the config.ini file does not exist, create it.
  4. Add the appropriate line for the CPU feature that you want masked to the config.ini file. See the Table below for more details.
  5. Save the file and restart the VirtualCenter Management Server Service so that the modified bit mask takes effect. The next time VMotion is attempted, the specific feature is ignored by VirtualCenter, and VMotion proceeds.
CPU Feature VirtualCenter Server 1.x Vendor Supported?
SSE3 migrate.ignore.extfeature.bits = 0xE5BD Intel, AMD No
SSSE3 migrate.ignore.extfeature.bits = 0x4E7BC Intel No

migrate.ignore.feature.bits = 0x20000

SSE4.1 migrate.ignore.extfeature.bits = 0x8E5BC Intel No
Single-core-Dual-core migrate.ignore.feature.bits = 0x90000000 AMD Yes
PERF_MSR migrate.ignore.extfeature.bits = 0xE5A0 Intel Yes


As an example, to effectively enable VMotion between a host based on an Intel CPU that has SSE3 and one that does not,add:

migrate.ignore.extfeature.bits = 0xE5BD

Warning: VMware does not support or recommend modifying the VMotion constraints for CPU extended features because of the risk of application or guest operating system failure after migration.

VirtualCenter Server 2.x and 2.5.x

VirtualCenter Server 2.x provides two different ways to modify VMotion CPU constraints, depending on the version of ESX Server being used:

  • For ESX Server 3.x hosts CPU constraints can be modified:

    • On a per-virtual-machine basis through the VMware Infrastructure Client (VI Client) graphical user-interface.

      Note: As of VirtualCenter 2.5.x, modifications to the CPU mask of an individual virtual machine must be made while the virtual machine is powered off. The ability to edit the CPU mask while powered on has been disabled because of the risk of application or guest operating system instability.

    • globally through the VirtualCenter Configuration file (vpxd.cfg ), as long as the host is being managed using VirtualCenter 2.0.1 Patch 2 and above.

  • For ESX Server 2.x hosts CPU constraints can only be modified globally by editing the the VirtualCenter configuration file (vpxd.cfg ).

    Note: To use global CPU masks VirtualCenter must be version 2.0.1 Patch 2 or later.

Per-Virtual-Machine Masking with ESX Server 3.x

In Virtual Center 2.x, the default bit mask for VMotion constraints among ESX Server 3.x systems can be applied on a per-virtual-machine basis using the VI Client. Regardless of CPU type or mask modifications, accessing the necessary dialog boxes is generally the same, as follows:

  1. Launch VI Client and connect to the VirtualCenter Server as an administrator.
  2. Click the Virtual Machine that you want to migrate from Inventory.
  3. Click Edit Settings on the Summary tab. The Properties window for the virtual machine displays.
  4. Click the Options tab in the Properties window.
  5. Click the CPUID Mask option to display the CPU Identification Mask information and settings.
  6. Click Advanced to display several settings-related boxes, including CPU Identification Mask, in the right-hand pane.
From here the mask can be modified appropriately for the selected virtual machine, depending on what needs to be masked. The following sections include steps on modifying the masks for several common CPU registers:

Modifying Default NX/XD Mask

Issues with the NX/XD features on CPUs are common. Ensure that the feature is either enabled (or disabled) in the BIOS of all physical ESX Servers to avoid these compatibility error messages.

Note: There may be no option to enable or disable the mask on all the physical servers.
If a CPU feature compatibility issue with the NX/XD bit is encountered, an error similar to the following is generated:

The CPU of the host is incompatible with the cpu feature requirements of virtual machine; problem detected at CPUID level 0x80000001 register 'edx'.
To modify the mask to enable or disable the NX/XD CPU bit:
  1. Navigate to the virtual machine Options tab (see steps above, if necessary).
  2. Select Hide the NX flag from guest or the Expose the NX flag to guest to disable or enable this CPU compatibility check for the selected virtual machine.
  3. Click OK to save the change.

    Note: The NX/XD mask can only be modified when the virtual machine is powered off.

Modifying Default Mask

Several other masks can be modified, to provide further compatibility for VMotion. To modify other CPU masks:
  1. Navigate to the virtual machine Options tab (see steps above, if necessary).
  2. Click Advanced to open the CPU Identification Mask properties dialog box.

    Note: The CPU Identification Mask dialog box has two tabs—Virtual Machine Default, and AMD Override. Most modifications for Intel CPU features are made on the Virtual Machine Default page. Modifications for AMD CPU features are made on the AMD Overrides page and are discussed in the next section of this article.

  3. Click the Virtual Machine Default tab to activate the dialog box, if necessary.

To modify the mask for a specific feature, enter the series of dashes and 0s as shown in the table below.

Feature Level Row Mask
SSE3 1 ecx

---- ---- ---- ---- ---- ---- ---0 -0-0

SSSE3 1 ecx

---- ---- ---- -0-- ---- --0- ---0 -0--

1 edx

---- ---- ---- --0- ---- ---- ---- ----

SSE4.1 1 ecx

---- ---- ---- 0--- ---- ---- ---- ----

When all modifications are complete, click OK and exit the CPU Identification Mask dialog box.

Modifying AMD-Specific Masks

Features that are specific to AMD processors are listed and can be changed on the AMD Override tab. To modify other CPU masks for AMD Processors:
  1. Navigate to the virtual machine Options tab (see steps above, if necessary).
  2. Click Advanced to open the CPU Identification Mask properties dialog box.
  3. Click the AMD Override tab to activate the dialog box. The AMD Override page displays.

To modify the mask for a specific feature, enter the series of dashes and 0s as shown in the table below.

Feature Level Row Mask
SSE3 1 ecx
---- ---- ---- ---- ---- ---- ---- ---0
RDTSCP 80000001 edx
---- 0--- ---- ---- ---- ---- ---- ----
80000001 ecx
---- ---- ---- ---- ---- ---- ---- 0---
CMPXCH16B
1 ecx

---- ---- ---- ---- --0- ---- ---- ----

FFXSR 80000001 edx
---- --0- ---- ---- ---- ---- ---- ----
3DNPREFETCH 80000001 ecx
---- ---- ---- ---- ---- ---0 ---- ----

When all modifications are complete click OK and exit the CPU Identification Mask dialog box.

Combining Mask Modifications

You can combine modifications to the default bit mask to allow migration with VMotion between groups that are incompatible based on more than one CPU feature. For example, to filter-out the compatibility check for both SSE3 and SSSE3 combine the following:

---- ---- ---- ---- ---- ---- ---0 -0-0

and:

---- ---- ---- -0-- ---- --0- ---0 -0--

to yield:

---- ---- ---- -0-- ---- --0- ---0 -0-0

for the ecx register mask.

Global Masking with ESX Server 2.x and ESX Server 3.x

For ESX Server hosts managed by VirtualCenter 2.0.1 Patch 2 (and subsequent releases), the bit mask can be modified globally by manually editing the VirtualCenter configuration file (vpxd.cfg ). The VirtualCenter 2.x-series configuration file, vpxd.cfg , contains XML tags defining various elements and settings for the VirtualCenter server. Bit-masks can be modified by adding the appropriate XML tags to define the mask in the context of a guest operating system configuration option to the configuration file .
Note: The vpxd.cfg file is located by default in C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter
Although a full discussion of building these elements is beyond the scope of this article, the About the Tags section provides a brief overview. See the following section for specific steps related to Editing the VirtualCenter Configuration File and XML tags for Common Mask Patterns like, SSE3 , SSSE3 , and SSE3 and SSSE3 Combined .

About the Tags

The tags identify the register to which the mask applies, and for which hosts and which versions the mask applies. The tags are direct descendants of the tag, in the vpxd.cfg file. Tags are listed in the order in which they must be nested:
  • —Direct descendant (child) tag of element. The vpxd.cfg can contain a single guestOSDescriptor element.
  • <host-product-and-version> —Between the opening and closing tags, you can nest multiple host-product-and-version-tags that specify the version and host to which the masks you define apply. For ESX Server hosts, the tags can be specified generally, as in for an ESX Server 2.x host, for an ESX Server 3.x host or can be specified precisely— , for example. The tag identifies various maintenance release levels of the ESX Server to which the subsequently nested mask applies.
  • —Allows for the configuration to be restricted by virtual machine hardware version. For example, , , or . In the example below is specified, meaning that the mask applies to all virtual machine hardware versions.
  • —Allows for a guest version to be specified. For example, , , , and so on. In the example shown below, is specified, and therefore the mask applies to all guest versions.
  • —This tag precedes the actual mask. The mask is then defined for , , or , depending on your needs. Tag elements that are used to define the mask, identify the CPU mask. The element details include vendor, CPU ID level, and the CPU register. The valid choices for these are:
CPU vendor
, ,
CPU ID level
, , ,
CPU register
, , ,

Tags must be embedded in the order shown in the table. A CPU-vendor tag is followed by a CPU-ID-level tag, followed by a CPU-register tag. Immediately following the CPU-register tag is the sequence of 32 dashes and x-s that represent the actual 32-bit register mask appropriate for the feature being modified. The mask is then followed by the CPU-register-, CPU-ID-level-, and CPU-vendor-closing tags.

Note: A mask defined using tag is used by the system only when no vendor-specific mask has been specified for the same CPU ID level.
  • When you have finished defining masks, close with .
Below is an example of the tag order, shown in the context of the vpxd.cfg file. The and opening and closing tags are already in the vpxd.cfg file. The opening tag can be placed directly after the opening tag, embed the appropriate tags to suit your needs, followed by the closing tag.







[Elements and mask definition go in here. Common Mask Patterns can be copy-and-pasted from the below example patterns.]





...
In this example, any mask embedded in the [Elements and mask...] placeholder section applies to all ESX Server 2.x hosts being managed by the VirtualCenter Server, and to all guest operating systems.
Below are some sample XML snippets that can be copied and pasted into a vpxd.cfg file for the common mask modification patterns . VMware does not support or recommend modifying the VMotion constraints for CPU extended features because of the risk of application or guest operating system failure after migration.

Editing the VirtualCenter Configuration File

To edit the VirtualCenter Configuration File:
  1. Navigate to the location of the vpxd.cfg file. By default, the vpxd.cfg file is located in the C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter directory.
  2. Use a text editor (such as WordPad) to open the vpxd.cfg file. The vpxd.cfg file is an XML-formatted text file that contains various optional settings for the VirtualCenter Server.
  3. Add opening and closing tags to identify the hosts, versions, and other specifics to which the mask applies.
  4. Copy and paste from the examples in Common Mask Patterns, or apply other masks as needed for your deployment.
  5. When the appropriate changes are made, restart the VMware VirtualCenter Server Service to enable the new masking.

Common Mask Patterns

The following are example masks for several common CPU feature masks. Copy, paste, and modify them as required for the environment. VMware does not support or recommend modifying the VMotion constraints for CPU extended features because of the risk of application or guest operating system failure after migration.


SSE3



----:----:----:----:----:----:---x:-x-x




----:----:----:----:----:----:----:---x





SSSE3



----:----:----:-x--:----:--x-:---x:-x--
----:----:----:--x-:----:----:----:----







----:----:----:-x--:----:--x-:---x:-x-x
----:----:----:--x-:----:----:----:----




----:----:----:----:----:----:----:---x
Labels: ,

Install - Upgrade Vmware Tools

Installing / Upgrading VMware Tools

Details

  • Only low video resolutions are available in the virtual machine
  • Color depth cannot be set very high
  • Network speed in the virtual machine indicates that it is 10Mbps
  • The mouse gets stuck in the virtual machine window
  • Drag and drop features do not work
  • Sound does not play or is not available in the virtual machine

Solution

VMware Tools is a suite of utilities that enhances the performance of the virtual machine’s guest operating system and improves management of the virtual machine. Although the guest operating system can run without VMware Tools, you lose important functionality and convenience.

Overview of the VMware Tools installation

The following are general steps used to start the VMware Tools installation in most VMware products. Certain guest operating systems may require different steps, however these steps work for most operating systems.

  1. Power on the virtual machine.
  2. Log on to the virtual machine using an account with Administrator or root privileges.
  3. Wait for the desktop to load and be ready.
  4. Click Install VMware Tools. There are two places to find this option:
    • Right-click on the running virtual machine and choose Install VMware Tools.
    • Right-click on the running virtual machine and click Open Console. In the Console menu click VM and click Install VMware Tools.
  5. The VMware Tools installation wizard appears inside of the virtual machine's console. Follow the prompt in the wizard to complete the VMware Tools installation. Choose the Typical installation option.

    Note: If you are installing VMware Tools on Linux, the above steps generally work. A non GUI installation script is available if no GUI is installed. For more information and installation instructions, see the Additional Information section.

    Note: If you are installing VMware Tools on Netware, follow the instructions contained in the User's Guide for your VMware Product. Additional steps are necessary to start the VMware Tools installation on this operating system. See the Additional Information section for documentation links.

  6. When the VMware Tools installation has finished, restart the virtual machine to complete installation.
Note: VMware Player is designed to only play back pre-built virtual machines. The person who created the pre-built virtual machine must use VMware Tools if it is needed. VMware Player cannot be used to install VMware Tools.

Specific guest operating system considerations

Certain guest operating systems have specific installation requirements. For more information, see How do I install VMware Tools in a Linux virtual machine on ESX Server 3.x? (5242329) .

Additional Information

For detailed instructions on installing VMware Tools in the VMware product in use, see the User's Manual for the appropriate VMware product. The manuals also outline the manual script installation procedure to install VMware Tools in a Linux guest operating system or in a Novell operating system.
To access the manuals, see VMware Documentation. Click on the applicable product name and download the User's Manual. Search for VMware Tools within the manual.
Labels:

Compare Vmware ESX and ESXi

ESX and ESXi Comparision


Capability

VMware ESX

VMware ESXi

Service Console

Service Console is a standard Linux environment through which a user has privileged access to the VMware ESX kernel. This Linux-based privileged access allows you to highly customize your environment by installing agents and drivers and executing scripts and other Linux-environment code.

VMware ESXi is designed to make the server a computing appliance. Accordingly, VMware ESXi behaves more like firmware than traditional software. To provide hardware-like security and reliability, VMware ESXi does not support a privileged access environment like the Service Console of VMware ESX. To enable interaction with agents, VMware has provisioned CIM Providers through which monitoring and management tasks – traditionally done through Service Console agents – can be performed. VMware has provisioned RCLI to allow the execution of scripts.

Remote CLI

VMware ESX Service Console has a host CLI command through which VMware ESX can be configured. ESX 3.5 Update 2 supports RCLI.

VMware ESX Service Console CLI has been ported to a Remote CLI (RCLI) for VMware ESXi. RCLI is a virtual appliance that interacts with VMware ESXi hosts to enable host configuration through scripts or specific commands.

Note:
  • RCLI is limited to read-only access for the free version of VMware ESXi. To enable full functionality of RCLI on a VMware ESXi host, the host must be licensed with VI Foundation, VI Standard, or VI Enterprise.

  • The VMware Infrastructure toolkit for Windows and the Perl toolkit access ESXi through the same API as RCLI. Similarly, these toolkits are limited to read-only access for the free version of VMware ESXi. When the host is upgraded to VI Foundation, VI Standard, or VI Enterprise, these toolkits have write-access and provide a scriptable method for managing ESXi hosts.

  • The following Service Console CLI commands have not been implemented in RCLI:
    • ESXcfg-info
    • ESXcfg-resgrp
    • ESXcfg-swiscsi

Scriptable Installation

VMware ESX supports scriptable installations through utilities like KickStart.

VMware ESXi Installable does not support scriptable installations in the manner ESX does, at this time. VMware ESXi does provide support for post installation configuration script using RCLI-based configuration scripts.

Boot from SAN

VMware ESX supports boot from SAN. Booting from SAN requires one dedicated LUN per server.

VMware ESXi may be deployed as an embedded hypervisor or installed on a hard disk.

In most enterprise settings, VMware ESXi is deployed as an embedded hypervisor directly on the server. This operational model does not require any local storage and no SAN booting is required because the hypervisor image is directly on the server.

The installable version of VMware ESXi does not support booting from SAN.

Serial Cable Connectivity

VMware ESX supports interaction through direct-attached serial cable to the VMware ESX host.

VMware ESXi does not support interaction through direct-attached serial cable to the VMware ESXi host at this time.

SNMP

VMware ESX supports SNMP.

VMware ESXi supports SNMP when licensed to a VI Foundation, VI Standard, or VI Enterprise edition. The free version of VMware ESXi does not support SNMP.

Active Directory Integration

VMware ESX supports Active Directory integration through third-party agents installed on the Service Console.

VMware ESXi with a Virtual Infrastructure license and in conjunction with VirtualCenter allows users to be authenticated via Active Directory. In this configuration, users can log in directly to an ESXi host and authenticate using a local username and password.

The free version of VMware ESXi does not support Active Directory integration at this time.

HW Instrumentation

Service Console agents provide a range of HW instrumentation on VMware ESX.

VMware ESXi provides HW instrumentation through CIM Providers. Standards-based CIM Providers are distributed with all versions of VMware ESXi. VMware partners may inject their own proprietary CIM Providers in customized versions of VMware ESXi. To obtain a customized version of VMware ESXi, you typically have to purchase a server with embedded VMware ESXi through a server vendor.

At this time, HP also offers its customized VMware ESXi Installable on www.vmware.com. Dell, IBM, and FSC will soon offer their customized version of VMware ESXi on www.vmware.com.

Remote console applications like Dell DRAC, HP iLO, IBM RSA, and FSC iRMC S2 are supported with ESXi.

Note: COS agents have a longer lineage than CIM Providers and are therefore more mature. VMware is actively working with its 250+ partners to close the CIM Provider–Service Console agent gap.

Software Patches and Updates

VMware ESX software patches and upgrades behave like traditional Linux based patches and upgrades. The installation of a software patch or upgrade may require multiple system boots as the patch or upgrade may have dependencies on previous patches or upgrades.

VMware ESXi patches and updates behave like firmware patches and updates. Any given patch or update is all-inclusive of previous patches and updates. That is, installing patch version “n” includes all updates included in patch versions n-1, n-2, and so forth.

VI Web Access

VMware ESX supports managing your virtual machines through VI Web Access. You can use the VI Web Access to connect directly to the ESX host or to the VMware Infrastructure Client.

VMware ESXi does not support web access at this time.

Licensing

VMware ESX hosts can be licensed as part of a VMware Infrastructure 3 Foundation, Standard, or Enterprise suite.

VMware ESXi hosts can be individually licensed (for free) or licensed as part of a VMware Infrastructure 3 Foundation, Standard, or Enterprise suite.

Individually licensed ESXi hosts offer a subset of management capabilities (see SNMP and Remote CLI).

ESXi – Free License

(ESX not available without VI)

VI Foundation

(with ESX or ESXi)

VI Standard

(with ESX or ESXi)

VI Enterprise

(with ESX or ESXi)

Core hypervisor functionality

Yes

Yes

Yes

Yes

Virtual SMP

Yes

Yes

Yes

Yes

VMFS

Yes

Yes

Yes

Yes

VirtualCenter Agent

Yes

Yes

Yes

Update Manager

Yes

Yes

Yes

Consolidated Backup

Yes

Yes

Yes

High Availability

Yes

Yes

VMotion

Yes

Storage VMotion

Yes

DRS

Yes

DPM

Yes

Labels: , ,
Subscribe to: Posts (Atom)