Installing ESXi 6 Using PXE - Vsphere 6

Preboot execution environment (PXE) to boot a host. Starting with vSphere 6.0, you can PXE boot the ESXi installer from a network interface on hosts with legacy BIOS or using UEFI.

ESXi is distributed in an ISO format that is designed to install to flash memory or to a local hard drive. You can extract the files and boot by using PXE. PXE uses Dynamic Host Configuration Protocol (DHCP) and Trivial File Transfer Protocol (TFTP) to boot an operating system over a network.

PXE booting requires some network infrastructure and a machine with a PXE-capable network adapter. Most machines that can run ESXi have network adapters that can PXE boot.

NOTE PXE booting with legacy BIOS firmware is possible only over IPv4. PXE booting with UEFI firmware is possible with either IPv4 or IPv6.

Overview of PXE Boot Installation Process

The interaction between the ESXi host and other servers proceeds as follows

1. The user boots the target ESXi host.
2. The target ESXi host makes a DHCP request.
3. The DHCP server responds with the IP information and the location of the TFTP server.
4. The ESXi host contacts the TFTP server and requests the file that the DHCP server specified.
5. The TFTP server sends the network boot loader, and the ESXi host executes it. The initial boot loader
6. might load additional boot loader components from the TFTP server.
7. The boot loader searches for a configuration file on the TFTP server, downloads the kernel and other
8. ESXi components from the HTTP server or the TFTP server and boots the kernel on the ESXi host.
9. The installer runs interactively or using a kickstart script, as specified in the configuration file.

Alternative Approaches to PXE Booting

Alternative approaches to PXE booting different software on different hosts are also possible, for example 

1. Configuring the DHCP server to provide different initial boot loader filenames to different hosts depending on MAC address or other criteria. See your DCHP server's documentation.
2. Approaches using iPXE as the initial bootloader with an iPXE configuration file that selects the next bootloader based on the MAC address or other criteria.

VMware ESXi 6.0 U1a / vSphere 6.0 Update 1 Download available

VMware has recently published a patch for ESXi 6.0 

VMware ESXi 6.0 Update 1a Release Notes

What's New

This release of VMware ESXi contains the following enhancements:

I/O Filter: vSphere APIs for I/O Filtering (VAIO) provide a framework that allows third parties to create software components called I/O filters. The filters can be installed on ESXi hosts and can offer additional data services to virtual machines by processing I/O requests that move between the guest operating system of a virtual machine and virtual disks. 

Exclusive affinity to additional system contexts associated with a low-latency VM: This release introduces a new VMX option sched.cpu.latencySensitivity.sysContexts to address issues on vSphere 6.0 where most system contexts are still worldlets. The Scheduler utilizes the sched.cpu.latencySensitivity.sysContexts option for each virtual machine to automatically identify a set of system contexts that might be involved in the latency-sensitive workloads. For each of these system contexts, exclusive affinity to one dedicated physical core is provided. The VMX option sched.cpu.latencySensitivity.sysContexts denotes how many exclusive cores a low-latency VM can get for the system contexts. 

ESXi Authentication for Active Directory:ESXi is modified to only support AES256-CTS/AES128-CTS/RC4-HMAC encryption for Kerberos communication between ESXi and Active Directory.

Support for SSLv3: Support for SSLv3 has been disabled by default. For further details, see Knowledge Base article 2121021.

Dying Disk Handling (DDH): The Dying Disk Handling feature provides latency monitoring framework in the kernel, a daemon to detect high latency periods, and a mechanism to unmount individual disks and diskgroups.

Stretched Clusters: Virtual SAN 6.0 Update 1 supports stretched clusters that span geographic locations to protect data from site failures or loss of network connection.

VMware Site Recovery Manager (SRM) 6.1

New features of Site Recovery Manager 6.1. There are some useful and long awaited features as follows:

• Support Stretched Storage and Orchestrated vMotion
• Enhanced integration with VMware NSX
• Storage Profile Based Protection

As for a quick reminder, Site Recovery Manager enables simplified automation of disaster recovery and the architecture of SRM has not been changed. Depending on RPO requirements, SRM can use vSphere Replication or array-replication.

Storage Profile Based Protection

Site Recovery Manager 6.1 adds a new type of protection group; the storage policy-based protection groups. Storage policy-based protection groups use vSphere storage profiles to identify protected datastores and virtual machines. They automate the process of protecting and unprotecting virtual machines and adding and removing datastores from protection groups. Storage profile-based protection groups enable deep integration with virtual machine provisioning tools like VMware vRealize Automation. This combination makes it easier than ever to deploy and protect virtual machines.

Storage policy-based protection groups utilize vSphere tags in combination with vSphere storage policy based management to enable automated policy based protection for virtual machines. Storage policy-based management enables vSphere administrators to automate the provisioning and management of virtual machines storage to meet requirements like performance, availability and protection. vSphere tags allow for the ability to attach metadata to vSphere inventory, in this case datastores, which makes these objects more sortable, searchable and possible to associate with storage policies. 

Stretched Storage and Orchestrated vMotion

Site Recovery Manager 6.1 now supports using cross-vCenter vMotion in combination with stretched storage such as NetApp Metro Cluster, you can combine the benefits of Site Recovery Manager with the advantages of stretched storage.

Prior to Site Recovery Manager 6.1 customers had to make a choice between using Site Recovery Manager or vSphere Metro Storage Clusters/Stretched Storage to provide a multisite solution that was optimized for either site mobility or disaster recovery without being able to attain the benefits of both solutions simultaneously. Site Recovery Manager 6.1 now supports using cross-vCenter vMotion in combination with stretched storage, thereby combining the benefits of Site Recovery Manager with the advantages of stretched storage.

Enhanced integration with VMware NSX

Networking is typically one of the more complex and cumbersome aspects of a disaster recovery plan. Ensuring that the proper networks, firewall rules and routing are configured correctly and available can quite challenging. Making an isolated test network with all the same capabilities can be even more so. Additionally, solutions like cross-vCenter vMotion require a stretched layer-2 network which can create even more difficulty.

NSX 6.2 has a number of new features which enhance Site Recovery Manager. This means that organizations can now use NSX and Site Recovery Manager to simplify the creation, testing and execution of recovery plans as well as accelerate recovery times.

NSX 6.2 supports creating “Universal Logical Switches”, which allow for the creation of layer-2 networks that span vCenter boundaries. This means that when utilizing Universal Logical Switches with NSX there will be a virtual port

group at both the protected and recovery site that connect to the same layer-2 network.

Hyper-Converged

Corporate technology undergoes a massive shift every so often as new models emerge to meet changing business needs. This chapter is about hyper-converged infrastructure, which is the culmination and conglomeration of a number of trends, all of which provide specific value to the modern enterprise.

So, what is hyper-convergence? At the highest level, hyper-convergence is a way to enable cloud-like economics and scale without compromising the performance, reliability, and availability you expect in your own data center. Hyper-converged infrastructure provides significant benefits:

• Elasticity: Hyper-convergence makes it easy to scale out/ in resources as required by business demands.
• VM-centricity: A focus on the virtual machine (VM) or workload as the cornerstone of enterprise IT, with all supporting constructs revolving around individual VMs.
• Data protection: Ensuring that data can be restored in the event of loss or corruption is a key IT requirement, made far easier by hyperconverged infrastructure.
• VM Mobility: Hyper-convergence enables greater application/workload mobility.
• High availability: Hyper-convergence enables higher levels of availability than possible in legacy systems.
• Data efficiency: Hyper-converged infrastructure reduces storage, bandwidth, and IOPS requirements.
• Cost efficiency: Hyper-converged infrastructure brings to IT a sustainable step-based economic model that eliminates waste.

Hyperconvergence is the ultimate in an overall trend of convergence that has hit the market in recent years. Convergence is intended to bring simplicity to increasingly complex data centers.

Hyper-Convergence Constructs

Convergence comes in many forms. At its most basic, convergence simply brings together existing individual storage, compute, and network switching products into pre-tested, pre-validated solutions sold as a single solution. However, this level of convergence only simplifies the purchase and upgrade cycle. It fails to address ongoing operational challenges that have been introduced with the advent of virtualization.  There are still LUNs to create, WAN optimizers to acquire and configure, and third- party backup and replication products to purchase and maintain.

Hyper-convergence is a ground-up rethinking of all the services that comprise the data center. With a focus on the virtual machine or workload, all the elements of the hyper-converged infrastructure support the virtual machine as the basic construct of the data center.

The results are significant and include lower CAPEX as a result of lower upfront prices for infrastructure, lower OPEX through reductions in operational expenses and personnel, and faster time-to-value for new business needs. On the technical side, newly emerging infrastructure engineers people with broad knowledge of infrastructure and business needs can easily support hyper-converged infrastructure. No longer do organizations need to maintain separate islands of resource engineers to manage each aspect of the data center. To fully understand hyper-convergence, it’s important to understand the trends that have led the industry to this point. These include post-virtualization headaches, the rise of the software- defined data center and cloud.

How to upgrade Site Recovery Manager 5.8 to version 6.0

The Site Recovery Manager 6.0 has been released for a while now so it is a good time to have a look at the upgrade process since the original release build also received a patch in April 2015. Before we jump into the upgrade process, let’s have a quick look at what’s new in Site Recovery Manager 6.0.

• Support for VMware vSphere 6.0, including integration with shared infrastructure components such as Platform Services Controller and vCenter Single Sign On.
• Support for Storage vMotion and Storage DRS on both the protected and recovery sites.
• Protection and recovery of virtual machines in IPv6 environments.
• IP customization enhancements to support dual-protocol IP configurations and independent IPv4 and IPv6 configurations.

As in previous releases, you can upgrade an existing vCenter Sire Recovery Manager installation and the upgrade process will preserve existing information and settings (except the advanced settings) in your current vCenter Site Recovery Manager deployment. Before you begin, make sure you have read the following:

• vCenter Site Recovery Manager 6 – Installation and Configuration guide (chapter 7, Upgrading Site Recovery Manager)
• Check the VMware Product Interoperability Matrix and verify that your current vCenter Site Recovery Manager version upgrade is supported.
• Read the vCenter Site Recovery Manager 6.0 release notes

Note: As per vCenter Site Recovery Manager Installation and Configuration guide, upgrading from SRM 5.0.x and 5.1.x to SRM 6.0 is not supported. Upgrade SRM 5.0.x and 5.1.x to SRM version 5.5.x or 5.8.x release before you upgrade to SRM 6.0.

Upgrade Order

Improved interoperability with SDRS and Storage vMotion

In previous versions of SRM there was basic compatibility with SDRS and Storage vMotion with some documented caveats. Specifically, Storage vMotion would not throw a warning if an attempt was made to move a VM out of it’s consistency group and for SDRS, datastore clusters could only contain datastores from the same consistency group because otherwise SDRS could easily move VMs out of it.

With SRM 6.0 we now have full compatibility with SDRS and greatly enhanced support for Storage vMotion. Datastore groups can now contain any set of datastores, no restrictions, and SDRS will only make automatic migrations between two non-replicated datastores or within datastores in the same consistency group. Also, Storage vMotion will now generate a warning if a user attempts to move an SRM protected VM.

As described in the vCenter Site Recovery Manager Installation and Configurations guide, you must upgrade certain components of your vSphere environment before you upgrade the vCenter Site Recovery Manager. As always, upgrade the components on the protected site before you upgrade the components on the recovery site. Upgrading the protected site first allows you to perform a disaster recovery on the recovery site if you encounter problems during the upgrade that render the protected site unusable. The exception is the ESXi hosts, which you can upgrade after you finish upgrading the other components on the protected and recovery sites.

This makes it much easier for users to create and use datastore clusters, SDRS and Storage vMotion without having to worry about the impact to recovery of their VMs.

Simplified SSL certificate requirements

SRM 6.0 is now deeply integrated with SSO, using it for authentication and SAML token acquisition among other things. This integration with SSO also allowed the external certificate requirements to be relaxed significantly. Previously, certificates were used both for authenticating to the associated vCenter as well as between SRM instances. This imposed a number of restrictions and requirements that made deploying certificates time consuming and difficult. The SRM 6.0 Installation guide provides a detailed description of all the new simplified certificate requirements. These new requirements will make SRM environments more secure and easier to deploy and maintain

Integration with vSphere 6.0 platform services (SSO, Authorization, Licensing, Tags, etc.)

SRM is now fully integrated with and supported by vSphere 6.0. This has benefits for authentication (SSO), tagging (now shared) and the lookup service to name just a few. To use SRM 6.0 requires:

• vCenter Server 6.0
• vSphere Web-Client 6.0
• If using vSphere Replication, version 6.0

Note: The large majority of SRAs that were compatible with SRM 5.8 remain compatible with SRM 6.0. Check the Compatibility Guide for details and confirm with your array vendor if you have questions.

Also, since vSphere Replication 6.0 now supports up to 2000 VMs, this is now supported in SRM 6.0 as well. All other SRM limits remain the same for this release.

The integration of SRM and the separation of the platform services controller (PSC) from vCenter creates a number of new topology possibilities. These topologies can impact SRM so make sure to read this KB List of recommended topologies for vSphere 6.0.x (2108548) when planning your upgrade or deployment. A more detailed post about topologies and SRM will be published soon.

Also be aware that because of the integration of SRM with SSO, vCenter and the PSC time synchronization among all these components is important.

IP customization enhancements

When using the dr-ip-customizer tool for updating VM IP addresses it now allows simultaneous IPv4 and IPv6 static address specification and is backward compatible with SRM 5.X generated spreadsheets. This increases the flexibility of the tool while maintaining compatibility with previous releases.

When upgrading to Site Recovery Manager 6.0 follow these steps as described below.

1. Upgrade all components of vCenter Server on the protected site.

2. If you use vSphere Replication, upgrade the vSphere Replication deployment on the protected site.

3. Upgrade Site Recovery Manager Server on the protected site.

4. If you use array-based replication, upgrade the storage replication adapters (SRA) on the protected site.

5. Upgrade all components of vCenter Server on the recovery site.

6. If you use vSphere Replication, upgrade the vSphere Replication deployment on the recovery site.

7. Upgrade Site Recovery Manager Server on the recovery site.

8. If you use array-based replication, upgrade the storage replication adapters (SRA) on the recovery site.

9. Verify the connection between the Site Recovery Manager sites.

10. Verify that your protection groups and recovery plans are still valid.

11. Upgrade ESXi Server on the recovery site (optional).

12. Upgrade ESXi Server on the protected site (optional).

13. Upgrade the virtual hardware and VMware Tools on the virtual machines on the ESXi hosts.

Source: vCenter Site Recovery Manager 6.0 Installation and Configuration guide.

At this point the Site Recovery Manager is upgraded to version 6.0. If you are logged in to the vSphere Web Client, log out, clear the browser cache and log back in. The Site Recovery Manager extension should be visible now.

Next, upgrade the Protected Site and then verify your protection groups, recovery plans etc.

Datastore un-mounting | Dead path issue (APD)

Vsphere 5.1 onwards the process of removal datastore has been changed, before removing any datastore from ESXi hosts and cluster Right-click the datastore and unmounting.

It is not only the process to remove LUN from ESXi hosts but there are few additional pre-checks and post tasks like detaching the device from the host is must before we request storage administrator to unpresenting the LUN from the backend storage array.

This process needs to be followed properly otherwise it may cause bad issue like Dead path or APD ( All paths down) condition on the ESXi host.

1.  If the LUN is being used as a VMFS datastore, all objects (such as VM, snapshots ,template and HA configuration stored on the VMFS datastore.
2. Ensue the Datastore is not used for vSphere HA heartbeat.
3. Ensure the datastore is not part of a SDRS.
4. Storage I/O control should be disabled.
5. ISO mount and scripts or utilities are accessing the datastore.

Process to remove datatstore or LUN  from ESXi 5.x hosts

• Select the ESXi host -> Configuration - > Storage - > Datastores

(note down the naa id for the datatore which starts from naa.xxx)

•                 Right-click the datastore, which you want to unmounts and select unmounts.

•    Confirm datastore unmounts pre-check is all marked with Green check mark and click on OK.
•     Select the ESXi host -> Configuration -> storage -> devices Match the devices with the naa.id (naa.xx) Right-click the Device and Detach. Verify all the Green checks and click on OK to detach the LUN.

           Repeat the same step for all ESXi hosts, where you want to unpresent this datastore.

•      Inform your storage team to physically unpresent the LUN from the ESXi host using the appropriate array tools.

Rescan the ESXi host and verify detached LUNs are disappeared from the ESXi host.

vSphere 6: vMotion enhancements

With vSphere 6.0 you can migrate Virtual Machines across virtual switches. The new vMotion workflow allows you to choose the destination network which can be on a vSwitch or vDS. This feature eliminates the need to span virtual switches across two locations.

 

VMware vSphere vMotion capabilities have been enhanced on Vsphere 6, enabling users to perform live migration of virtual machines across virtual switches, across vCenter Server systems, and across long distances of up to 100ms RTT.

 

vSphere administrators now can migrate across vCenter Server systems, enabling migration from a Windows version of vCenter Server to vCenter Server Appliance or vice versa, depending on specific requirements. Previously, this was a difficult task and caused a disruption to virtual machine management. This can now be accomplished seamlessly without losing historical data about the virtual machine.

 

Cross vSwitch vMotion

 

Cross vSwitch vMotion allows you to seamless migrate a virtual machines across different virtual switches while performing a vMotion. This means that you are now longer restricted by the network you created on the vSwitches in order to vMotion a virtual machine.

 

vMotion will work across a mix of switches (standard and distributed). Previously, you could only vMotion from vSS to vSS or within a single vDS. This limitation has been removed.

 

The following Cross vSwitch vMotion migrations are possible:

• vSS to vSS migration.
• vSS to vDS migration.
• vDS to vDS migration (transferring VDS port metadata)
• vDS to VSS is not allowed.

Cross vCenter vMotion

But Cross vSwitch vMotion is not the only vMotion enhancement. vSphere 6 also introduces support for Cross vCenter vMotion. vMotion can now perform the following changes simultaneously.

 

• Change compute (vMotion) – Performs the migration of virtual machines across compute hosts.
• Change storage (Storage vMotion) – Performs the migration of the virtual machine disks across datastores.
• Change network (Cross vSwitch vMotion) – Performs the migration of a VM across different virtual switches.
• Change vCenter (Cross vCenter vMotion) – Performs the migration of the vCenter which manages the VM.

 

All of these types of vMotion are seamless to the guest OS.

 

Like with vSwitch vMotion, Cross vCenter vMotion requires L2 network connectivity since the IP of the VM will not be changed. This functionality builds upon Enhanced vMotion and shared storage is not required. Target support for local (single site), metro (multiple well-connected sites), and cross-continental sites

With vSphere 6 vMotion you can now:

Migrate from a VCSA to a Windows version of vCenter & vice versa.

• Replace/retire vCenter server without distruption.
• Resource pooling across vCenters where additional vCenters were used due to vCenter scalability limits.
• Migrate VMs across local, metro, and continental distances.
• Public/Private cloud environments with several vCenters.

There are several requirements for Cross vCenter vMotion to work:

• Only vCenter 6.0 and greater will be supported. All instances of vCenter prior to version 6.0 will need to be upgraded before this this feature will work. For example, an instance of vCenter 5.5 and 6.0 will not work.
• Both the source and the destination vCenter servers will need to be joined to the same SSO domain if you want to perform the vMotion using the vSphere Web Client. If the vCenter servers are joined to different SSO domains, it’s still possible to perform a Cross vCenter vMotion, but you must use the API.
• You will need at least 250 Mbps of available network bandwidth per vMotion operation.
• Lastly, although not technically required for the vMotion to successfully complete, L2 connectivity is required on the source and destination portgroups. When a Cross vCenter vMotion is performed, a Cross vSwitch vMotion is done as well. The virtual machine portgroups for the VM will need the share an L2 network because the IP will within the guest OS will not be updated.

vSphere 6.0 New Features – Content Library

One of the new feature of vSphere 6 is Content Library . The Content Library provides simple and effective management for VM templates, vApps, ISO images and scripts for vSphere Administrators collectively called “content”.

 

Sometimes we have ISO and other files (needed for VM creation etc) are spread across datastores as multiple administrators are managing vSphere Infrastructure. This can lead to duplication of the contents. To mitigate this issue concept of content library is introduced in vSphere 6.o which allows for a centralized place for storing your contents.

 

Advantage of Content Library

 

The Content Library can be synchronized across sites and vCenter Servers. Sharing consistent templates and files across multiple vCenter Servers in same or different locations brings out consistency, compliance, efficiency and automation in deploying workloads at scale.

 

Following are some of the features of the content library:

 

• Store and manage content - Once central location to manage all content as VM templates, vApps, ISO’s, scripts etc. This release will have a maximum on 10 libraries and 250 items per library and it is a build-in feature in the vCenter Server. Not a plug-in that you will have to install separately.
• Share content – Once the content is published on one vCenter Server, you can subscribe to the content from other vCenter Servers. This looks similar to the catalog option in the vCloud Director.
• Templates – The VM’s will be stored as OVF packages rather than templates. This will affect the template creation process. If you want to make changes to a certain OFV template in the Content Library you have to create a VM out of it first, make the changes and then export it back to an OVF template and into the library.
• Network – The port for communication for the Content Library will be 443 and there is an option to limit the sync bandwidth.
• Storage – The Content Library can be stored on datastores, NFS, CFIS, local disks etc. as long as the path to the library is accessible locally from the vCenter Server and the vCenter Server has read/write permission

 

Creating a Content Library

 

 

Selecting Storage for the Content Library

 

Deploying a Virtual Machine to a Content Library

You can clone virtual machines or virtual machine templates to templates in the content library and use them later to provision virtual machines on a virtual data center, a data center, a cluster, or a host.

 

Publishing a Content Library for External Use

 

You can publish a content library for external use and add password protection by editing the content library settings:

Users access the library through the subscription URL that is system generated.

VCP6-DCV Certification Now Available

VMware announced the new roadmap of version 6 certifications, and mentioned that there would be migration paths for those who held certifications on the previous version. Here is below migration paths.

• VCP6: Data Center Virtualization Exam (exam number: 2V0-621) 
• VCP6: Data Center Virtualization Delta Exam (exam number: 2V0-621D)
• VCP6: Desktop & Mobility Exam (exam number: 2V0-651) 
• VCP6: Cloud Management and Automation Exam (exam number: 2V0-631) 
• VCP6: Network Virtualization Exam (exam number: 2V0-641) 

Source from : VMware

VMware vSphere 5.x and 6.x Configuration Maximums

Here updated limits and maximums series details about vmware vsphere 6.

Please find the table summaries below.

Compute

Virtual Machine Maximums

vSphere Configuration Item	v5.0	v5.1	v5.5	v6.0
Virtual CPUs per virtual machine (Virtual SMP)	32	64	64	128

Memory

Virtual Machine Maximums

vSphere Configuration Item	v5.0	v5.1	v5.5	v6.0
RAM per virtual machine	1TB	1TB	1TB	4TB
Virtual machine swap file size	1TB	1TB	1TB	4TB

Virtual Peripheral Ports

Virtual Machine Maximums

vSphere Configuration Item	v5.0	v5.1	v5.5	v6.0
Serial Ports per virtual machine	4	4	4	32

Storage Virtual Adapters and Devices

Virtual Machine Maximums

vSphere Configuration Item	v5.0	v5.1	v5.5	v6.0
Virtual disk size	2TB minus 512 bytes	2TB minus 512 bytes	62TB	62TB
Virtual SATA adapters per virtual machine	-	-	4	4
Virtual SATA devices per virtual SATA adapter	-	-	30	30

Graphics video device

Virtual Machine Maximums

vSphere Configuration Item	v5.0	v5.1	v5.5	v6.0
Video memory per virtual machine	128MB	512MB	512MB	512MB

Host CPU maximums

ESXi Host Maximums

vSphere Configuration Item	v5.0	v5.1	v5.5	v6.0
Logical CPUs per host	160	160	320	480
NUMA Nodes per host	8	8	16	16

Virtual machine maximums

ESXi Host Maximums

vSphere Configuration Item	v5.0	v5.1	v5.5	v6.0
Virtual machines per host	512	512	512	1024
Virtual CPUs per host	2048	2048	4096	4096
Virtual CPUs per core	25	25	32	32

Fault Tolerance maximums

ESXi Host Maximums

vSphere Configuration Item	v5.0	v5.1	v5.5	v6.0
Virtual CPUs per virtual machine	1	1	1	4
Virtual CPU per host	-	-	-	8

Memory Maximums

ESXi Host Maximums

vSphere Configuration Item	v5.0	v5.1	v5.5	v6.0
RAM per host	2TB	2TB	4TB	6TB / 12TB on specific OEM certified platform

Fibre Channel

ESXi Host Maximums

vSphere Configuration Item	v5.0	v5.1	v5.5	v6.0
LUN ID	255	255	255	1023

VMFS5

ESXi Host Maximums

vSphere Configuration Item	v5.0	v5.1	v5.5	v6.0
Raw Device Mapping size (virtual compatibility)	2TB minus 512 bytes	2TB minus 512 bytes	62TB	62TB
Raw Device Mapping size (physical compatibility)	2TB minus 512 bytes	2TB minus 512 bytes	64TB	64TB
File size	2TB minus 512 bytes	2TB minus 512 bytes	62TB	62TB

Physical NICs

Networking Maximums

vSphere Configuration Item	v5.0	v5.1	v5.5	v6.0
e1000 1Gb Ethernet ports (Intel PCI‐x)	32	32	-	-
tg3 1Gb Ethernet ports (Broadcom)	32	32	32	16 (with NetQueue enabled) 32 (with NetQueue disabled)
bnx2 1Gb Ethernet ports (Qlogic)	-	-	-	16
forcedeth 1Gb Ethernet ports (NVIDIA)	2	2	-	-
elxnet 10Gb Ethernet Ports (Emulex)	-	-	-	8
ixgbe 10Gb Ethernet Ports (Intel)	-	-	8	16
bnx2x 10Gb Ethernet Ports (Qlogic)	-	-	-	8
Combination of 10Gb and 1Gb Ethernet ports	6x 10Gb and 4x 1Gb ports	6x 10Gb and 4x 1Gb ports	8x 10Gb and 4x 1Gb ports	16x 10Gb and 4x 1Gb ports

VMDirectPath limits

Networking Maximums

vSphere Configuration Item	v5.0	v5.1	v5.5	v6.0
SR-IOV number of virtual functions	-	-	64	1024
SR-IOV number of 10G pNICs	-	4	8	8

vSphere Standard and Distributed Switch

Networking Maximums

vSphere Configuration Item	v5.0	v5.1	v5.5	v6.0
Maximum active ports per host (VDS and VSS)	1016	1050	1016	1016
Port groups per standard switch	256	256	512	512
Static/Dynamic port groups per distributed switch	-	-	6500	10,000
Distributed virtual network switch ports per vCenter	30,000	60,000	60,000	60,000
Static/dynamic port groups per vCenter	5000	10,000	10,000	10,000
Ephemeral port groups per vCenter	256	256	1016	1016
Distributed switches per vCenter	32	128	128	128
Distributed switches per host	-	-	16	16
VSS portgroups per host	-	-	1000	1000
LACP - LAGs per host	-	-	64	64
LACP - uplink ports per LAG (Team)	-	4	32	32
Hosts per VDS	350	500	1000	1000
NIOC resource pools per vDS	-	-	64	64
Link aggregation groups per vDS	-	1	64	64

Cluster (all clusters including HA and DRS)

Cluster and Resource Pool Maximums

vSphere Configuration Item	v5.0	v5.1	v5.5	v6.0
Hosts per cluster	32	32	32	64
Virtual machines per cluster	3000	4000	4000	8000
Virtual machines per host	512	512	512	1024
Powered‐on virtual machine config files per datastore in an HA cluster.	-	2048	2048	2048
FT virtual machines per cluster	-	-	-	98
FT virtual machines vCPU per Cluster	-	-	-	256

Resource Pool

Cluster and Resource Pool Maximums

vSphere Configuration Item	v5.0	v5.1	v5.5	v6.0
Children per resource pool	1024	1024	1024	1100

vCenter Server Scalability

vCenter Server Maximums

vSphere Configuration Item	v5.0	v5.1	v5.5	v6.0
Hosts in linked vCenter Servers	3000	3000	3000	4000
Concurrent vSphere Client connections to vCenter Server	100	100	100	-

vCenter Server Appliance

vCenter Server Maximums

vSphere Configuration Item	v5.0	v5.1	v5.5	v6.0
Hosts (with embedded vPostgres database)	-	-	100	1000
Virtual machines (with embedded vPostgres database)	-	-	3000	15,000
Virtual machines (with Oracle database)	-	-	10,000	15,000

vCenter Server Windows embedded/packaged vPostgres

vCenter Server Maximums

vSphere Configuration Item	v5.0	v5.1	v5.5	v6.0
Hosts (with embedded vPostgres database)	-	-	-	20
Virtual machines (with embedded vPostgres database)	-	-	-	200

Content Library

vCenter Server Maximums

vSphere Configuration Item	v5.0	v5.1	v5.5	v6.0
Total CL items per VC (across all libraries)	-	-	-	200
Total number of libraries per VC	-	-	-	20
Total items per library	-	-	-	200
Maximum number of subscribers per library	-	-	-	5

Host Profile

vCenter Server Maximums

vSphere Configuration Item	v5.0	v5.1	v5.5	v6.0
Hosts	-	-	-	21
Powered On virtual machines	-	-	-	100
Datastores	-	-	-	120
Profile Created	-	-	-	1200
Profile Attached	-	-	-	1000

Single Sign On

vCenter Server Maximums

vSphere Configuration Item	v5.0	v5.1	v5.5	v6.0
Authentications per second (average)	-	30	-	-

Domain/Replication

Platform Service Controller maximums

vSphere Configuration Item	v5.0	v5.1	v5.5	v6.0
Maximum PSCs per vSphere Domain	-	-	-	8
Maximum PSCs per site, behind a load balancer	-	-	-	4
Maximum objects within a vSphere Domain (Users and Groups)	-	-	-	1,000,000
Maximum tolerance for time skew between PSC nodes	-	-	-	5 minutes

Identity Source

Platform Service Controller maximums

vSphere Configuration Item	v5.0	v5.1	v5.5	v6.0
Maximum Active Directory or OpenLDAP Groups per User for best performance	-	-	-	1015

Enhanced Linked Mode/Lookup Service

Platform Service Controller maximums

vSphere Configuration Item	v5.0	v5.1	v5.5	v6.0
Maximum number of VMware Solutions connected to a single PSC per User for best performance	-	-	-	4
Maximum number of VMware Solutions in a vSphere Domain	-	-	-	10

VMCA/Certificate

Platform Service Controller maximums

vSphere Configuration Item	v5.0	v5.1	v5.5	v6.0
Maximum number of subordinate Certificate Authority servers in the chain within VMware Certificate Authority	-	-	-	6
Maximum cryptographic hash used for PSC Node certificate Domain	-	-	-	1
Maximum RSA Public Key length used for PSC Node certificate	-	-	-	16,384

VMware vCenter Update Manager

vCenter Update Manager Maximums

vSphere Configuration Item	v5.0	v5.1	v5.5	v6.0
ESXi host upgrade per cluster	-	-	1	-

VMware vCenter Orchestrator

vCenter Orchestrator Maximums

vSphere Configuration Item	v5.0	v5.1	v5.5	v6.0
Connected vCenter Server systems	10	20	20	20
Connected ESXi instances	100	1280	1280	1280
Connected virtual machines	15,000	35,000	35,000	35,000
Concurrent running workflows	150	300	300	300

Storage DRS

Storage DRS Maximums

vSphere Configuration Item	v5.0	v5.1	v5.5	v6.0
Datastores per datastore cluster	32	32	32	64

Virtual SAN ESXi host

Virtual SAN Maximums

vSphere Configuration Item	v5.0	v5.1	v5.5	v6.0
Virtual SAN disk groups per host	-	-	-	5
Magnetic disks per disk group	-	-	-	7
SSD disks per disk group	-	-	-	1
Spinning disks in all diskgroups per host	-	-	-	35
Components per Virtual SAN host	-	-	-	9000
Cache tier maximum devices per host	-	-	-	5
Capacity tier maximum devices per diskgroup	-	-	-	7
Capacity tier maximum devices	-	-	-	35

Virtual SAN Cluster

Virtual SAN Maximums

vSphere Configuration Item	v5.0	v5.1	v5.5	v6.0
Number of Virtual SAN hosts in a cluster	-	-	-	64
Number of datastores per cluster	-	-	-	1

Virtual SAN virtual machines

Virtual SAN Maximums

vSphere Configuration Item	v5.0	v5.1	v5.5	v6.0
Virtual machines per host	-	-	-	200
Virtual machines per cluster	-	-	-	6400
Virtual machine virtual disk size	-	-	-	62TB
Disk stripes per object	-	-	-	12
Percentage of flash read cache reservation	-	-	-	100
Failure to tolerate	-	-	-	3 for VM virtual disk size <= 16 TB 1 for VM virtual disk size > 16 TB
Percentage of object space reservation	-	-	-	100
Virtual SAN networks/physical network fabrics	-	-	-	2

Virtual Volumes

Virtual Volumes Maximums

vSphere Configuration Item	v5.0	v5.1	v5.5	v6.0
Data Virtual Volume Size	-	-	-	62TB
Number of Virtual Volumes bound to a host	-	-	-	64,000
Number of PEs per host	-	-	-	256
Storage Container size	-	-	-	2^64
Storage Container per host	-	-	-	256
Maximum outstanding PE I/O operations	-	-	-	128 configurable up to 4096
Configured VPs per host	-	-	-	128
Maximum configured VVol managed storage arrays per host	-	-	-	64

Network I/O Control (NIOC)

Network I/O Control (NIOC) Maximums

vSphere Configuration Item	v5.0	v5.1	v5.5	v6.0
Number of resource pools	-	-	-	10,000
Number of uplinks per vds	-	-	-	32
Number of uplinks per host	-	-	-	32
Number of vNIC per host	-	-	-	5120
Max pNIC bandwidth	-	-	-	Approximately 10 Gbits/sec for 10G pNIC Approximately 1 Gbits/sec for 1G pNIC

vCloud Director Maximums

vCloud Director Maximums

vSphere Configuration Item	v5.0	v5.1	v5.5	v6.0
Virtual machine count	20000	30000	50000	-
Powered‐On virtual machine count	10000	10000	30000	-
Virtual machines per vApp	64	128	128	-
vApps per organization	500	3000	5000	-
Number of networks	7500	10000	10000	-
Number of networks	7500	7500	10000	-
Hosts	2000	2000	2000	-
vCenter Servers	25	25	20	-
Catalogs	1000	10000	10000	-
Users	10000	10000	25000	-