VMware vCenter™ Infrastructure Navigator is an application awareness plug-in to vCenter Server, and provides continuous dependency mapping of applications. Infrastructure Navigator offers application context to the virtual infrastructure administrators to monitor and manage the virtual infrastructure inventory objects and actions. Administrators can use Infrastructure Navigator to understand the impact of the change on the virtual environment in their application infrastructure. Infrastructure Navigator helps virtual infrastructure administrators perform the following tasks:

• Make accurate first-level triage to help either eliminate the problem or associate the problem with the virtual infrastructure when business service users report problems.
• Assess change impact, manage, and communicate virtual infrastructure issues for critical applications.
• Understand the application and business impact of changes to the virtual infrastructure on applications.

The Open Source Licenses (OSL) file for the virtual appliance is available at /root/open_source_licenses.txt. You can retrieve the file by running the scp root@<appliance IP>:open_source_licenses.txt command.

Infrastructure Navigator is supported on vCenter Server 5.0 with the vSphere Web Client. The supported ESX versions include ESX/ESXi 3.5 (build 425420), ESX/ESXi 4.0 (build 398348), ESX/ESXi 4.1 (build 433742), and all builds of ESXi 5.x.

Features

This section describes the key features for the Infrastructure Navigator 1.0.0 release.

Simplifies and automates the deployment and the discovery process and keeps manages Application Component Knowledge Base (KB) current

• Eliminates physical switch spanning or credential based discovery.
• Discovers and maps the application components and dependencies using KBs and presents this knowledge through maps or search for relevant use cases.

Provide Infrastructure Navigator data for vCenter Server and related solutions

• Ensures that the application and dependency data is available to the rest of the vCenter Server entities and its various solutions through the vCenter extensibility APIs.
• Supports SRM integration to set up more focused and accurate site recovery and backup plans.

VMware vCenter Operations Manager is an automated operations management solution that provides integrated performance, capacity, and configuration management for highly virtualized and cloud infrastructure. Deep VMware vSphere integration provides the most comprehensive management of VMware environments. VMware vCenter Operations Manager is purpose-built for VMware administrators to more effectively manage the performance of their VMware environments as they move to the private cloud.

Key Benefits

• Actionable intelligence to automate manual operations processes
• Visibility across infrastructure and applications for rapid problem resolution
• Proactively ensures optimal resource utilization and virtual and cloud infrastructure performance

To enable Network I/O Control we need to have a DvS in place.  If we select the distributed switch and then select the Resource Application tab on the right, this gives us the “properties” option on the far right.  By selecting the Properties option, you can enable Network I/O Control on the DvS.  Once enabled you can see all of the System network resource pools.  There is one at the bottom of the list labeled “vSphere Replication (VR) Traffic”.  Selecting it and then clicking the “Edit Settings” link just below it opens up the settings window.

From here, you can edit the adapter shares.  The shares are to balance the bandwidth so that network flows can use the bandwidth thats available from a given dvuplink.  The shares are for a given dvUplink.

Alternatively, you can uncheck the Unlimited checkbox and set a host limit.  Keep in mind that this is Megabits per sec, not MegaBytes.  This is also the limit of the combined set of dvUplinks on a given host.

Lastly, a QOS priority tag can be used.  The traffic will have a 802.1p tag applied to it.  The IEEE does not standardize or mandate the use of the priority tag applied to the packets but the switches should treat higher tags with higher priority.  The choices are None, 1-7.

While not the granular controls that we may wish for, say individual bandwidth controls on a per VM or per-site replication limits, these settings and options are a start.  Hopefully in the future in vSphere Replication v2 we will have more granular controls for bandwidth throttling but until then, these are what we can use.  Happy computing.

The vCenter Chargeback Manager 2.0 provides various new features.

• Automatic Report Scheduler
  In vCenter Chargeback Manager, you can define automatic report schedulers. These schedulers create report schedules for hierarchies and entities that match the criteria specified in the automatic report scheduler. The automatic report scheduler scans all the hierarchies and creates report schedules for the hierarchies and entities that match the specified criteria.
• Charge thin and thick provisioned virtual machines differently
  In this release, you can charge thin provisioned disks and thick provisioned disks differently. By default, thin provisioned disks are charged for the actual usage of the disk. You can override this behavior to charge the thin provisioned disks as thick provisioned in your billing policy.
• Cost variance and cost optimization
  vCenter Chargeback Manager provides a cost variance graph in the report dashboard that lets you analyze the day-to-day change in cost for a selected hierarchy or entity. The graph shows cost data for the last 30 days and that projected for the next 3 months in sets of 30 days each. vCenter Chargeback Manager lists different cost optimization opportunities, such as oversized virtual machines, undersized virtual machines, idle virtual machines, and powered off virtual machines. Cost variance and cost optimization is displayed only for the vCenter Servers that are integrated with VMware vCenter Operations.
• Showback Report
  A showback report lets you analyze how the cost is distributed among the entities based on a specified distribution policy. It is a configurable report that does not include any costs when it is generated. You can specify the total cost, fixed cost, and resource weight in the generated report to obtain the cost for each entity and for each resource per entity. The cost per entity is calculated based on the distribution policy that you select when generating the show back report.
• Apply fixed cost based on virtual machine state
  In vCenter Chargeback Manager, you can now define fixed costs that will be applied on an entity only for the duration for which the virtual machine in the entity is powered on.
• Tier-based storage costing
  vCenter Chargeback Manager lets you define storage tiers and configure cost on the tiers. All the datastores under a tier will be charged uniformly as per the cost configuration settings on the tier. You can also include VM storage profiles in a tier. The storage profiles defined in vSphere are synchronized and the datastores are automatically grouped according to their storage profiles. The cost configuration defined on a profile is applied on all the datastores that match the storage profile. Similarly, the cost configuration defined on a tier is applied to all the datastores or storage profiles added to the tier.
• Support for raw device mapping
  vCenter Chargeback Manager accounts for usage of hard disks that use raw device mapping. The corresponding cost and usage data is reported for the virtual machines that have disks using raw device mapping.
• Complete support for vSphere 5.0 and vCloud Director 1.5
  vCenter Chargeback Manager 2.0 supports the new features introduced in vSphere 5.0, such as VM storage profiles, and that introduced in vCloud Director 1.5, such as support for an SQL Server database.
• Partial support for IPv6
  In this release, vCenter Chargeback Manager supports IPv6 over IPv4 on an experimental basis. You can provide URLs with IPv6 IP addresses when connecting to vCenter Servers, LDAP Servers, vCenter Chargeback Manager databases, and vCenter Server databases. Ensure that the IPv6 IP address is enclosed in square brackets [ ] in the URL as per the standard convention.
• VM Instance Cost support for all hierarchies in vCenter Chargeback Manager
  In vCenter Chargeback Manager 2.0, you can define fixed cost pricing matrices for virtual machines based on vCPU count and memory bundles. Unlike earlier releases, this functionality is now available for all the hierarchies created in vCenter Chargeback Manager.
• Support for burstable billing or 95th percentile billing for the external network traffic in vCloud Director
  You can now calculate the cost for external network traffic in your vCloud Director setup based on the 95th percentile transfer rate. Starting with this release, vCenter Chargeback Manager introduces the external network transmit rate and external network receive rate resources and the Burstable Utilization resource attribute for these resources. You can define a billing policy that has these resource-attribute pair in the expression to calculate the cost based on the 95th percentile transfer rate. vCenter Chargeback Manager calculate the 95th percentile value based on the daily samples. That is, vShield Manager Data Collector runs a job that accounts for the samples for the last 24 hours and computes the 95th percentile value based on these samples.
• Support for overage charging for org vDCs in the Allocation Pool model of vCloud Director
  In this release, vCenter Chargeback Manager provides the VMware Cloud Director apply overage charge on Allocation Pool vDC property for the Cloud Director Data Collector. This property must be set to true (default value is false) to account for the resource usage over and above the guaranteed reservation in vCloud Director. This is applicable only for CPU and memory. Also, you must use the VMware Cloud Director Overage Allocation Pool Cost Model to account for resource overage. You must, however, modify the cost model to define the base rate and overage rate for the resources.
• New cost models and billing policies for vCloud Director
  This release of vCenter Chargeback Manager introduces two new cost models and billing policies that are made available when you install the Cloud Director Data Collector. 
  • VMware Cloud Director Actual Usage Cost Model: This cost model uses the new VMware Cloud Director Billing Policy – Actual Usage. This billing policy lets you calculate cost based on actual resource usage for all resources except count of networks, enabled IPSec VPN tunnel count, and NAT, DHCP, and firewall services. For these resources the allocation values defined in vCloud Director is used.
  • VMware Cloud Director Overage Allocation Pool Cost Model: This cost model uses the new VMware Cloud Director Billing Policy – Overage Allocation Pool. Only for this beta release, the billing policy calculates the overage cost for CPU based on actual usage and that for memory based on allocation. For external network transmit and external network receive the actual usage values are used and for all other resources the allocation values are used.

What’s New in version 1.2

• Optimized for VMware View 5 with improved performance
• Support for iOS 5 including Airplay
• Presentation Mode for use with external display and Airplay
• Embedded RSA soft token simplifies login to desktop
• Background tasking to move between Windows and iOS apps
• Updated look and feel
• Integrated online help
• Buffered text input for multibyte text entry
• Now in French, German, Japanese, Korean, and Simplified Chinese
• Bug fixes

New in v1.2 (see notes below):

• Migrate virtual machines without downtime using vMotion.  This feature is available via Host & VM action menus.  Virtual machines can also be two-finger flicked/dragged from the Host detail view to enter vMotion mode
• Ability to email vMotion validation error details to others
• View task progress reporting on VM cards
• Ability to refresh vCenter host list
• Support of ESX 3.5
• Support for vSphere 5.0

Release Notes:

• This version requires vCMA 1.2, available at: http://labs.vmware.com/flings/vcma
• Min iOS version: 4.0

Here lies the problem and the reason for my post.  Remember that the licensing is sold in packs of 25 VMs so we can add SRM capacity in blocks of 25.  When we cross that 75 to 100 in capacity required, we need to upgrade our existing Standard Licenses to Enterprise and purchase a 25-pack of Enterprise to protect the additional VMs.    In list price terms, the 76th VM will cost $49,501.  That price includes 3 of the 25-VM Upgrade packs for SRM Standard to Enterprise (to upgrade the existing licensing for that site), a 25-VM Pack of SRM Enterprise and 4 x 1-year SnS for SRM Enterprise (the upgrade packs require SnS at purchase).

I created a chart showing List Prices and the acquisition cost and total investment in SRM.  From left to right shows the number of licensed VMs protected.  This chart assumes you start purchasing SRM Standard for a site with 75 or less VMs protected and then grow the site to larger than 75 VMs protected.

You can see from the greenish line that the total cost takes a significant jump from the 75-to-100 number of VMs protected.  Please keep in mind that these are list prices and assume that you are going to start with Standard Edition.

I was curious to know how this model would compare if we purchased SRM Enterprise licenses from the start.  I created this graph below for comparison.

You can see the blue 25-VM pack acquisition costs are a constant and predictable for each 25-VM pack.  The red total cost line is also a constant rate.   You’ll also notice that at 100 VMs and on, total costs are lower when you use Enterprise from the start.

There are a couple important observations that I have made from this analysis.  First, Standard Edition is a great way for customers to get into SRM at a much lower price point.  Please understand the risks if there is potential for that site to grow large enough to protect more than 75 VMs from it.

Second, and most important, this article is not meant as a criticism of VMware licensing practices (I’ll let others write those).  This article is meant to inform the customers:  If you need to protect a site with SRM and you think that you will eventually grow that site past the 75-protected-VM mark, you may want to consider purchasing SRM Enterprise now to balance out your costs and save some money in the end.  I really do not want to have to explain this licensing to you when started by purchasing SRM Standard Edition and now you need to protect the 76th VM.

Good luck and good computing.

VMware vCenter Site Recovery Manager 5.0 enhances your ability to build, manage and execute reliable disaster recovery plans for your virtual environment. With the release of version 5.0, VMware has expanded the capabilities of Site Recovery Manager to provide unprecedented levels of protection. New use cases have been made possible through the addition of the following capabilities:

• vSphere Replication. When used in conjunction with VMware vSphere 5.0, Site Recovery Manager 5.0 introduces a new capability to utilize the vSphere 5.0 host to perform replication of powered-on virtual machines over the network to another vSphere 5.0 host, without the requirement for storage array-based replication. As virtual machines change with use, the changed blocks are replicated to a shadow copy of the virtual machine resident at the recovery site, in accordance with a Recovery Point Objective set as a property of the virtual machine itself.
• Planned Migration. A new workflow designed to deliver migration while minimizing the risk of data loss. Planned migration will stop the workflow from continuing if an error is encountered, providing an opportunity to fix the problem, ensuring that systems are properly quiescent and that all data changes have been completely replicated.
• Automated Re-Protection. Re-protection is a new extension to recovery plans for use only with array-based replication. Automated re-protect enables the environment at the recovery site to establish replication and protection of the environment back to the original protected site through a single click.
• Automated Failback. Automated failback returns the entire environment to the originally protected primary site. This can only happen after re-protection has ensured that data replication and synchronization have been established to the original primary site. Failback will run the same workflow that was used to migrate the environment to the protected site, ensuring that the critical systems encapsulated by the recovery plan are returned to their original environment. Automated failback, like re-protection, is only available for use with array-based replication protected virtual machines.
• Enhanced Dependency Definition. This includes the addition of more (5) priority groups, and the ability to set virtual machine dependencies within a priority group. Virtual machine dependencies can be defined to ensure that required systems are available before dependent virtual machines are powered on. This enables highly organized workflow control, ensuring that required services are available before dependent virtual machines are powered on.

VMware View 5.0 includes the following new features:

• PCoIP WAN performance optimization – Improves PCoIP protocol performance in low-bandwidth WAN environments. Users who connect to their desktops over an external WAN have enhanced desktop experience.
• Support for 3D graphics on vSphere 5.0 – This feature provides View desktops with vGPU graphics enablement available on vSphere 5.0 platforms. View users can take advantage of desktop graphics enhancements provided by AERO (such as peek, shake, and Flip 3D) and the 3D capabilities of Windows Office 2010 (such as picture editing, slide transitions and animations, presentation-to-video conversion, video embedding, editing, and 3D rotations).
• View Persona Management – The View Persona Management feature manages user profiles in a secure and centralized environment. (User profiles include user data and settings, application data and settings, and Windows registry settings configured by user applications.) View Persona Management allows IT organizations to simplify and automate the capture and management of a user’s persona while providing a rich user experience. View Persona Management offers the following benefits:
  • Provides a user profile that is independent of the virtual desktop. When a user logs in to any desktop, the same profile appears.
  • Lets you configure and manage personas entirely within View. You do not have to configure Windows roaming profiles.
  • Expands functionality and improves performance compared to Windows roaming profiles.
  • Minimizes login impact by downloading only the files that Windows requires, such as user registry files. Other files are copied to the local desktop when the user or an application opens them from the local profile folder.
  • Copies recent changes in the local profile to a remote profile repository at configurable intervals, typically once every few minutes.
• Updated client certificate checking for View clients – View clients now follow the well-known browser model for handling certificates, displaying errors detected in the certificate presented by View Connection Server, or in the certificate trust chain. Administrators can set the Certificate verification mode group policy to enforce strict certificate checking; if any certificate error occurs, the user cannot connect to View Connection Server. Alternatively, administrators can use the default Warn But Allow mode, which supports self-signed server certificates and lets users connect to View Connection Server with certificates that have expired or are not yet valid. If necessary, administrators can also set a No Security mode that lets users connect without certificate checking.
• Support for vSphere 5.0
• Support for hardware v8 – Remote View desktops can be hardware v8 virtual machines. Hardware v8 is not supported for desktops that run in local mode.
• Removed support for HP RGS display protocol
• Localization support for Korean. – View Client and the documentation, online help, and release notes are available in Korean.

Note: The version of View Client for Mac that was bundled with View 4.6 is also bundled with the View 5.0 release. This is the latest View Client for Mac and is compatible with View 4.6 and View 5.0.

As always, here’s the what’s new section from the release notes:

With this release, the VMware virtual datacenter operating system continues to transform x86 IT infrastructure into the most efficient, shared, on-demand utility, with built-in availability, scalability, and security services for all applications and simple, proactive automated management. The new and enhanced features in vSphere 5.0 are listed below.

Platform Enhancements
Storage
Networking
VMware vCenter Server
Availability
Partner Ecosystem
Platform Enhancements

Convergence. vSphere 5.0 is the first vSphere release built exclusively on the vSphere ESXi 5.0 hypervisor architecture as the host platform. The ESX hypervisor is no longer included in vSphere. The vSphere 5.0 management platform, vCenter Server 5.0, supports ESXi 5.0 hosts as well as ESX/ESXi 4.x and ESX/ESXi 3.5 hosts.

VMware vSphere Auto Deploy. VMware vSphere Auto Deploy simplifies the task of managing ESXi installation and upgrade for hundreds of machines. New hosts are provisioned based on rules that the administrator defines. Rebuilding a server to a clean slate requires only a reboot. To move between ESXi versions, you create a new rule using the Auto Deploy PowerCLI and perform a test and repair compliance operation.

Unified CLI Framework. The expanded ESXCLI framework offers an extensible command set, including new commands to facilitate on-host troubleshooting and maintenance. The framework allows consistency of authentication, roles, and auditing, using the same methods as other management frameworks such as vCenter Server and PowerCLI. You can use the ESXCLI framework both remotely as part of vSphere CLI and locally on the ESXi Shell (formerly Tech Support Mode).

New virtual machine capabilities. ESXi 5.0 introduces a new generation of virtual hardware with virtual machine hardware version 8, which includes the following new features:
32-way virtual SMP. ESXi 5.0 supports virtual machines with up to 32 virtual CPUs, which lets you run larger CPU-intensive workloads on the VMware ESXi platform.

1TB of virtual machine RAM. You can assign up to 1TB of RAM to ESXi 5.0 virtual machines.

Software support for 3D graphics to run Windows Aero. ESXi 5.0 supports nonhardware accelerated 3D graphics to run Windows Aero and Basic 3D applications in virtual machines.

USB 3.0 device support. ESXi 5.0 features support for USB 3.0 devices in virtual machines with Linux guest operating systems. USB 3.0 devices attached to the client computer running the vSphere Web Client or the vSphere Client can be connected to a virtual machine and accessed in it. USB 3.0 devices connected to the ESXi host are not supported.

UEFI virtual BIOS. Virtual machines running on ESXi 5.0 can boot from and use the Unified Extended Firmware Interface (UEFI).

Graphical User Interface to configure multicore virtual CPUs. You can now configure the number of virtual CPU cores per socket in the Virtual Machine Properties view in the vSphere Web Client and the vSphere client. Previously this feature was only configurable through advanced settings.

Client-connected USB devices. USB devices attached to the client computer running the vSphere Web Client or the vSphere Client can be connected to a virtual machine and accessed within it.

Smart card reader support for virtual machines. Smart card readers attached to the client computer running the vSphere Web Client or the vSphere Client can be connected to one or more virtual machines and accessed in them. The virtual machine remote console, available in the vSphere Web Client and the vSphere Client, supports connecting smart card readers to multiple virtual machines, which can then be used for smart card authentication.

Expanded support for VMware Tools versions. VMware Tools from vSphere 4.x is supported in virtual machines running on vSphere 5.0 hosts. Additionally, the version of VMware Tools supplied with vSphere 5.0 is also compatible with ESX/ESXi 4.x.

Apple Mac OS X Server guest operating system support. VMware vSphere 5.0 adds support for the Apple Mac OS X Server 10.6 (“Snow Leopard”) as a guest operating system. Support is restricted to Apple Xserve model Xserve3,1 systems.

Host UEFI boot support. vSphere 5.0 supports booting ESXi hosts from the Unified Extensible Firmware Interface (UEFI). With UEFI you can boot systems from hard drives, CD/DVD drives, or USB media. Booting over the network requires the legacy BIOS firmware and is not available with UEFI.

Support for up to 512 virtual machines per host. vSphere 5.0 supports up to 512 virtual machines totaling a maximum of 2048 virtual CPUs per host.

Support for larger systems. vSphere 5.0 supports systems with up to 160 logical CPUs and up to 2TB of RAM.

Improved SNMP support. With vSphere 5.0, you can convert CIM indications to SNMP traps. Check with your hardware vendor to see whether their CIM provider supports this functionality. In addition, vSphere 5.0 now supports the Host Resources MIB (RFC 2790) and allows for finer control over the types of traps sent by the SNMP agent.

Memory fault isolation. On supported platforms, ESXi 5.0 detects and quarantines physical memory regions that exhibit frequent correctable errors. This preemptive action reduces the risk of uncorrectable errors that result in VM or host downtime. Should an uncorrectable memory error occur, ESXi 5.0 quarantines the failed memory region and restarts the affected virtual machines. ESXi halts with a purple diagnostic screen only if the memory error affects the hypervisor itself. These enhancements deliver improved VM and host availability.

Image Builder. A new set of PowerCLI cmdlets lets administrators create custom ESXi images that include third-party components required for specialized hardware, such as drivers and CIM providers. You can use Image Builder to create images suitable for different types of deployment, such as ISO-based installation, PXE-based installation, and Auto Deploy.

Host Profiles Enhancements. Using an Answer File, you can configure host-specific settings to use with the common settings in the Host Profile, which removes the need to add host-specific parameters. This feature enables the use of Host Profiles to fully configure a host during an automated deployment. In addition, Host Profiles includes support for an expanded set of configurations, including iSCSI, FCoE, Native Multipathing, Device Claiming and PSP Device Settings, and Kernel Module Settings.

Metro vMotion. Ability to use vMotion to move a running virtual machine when the source and destination ESX hosts are more than 5ms round trip time latency apart. The maximum supported round trip time latency between the two hosts is now 10ms.

Enablement of Trusted Execution Technology (TXT). ESXi 5.0 can be configured to boot with Intel Trusted Execution Technology (TXT). This boot option can protect ESXi in some cases where system binaries are corrupt or were tampered with.

Improvement in scalability. ESXi 5.0 supports up to 160 logical processors.

Storage

Storage DRS. This feature delivers the DRS benefits of resource aggregation, automated initial placement, and bottleneck avoidance to storage. You can group and manage similar datastores as a single load-balanced storage resource called a datastore cluster. Storage DRS makes disk (VMDK) placement and migration recommendations to avoid I/O and space utilization bottlenecks on the datastores in the cluster.

Profile-driven storage. This solution allows you to have greater control and insight into characteristics of your storage resources. It also enables virtual machine storage provisioning to become independent of specific storage available in the environment. You can define virtual machine placement rules in terms of storage characteristics and monitor a virtual machine’s storage placement based on these administrator-defined rules. The solution delivers these benefits by taking advantage of the following items:

Integrating with Storage APIs – Storage Awareness to deliver storage characterization supplied by storage vendors.

Enabling the vSphere administrator to tag storage based on customer-specific descriptions.

Using storage characterizations to create virtual machine placement rules in the form of storage profiles.

Providing easy means to check a virtual machine’s compliance against these rules.

As a result, managing storage usage and choice in vSphere deployments is more efficient and user-friendly.

vStorage APIs – Storage Awareness. A new set of APIs that allows vCenter Server to detect capabilities of a storage device, making it easier to select the appropriate storage disk for virtual machine placement. Storage capabilities, such as RAID level, thin or thick provisioning, replication state, and so on, can now be made visible with vCenter Server.

VMFS5. VMFS5 is a new version of vSphere Virtual Machine File System that offers improved scalability and performance, and provides internationalization support. With VMFS5, you can create a 64TB datastore on a single extent. RDMs in physical compatibility mode with the size larger than 2TB can now be presented to a virtual machine. In addition, on SAN storage hardware that supports vStorage APIs – Array Integration (also known as VAAI), ESXi 5.0 uses the atomic test and set (ATS) locking mechanism for VMFS5 datastores. Using this mechanism can improve performance, although the degree of improvement depends on the underlying storage hardware.

iSCSI UI support. Configure dependent hardware iSCSI and software iSCSI adapters along with the network configurations and port binding in a single dialog box using the vSphere Client. Full SDK access is also available for these configurations.

Storage I/O Control NFS support. vSphere 5.0 extends Storage I/O Control to provide cluster-wide I/O shares and limits for NFS datastores.

Storage APIs – Array Integration: Thin Provisioning. Reclaim blocks of a thin-provisioned LUN when a virtual disk is deleted or migrated. You can also preallocate space on thin-provisioned LUNs and receive advanced warnings and error messages when a datastore on a thin-provisioned LUN starts to fill up. The behavior of a full thin-provisioned disk is also improved. Only virtual machines that are trying to allocate new blocks on a full thin-provisioned datastore are paused. Virtual machines that do not require additional blocks on the thin-provisioned disk continue to run.

Swap to Host Cache. The VMkernel scheduler is modified to allow ESXi swap to extend to local or network SSD devices, which enables memory overcommitment and minimizes performance impact. The VMkernel automatically recognizes and tags SSD devices that are local to ESXi or are on the network.

2TB+ LUN support. vSphere 5.0 provides support for 2TB+ VMFS datastores. Very large VMFS5 datastores with the size of up to 64TB can be created on a singe storage device without additional extents.

Storage vMotion snapshot support. Allows you to use Storage vMotion for a virtual machine in snapshot mode with associated snapshots. You can better manage storage capacity and performance by using flexibility of migrating a virtual machine along with its snapshots to a different datastore. A new Storage vMotion mechanism uses a mirror driver, which synchronizes the source disk to the destination disk, making the migration quicker.

Software FCoE. vSphere 5.0 introduces support for a software Fibre Channel over Ethernet (FCoE) driver. To enable this driver on an ESXi host, you must have a NIC that can support some FCoE offload capabilities.

Snapshot commitments. If a snapshot commit operation fails, this feature enables the vSphere Client to warn users that a consolidate operation is still required on the virtual machine.

Networking

Enhanced Network I/O Control. vSphere 5.0 builds on network I/O control to allow user-defined network resource pools, enabling multitenancy deployment, and to bridge virtual and physical infrastructure QoS with per resource pool 802.1 tagging.

vSphere Distributed Switch Improvements. vSphere 5.0 provides a deeper view into virtual machine traffic through Netflow and enhances monitoring and troubleshooting capabilities through SPAN and LLDP.

ESXi Firewall. The ESXi 5.0 management interface is protected by a service-oriented and stateless firewall, which you can configure using the vSphere Client or at the command line with esxcli interfaces. A new firewall engine eliminates the use of iptables and rule sets define port rules for each service. For remote hosts, you can specify the IP addresses or range of IP addresses that are allowed to access each service.

VMware vCenter Server

vSphere Web Client. A new browser-based user interface that is supported across Linux and Windows platforms. In the 5.0 release, the vSphere Web Client is a replacement for the Web Access product. The client is suitable for all console and virtual machine use cases, allowing administrators to manage their environments.

vCenter Server Appliance. A vCenter Server implementation running on a preconfigured virtual appliance. This appliance significantly reduces the time required to deploy vCenter Server and associated services and provides a low-cost alternative to the traditional Windows-based vCenter Server.

Inventory Extensibility. VMware customers and partners can extend vCenter Server in multiple ways, including the inventory, graphical user interface, and agents. vCenter Server includes a manager to monitor the extensions. By deploying extensions created by VMware partners, you can use vCenter Server as a unified console to manage your virtualized datacenter.

Enhanced logging support. All log messages are now generated by syslog, and messages can now be logged on either local or one or more remote log servers. A given server can log messages from more than one host. Log messages can be remotely logged using either the Secure Sockets Layer (SSL) or TCP connections. The vSphere syslog listener is available as an optional plug-in to vCenter on Windows. In the vCenter Virtual Appliance (VCVA), logging is accomplished using the native syslog-ng facility. With vSphere 5.0, log messages from different sources can be configured to go into different logs for more convenience. Configuration of message logging can also be accomplished using ESXCLI in addition to the vSphere Client.

Availability

vSphere HA. vSphere High Availability is now a cloud-optimized availability platform. Enhancements such as the elimination of the primary and secondary roles and removal of the dependence on DNS make configuration easier. New features, such as the ability to use shared storage as a backup communication channel ensure higher reliability of host failure detection.

vSphere Data Recovery 2.0. VMware increases the speed and reliability of backups expands with the release of Data Recovery 2.0. This release improves integration with vCenter and provides new manageability features including:

Automated generation and emailing of backup job reports.

Improved backup, integrity check, and reclaim operation performance.

Increased resiliency against transient network failures provides improved CIFS support.

Increased flexibility to schedule, pause, and cancel integrity check operations.

Partner Ecosystem

Expanded List of Supported Processors. The list of supported processors has been expanded for ESXi 5.0. To determine which processors are compatible with this release, use the Hardware Compatibility Guide. Among the supported processors are the the Intel Xeon E7-2800, E7-4800, and E7-8800 processor series, code-named Westmere-EX, and the Intel Xeon E3-1200 and i3-2100 processor series, code-named Sandy Bridge.

Support for Multi-queue Storage Adapters. The vSphere storage stack is enhanced to discover multi-queue capabilities of adapters and distribute the incoming I/O on these queues based on CPU affinity. This results in reduced CPU cost per I/O.

• vSphere Replication – The biggest feature add.  An additional replication option which allows you to replicate your VMs without having the storage perform the replication.  Even allows you to replicate to/from local storage on the ESXi hosts.  There are some important limits to vSphere Replication.  It’s not for everything/everyone but it does do quite a bit for the first release.
  • Requires vSphere 5
  • Managed from the vSphere client directly
  • ISOs and Floppys are not replicated
  • Powered off/Suspended VMs are not replicated
  • Non-critical files are not replicated (swap files, dumps, logs, etc.)
  • VMs can have snapshots on the protected side but they are automatically collapsed on the recovery side
  • Physical RDMs not supported (but virtual RDMs are)
  • Fault Tolerant VMs, Linked Clones and VM Templates are not supported
  • Automated Failback of vSphere Replicated VMs is not supported in SRM 5.0
  • Requires VM Hardware version 7 or 8 (required for Change Block Tracking)
  • Supports up to 500 VMs
  • Asynchronous only
  • Minimum replication frequency is every 15 minutes, max is every 24 hours
  • Initial copy can be seeded by sneaker net (taking the initial on a portable HD and importing at the destination, i.e. does not need to seed the initial copy over the wire)
  • File-level consistency (except for planned migration – see below) quiesces OS file system before sending changed blocks to the DR site (does not quiesce applications)
  • Included in both Standard and Enterprise Editions of SRM
  • vSphere Replication is not available outside SRM5
• Scalability Improvements
  • 1000 Total Protected VMs (Same as SRM4.1)
  • 500 Protected VMs in a single protection group (same as SRM v4.1)
  • 250 Protection Groups (Up from 150 in v4.1)
  • 30 Simultaneous running recovery plans (Up from 3 in v4.1 – this is the biggest improvement in scalability)
• Planned Migration – This is a big feature add.  This is another option when you are going failover.  In 4.1 the only option was to start up the VMs from the last good replication and go.  This option now allow you to migrate when there is an impending disaster and the protected side is still up.  Planned migration will shut down the VMs on the protected side then initiate a replication of the storage frames (or vSphere Replication) to get the last drop of changed data to the recovery side before powering on the VMs and bringing them up.  One extremely important advantage to this method: the VMs are always in a application-consistent state when they come up in DR.  (Absolutely love this feature)
• Failback – the single most-requested feature in SRM4.  Once a failover occurs, the admin clicks the “Reprotect” link to reset the recovery plan for failback and reverse replication.  Once completed, the recovery plan can be tested or run in the reverse direction and recovery the VMs to the origional protected site.  (This is outstanding for enterprises that are required to do a true failover for DR testing.
• User Interface improvements – Slightly different look and feel.
  • both sides are visible without vCenter linked mode
  • IP changes for VMs during recovery can now be entered in the GUI (thank you VMware!)
  • Placeholder VMs at the DR side now have a unique icon (with a thunderbolt thru it) to identify them easily in the DR vCenter.
  • Reports now include the user ID that initiated the Failover or DR test.
  • Reports now include more information about the storage steps (including the device friendly names)
• IPv6 Support – Ipv6 is now supported for all links.
• IP Customization performance increase – big performance improvement in the actual IP conversion in the VM
• In guest callouts – now you can run a script inside the VM, run a script on the SRM server or insert a breakpoint to post a message (these also now have maximum timeouts as an option) during the recovery plans
• New APIs on both the Protected and Recovery Sides – new commands for 3^rd party integration (note these are SOAP based and not PowerShell or PowerCLI)
• Dependency Improvements – There are now 5 priority groups for each recovery plan.  Each priority group has to finish completely before the recovery plan will start with the next group.  Within a single priority group, you can also set dependencies (similar to how Windows Services set dependencies) so that a particular VM will not recover before it’s dependencies have recovered (note-this is within a single priority group and cannot span priority groups.)
• Licensing – There are now two editions of SRM, Standard and Enterprise.  Both are feature identical.  Standard is for sites up to 75 VMs and Enterprise is for sites up to 1000 VMs (the technical limit).  All existing customers who maintain support will get SRM Enterprise when they go to SRM5.  SRM Standard is a new offering for SMBs and Remote Offices.  When customers need to grow beyond 75 VMs at a site, they can upgrade their existing VMs to SRM Enterprise and then continue buying SRM5 Enterprise VM-Packs.  Licensing still sold in packs of 25 VMs.  Only need to purchase for the VMs that you are going to protect.

Go into your vCenter (if you have more than one, you will need to do this for each.)  Go into the “Hosts and Clusters” view.  On the left pane, select the vCenter Server itself.  On the right pane, select the “Virtual Machines” tab.  You can optionally click the “State” field title to sort by state.  You may also click the host field to sort VMs by the host names (I would recommend this if you have multiple clusters with multiple editions of ESXi).  You can then right-click the virtual machine titles and add the field for “Memory Size” as shown below.  Right-click right on the word “State” in the title of the column.

Once the Memory field has been added (it will probably be far on the right), drag the filed so it’s just to the right of the “State” field.  Now go to the “File” Menu at the top of the vSphere client and select “File” then “Export” and then “Export List”.  Export the file selecting “Excel Workbook” as the file type.  Once exported, open the list in Excel.  In Excel, add a column to the right of the memory column like so:

Edit Cell D2 and put in this formula:   =IF(B2=”Powered On”,VALUE(LEFT(C2,(LEN(C2)-3))),0)

Copy this formula down the entire column.  This checks to see if the VM state is powered on (you do not draw from your vRAM license if it is not).  It then removes the “MB” and converts the value to a numeric so you can sum them up.

Scroll down to the last row and edit the cell in the next empty row in the memory column to something like this:  =ROUNDUP(SUM(D2:D65)/1024,0)

Where D65 is actually the last cell with the memory data in it, your row number will vary depending on how many VMs you have.

The ROUNDUP will round up the memory allocation (in case you have some VM’s with 4000MB allocated to them instead of 4096MB) and you need to divide the sum by 1024 to convert to GB of vRAM.

If you would rather run a PowerCLI script to gather the info, you can find a great article on how to do it here.

I hope your number turns out ok.  If it does not, all is not lost.  There are ways to shrink your vRAM footprint so the impact of the licensing is not as bad.  If you would like me to have a look, email me, I can provide a service to see how much vRAM you have allocated but never use.  That may prolong the next license purchase a bit or perhaps soften the expense.  The new licensing does not need to always be negative, maybe we just need to learn how to size our VMs with the licensing in mind.

UPDATE: If you copy and paste these formulas into Excel, the ASCII is different for some reason.  Just backspace over the quotes (“) and readd them.  The quotes are what Excel has an issue with.

Here are some of the features:

• Deploys as an appliance, very easy to install
• Must be deployed on a new ESXi 5.0 installation
• Deploys a VSA Cluster Service on the vCenter server
• The VSA Cluster Service can deploy the VSA “Agent VMs” to each of the ESXi 5.0 hosts
• The appliance will use the local space available and present the storage on the network as an NFS datastore
• Replicates the local storage to the local storage on another host in the cluster for redundancy.
• If a host fails, the appliance storing the replica will immediately take over the failed “Agent VM’s” IP address and share the storage from the replica
• v1.0 supports 2 or 3 ESXi hosts in a cluster (Typically for the essentials kits)
• Sold as a separate SKU with one price with no license capacity restrictions (no technical size limits that I could find)
• Supports 25 VMs (configured on 2 ESXi hosts) or 35 VMs (configured on 3 ESXi hosts)
• It is the only scenario where VMware recommends running vCenter on a physical or standalone ESXi hypervisor (To protect you from running into a Catch-22 as vCenter is managing the VSAs
• Recommended to use RAID10 on the hardware RAID controllers in the hosts (to protect from a single drive failure)
• Uses RAID 1 (Mirroring) between hosts for redundancy
• Supports Storage vMotion for when you are ready to migrate to hardware shared storage
• Can put the whole VSA cluster in maintenance mode or just a single node.  Can also replace a node and have the VSA rebuild onto it for redundancy or for rolling upgrades.

Here’s how it works: Imagine I have 3 hosts numbered 1,2 and 3.  Once the VSA gets installed, it creates two volumes on the available local storage on each host.  So host 1 will have volumes 1A and 1B, host 2 has 2A and 2B, host 3 has 3A and 3B.  Once the VSAs are configured, they will be redundant so that 1A (which stores VMs) mirrors to 2B, 2A mirrors to 3B and 3A mirrors to 1B.  If any VSA get’s dropped, the VSA running the mirror copy takes the IP address of the failed VSA and keeps right on chugging.

My Take

The Pros: Great solution for SMBs without shared storage to take advantage of HA, vMotion, etc.  I also think this is an outstanding solution for companies with remote offices who want to have redundancy in 2 or 3 ESXi hosts but don’t want to put shared storage in each site.

The Cons:  Way too much overhead.  VMware is recommending hardware RAID10 from the local drives if possible.  If I have 4 x 1TB drives in a server (4TB RAW disk capacity).  I use RAID10 as per VMware’s recommendation, this means 2TB gets presented to the ESXi host.  Now the VSA uses half of that storage for VMs and half as a target to mirror the VSA from one of the other hosts.  So out of 4TB of RAW disk, I get <1TB of capacity to store VMs on (don’t forget, I need room to store ESXi itself).  Thats a 75% reduction from RAW capacity = too much overhead.

Overall I still think it’s worth it.  It’s still going to be less expensive that a shared storage frame (even with the overhead loss).  I think for remote sites, you can’t beat it.  I can’t wait to see what they add to it in v2.0.

VMware vSphere 5.0

• ESXi Convergence – No more ESX, only ESXi (they said they would do it, they meant it)
• New VM Hardware:  Version 8 – New Hardware support (VS5 still supports VM Hardware 4 & 7 as well if you still want to migrate to the old hosts)
  • 3D graphics Support for Windows Aero
  • Support for USB 3.0 devices

• Platform Enhancements (Blue Requires Hardware v8)
  • 32 vCPUs per VM
  • 1TB of RAM per VM
  • 3D Graphics Support
  • Client-connected USB devices
  • USB 3.0 Devices
  • Smart-card Readers for VM Console Access
  • EFI BIOS
  • UI for Multi-core vCPUs
  • VM BIOS boot order config API and PowerCLI Interface
• vSphere Auto Deploy – mechanism for having hosts deploy quickly when needed ( I’m going to wait and see how customers use this one.)
• Support for Apple Products – Support for running OSX 10.6 Server (Snow Leopard) on Apple Xserve hardware. (although I betting technically, you can get it to run on any hardware, you will just not be compliant in your license)
• Storage DRS – Just like DRS does for CPU and Memory, now for storage
  • Initial Placement – Places new VMs on the storage with the most space and least latency
  • Load Balancing – migrates VMs if the storage cluster (group of datastores) gets too full or the latency goes too high
  • Datastore Maintenance Mode  - allow you to evacuate VMs from a datastore to work on it (does not support Templates or non-registered VMs yet…)
  • Affinity & Anti-Affinity – Allows you to make sure a group of VMs do not end up on the same datastore (for performance or Business Continuity reasons) or VMs that should always be on the same datastore.  Can be at the VM or down to the individual VMDK level.
  • Support for scheduled disabling of Storage DRS – perhaps during backups for instance.
• Profile-Driven Storage – Creating pools of storage in Tiers and selecting the correct tier for a given VM.  vSphere will make sure the VM stays on the correct tier(pool) of storage.  (Not a fan of this just yet.  What if just 1GB of the VM needs high-tier storage? This makes you put the whole VM there.)
• vSphere File System – VMFS5 is now available.  (Yes, This is a non-disruptive upgrade, however I would still create new and SVmotion)
  • Support for a single extent datastore up to 64TB
  • Support for >2TB Physical Raw Disk Mappings
  • Better VAAI (vStorage APIs for Array Integration) Locking with more tasks
  • Space reclamation on thin provisioned LUNs
  • Unified block size (1MB) (no more choosing between 1,2,4 or 8)
  • Sub-blocks for space efficiency (8KB vs. 64KB in VS4)
• VAAI now a T10 standard – All 3 primitives (Write Same, ATS and Full Copy) are now T10 standard compliant.
  • Also now added support for VAAI NAS Primitives including Full File Clone (to have the nas do the copy of the vmdk files for vSphere) and Reserve Space (to have the NAS create thick vmdk files on NAS storage)
• VAAI Thin Provisioning – Having the storage do the thin provisioning and then vSphere telling the storage which blocks can be reclaimed to shrink the space used on the storage
• Storage vMotion Enhancements
  • Now supports storage vMotion with VMs that have snapshots
  • Now supports moving linked clones
  • Now supports Storage DRS (mentioned above)
  • Now uses mirroring to migrate vs change block tracking in VS4.  Results in faster migration time and greater migration success.
• Storage IO Control for NAS – allows you to throttle the storage performance against “badly-behaving” VMs also prevents them from stealing storage bandwidth from high-priority VMs.  (Support for iSCSI and FC was added in VS4.)
• Support for VASA (vStorage APIs for Storage Awareness) – Allows storage to integrate tighter with vcenter for management.  Provides a mechanism for storage arrays to report their capabilities, topology and current state.  Also helps Storage DRS make more educated decisions when moving VMs.
• Support for Software FCoE Adapters – Requires a compatible NIC and allows you to run FCoE over that NIC without the need for a CNA Adapter.
• vMotion Enhancements
  • Support for multiple NICs.  Up to 4 x 10GbE or 16 x 1GbE NICs
  • Single vMotion can span multiple NICs (this is huge for 1GbE shops)
  • Allows for higher number of concurrent vMotions
  • SDPS Support (Slow Down During Page Send) – throttles busy VMs to reduce timeouts and improve success.
  • Ensures less than 1 second switchover in almost all cases
  • Support for higher latency networks (up to ~10ms)
  • Improved error reporting – better, more detailed logging (thank you vmware!)
  • Improved Resource Pool Integration – now puts VMs in the proper resource pool
• Distributed Resource Scheduling/Dynamic Power Management Enhancements
  • Support for “Agent VMs” – These are VMs that work per host (currently mostly vmware services – vshield, edge, app, endpoint, etc)  DRS will not migrate these VMs
  • “Agents” do not need to be migrated for maintenance mode
• Resource pool enhancements – now more consistent for clustered vs. non-clustered hosts.  No longer can modify resource pool settings on the host itself when it is managed by vcenter.  It does allow for making changes if the host gets disconnected from vCenter
• Support for LLDP Network Protocol – Standards based vendor-neutral discovery protocol
• Support for NetFlow – Allows collection of IP traffic information to send to collectors (CA, NetScout, etc) to provide bandwidth statistics, irregularities, etc.  Provides complete visibility to traffic between VMs or VM to outside.
• Network I/O Control (NETIOC) – allows creation of network resource pools, QoS Tagging, Shares and Limits to traffic types, Guaranteed Service Levels for certain traffic types
• Support for QoS (802.1p) tagging – provides the ability to Q0S tag any traffic flowing out of the vSphere infrastructure.
• Network Performance Improvements
  • Multiple VMs receiving multicast traffic from the same source will see improved throughput and CPU efficiency
  • VMkernel NICs will see higher throughput with small messages and better IOPs scaling for iSCSI traffic
• Command Line Enhancements
  • Remote commands and local commands will now be the same (new esxcli commands are not backwards compatible)
  • Output from commands can now be formatted automatically (xml, CSV, etc)
• ESXi 5.0 Firewall Enhancements
  • New engine not based on iptables
  • New engine is service-oriented and is a stateless firewall
  • Users can restrict specific services based on IP address and Subnet Mask
  • Firewall has host-profile support
• Support for Image Builder – can now create customized ESXi CDs with the drivers and OEM add-ins that you need.  (Like slip-streaming for Windows CDs) Can also be used for PXE installs.
• Host Profiles Enhancements
  • Allows use of an answer file to complete the profile for an automated deployment
  • Greatly expands the config options including: iSCSI, FCoE, Native Multipathing, Device Claming, Kernel Module Settings & more)  (I don’t think Nexus is supported yet)
• Update Manager Enhancements
  • Can now patch multiple hosts in a cluster at a time.  Will analyze and see how many hosts can be patched at the same time and patch groups in the cluster instead of one at a time.  Can still do one at a time if you prefer.
  • VMTools can now be scheduled at next VM reboot
  • Can now configure multiple download URLs and restrict downloads to only the specific versions of ESX you are running
  • More management capabilities: update certificates, change DB password, proxy authentication, reconfigure setup, etc.
• High Availability Enhancements
  • No more Primary/Secondary concept, one host is elected master and all others are slaves
  • Can now use storage-level communications – hosts can use “heartbeat datastores” in the event that network communication is lost between the hosts.
  • HA Protected state is now reported on a per/VM basis.  Certain operations no longer wait for confirmation of protection to run for instance power on.  The result is that VMs power on faster.
  • HA Logging has been consolidated into one log file
  • HA now pushes the HA Agent to all hosts in a cluster instead of one at a time.  Result:  reduces config time for HA to ~1 minute instead of ~1 minute per host in the cluster.
  • HA User Interface now shows who the Master is, VMs Protected and Un-protected, any configuration issues, datastore heartbeat configuration and better controls on failover hosts.
• vCenter Web Interface – Admins can now use a robust web interface to control the infrastructure instead of the GUI client.
  • Includes VM Management functions (Provisioning, Edit VM, Poer Controls, Snaps, Migrations)
  • Can view all objects (hosts clusters, datastores, folders, etc)
  • Basic Health Monitoring
  • View the VM Console
  • Search Capabilities
  • vApp Management functions (Provisioning, editing, power operations)
• vCenter Server Appliance – Customers no longer need a Windows license to run vCenter.  vCenter can come as a self-contained appliance (This has been a major request in the community for years)
  • 64-bit appliance running SLES 11
  • Distributed as 3.6GB, Deployment range is 5GB to 80GB of storage
  • Included database for 5 Hosts or 50 VMs (same as SQL Express in VS4)
  • Support for Oracle as the full DB (twitter said that DB2 was also supported but I cannot confirm in my materials)
  • Authentication thru AD and NIS
  • Web-based configuration
  • Supports the vSphere Web Client
  • It does not support:  Linked Mode vCenters, IPv6, SQL, or vCenter heartbeat (HA is provided thru vSphere HA)
• vCenter Heartbeat 6.4 Enhancements
  • Allows the active and standby nodes to be reachable at the same time, so both can be patched and managed
  • Now has a plug-in to the vSphere client to manage and monitor Heartbeat
  • Events will register in the vSphere Recent Tasks and Events
  • Alerts will register in the alarms and display in the client
  • Supports vCenter 5.0 and SQL 2008 R2

That’s what I have on vSphere 5, next up is SRM5, vShield5, Storage Appliance, and vCloud Director 1.5.

New in version 1.1.0

• Support for connecting directly to a vSphere host (resolves Null Pointer Exception)
• Integrated interface to input vCMA server settings and login credentials
• Enhanced version compatibility checks between vSphere iPad application and vCMA server
• Fix for Null Pointer Exception when rebooting a host while the host was in maintenance mode
• Store password, if requested by the use, in the keychain
• Ability to properly scroll the host list in landscape mode
• Sorted host list (by name and grouped by vendor ID)
• Display either ellipsis for long virtual machine names
• Better performance metricswhen connecting directly to a vSphere host
• Show “Unavailable” or “PoweredOff” message when unable to obtain performance data for a selected VM
• Reflect available actions correctly, for a selected VM, when an operation was completed
• Ability to cancel “revert to snapshot” action

My notes:  The client is maturing, slowly, worth a look but I typically only use it when in a pinch and need some simple tasks completed in the environment.

Let’s go thru an example.  First things first, before you export, make sure you have all the information you need.  In the vSphere client, pick your level to look at the Storage View (the vCenter Server, the datacenter, a cluster, a host, etc) and select the Storage Views tab on the right.  Right-click the title bar in the right pane and make sure you have all of the fields you need.  The menu will look something like this one here:

Make sure you select all of the columns of data that you want (or don’t want).  Once you have that cleaned up, we go for the export.  Your instinct would be to go to File and Export like this:

Notice how the Export List option is greyed out?  That’s where you would expect to find the export function for the Storage Views.  I think there is a bug in the interface as that is not really where it is located in this case.  For Storage Views, move the cursor to some white space on the right or the bottom of the right pane and right-click.  You should see a popup menu that looks like something like this:

Select “Export List” from the menu and you can save the storage view as Excel, HTML, CSV, etc.  There, now you have some great data for graphs or whatever you like.

One more tip:  If you export the fields to Excel, the cells will all be text and the data values will have “GB” in the cells with them.  If you want to remove the “GB” and convert to numeric so you can work with the values here’s how:

Let’s say Cell C3  has a value of “7.77 GB”.  Create a new column and for the value put in  =VALUE(LEFT(C3,LEN(C3)-3))

The LEFT() function will cutoff the “GB” and the VALUE() function will convert the TEXT to a numeric value that you can add, subtract, etc.

Now you can add a cell at the bottom and use the AVERAGE() function and find out what your average VM size really is!  Or SUM() the Snapshot column and find out how much space your VM snaps are taking up on storage.  There are all kinds of options, have fun and enjoy!

Beginning on March 15, 2011, VMware began sending out the email notifications with the Redemption Codes in email.  The customer contact on the original order for the products should have received the email.  It has instructions for redeeming the code and getting the Ops Manager licenses.  If you have not received (or can’t find) the email and believe you are eligible, you should contact your VMware Sales team.  Here’s the main point: If you have received your email, you only have until May 31, 2011 to redeem your code and get your licenses.

If you think you are eligible, make sure to find your email and get your licenses, time is running out.

2 new patches released Yesterday.  You can find the details for the ESXi patch in this KB Article and in this KB Article.  There are two very important security fixes in the patches but they also have some problem symptoms fixed as well.  Here’s some of the symptoms that are fixed (as per the KB articles at the time of this writing):

• If you configure the port group policies of NIC teaming for parameters such as load balancing, network failover detection, notify switches, or failback, and then restart the ESXi host, the ESXi host might send traffic only through one physical NIC.
• Virtual machines configured with CPU limits might experience a drop in performance when the CPU limit is reached (%MLMTD greater than 0). For more information, see KB 1030955.
  
• The CPU usage of sfcbd becomes higher than the normal, which is around 40% to 60%. The/var/log/sdr_content.raw and /var/log/sel.raw log files might contain the efefefefefefefefefefefef text, and the /var/log might contain a SDR response buffer was wrong size message. This issue occurs becauseIpmiProvider might use CPU for a long time to process meaningless text such as efefef.
  This issue is seen particularly on Fujitsu PRIMERGY servers, but might occur on any other system.
• ESXi hosts that are installed with NetXen NX 2031 devices might not show up under ESXi 4.1. When you view the NICs in the vSphere Client for the ESXi host, NetXen devices might not appear.
• The Broadcom 5709 NIC that uses the bnx2 driver and the MSI-X might stop processing interrupts and terminate network connectivity under heavy workloads. This issue occurs because the driver drops the write to unmask the MSI-X vector by the kernel, when the GRC timeout value for such writes is too short.
  This patch increasing the GRC timeout value, preventing unexpected termination of network connectivity when the NIC experiences heavy workload.
• If the NFS volume hosting a virtual machine encounters errors, the NVRAM file of the virtual machine might become corrupted and grow in size from the default 8K up to a few gigabytes. At such a time, if you perform a vMotion or a suspend operation, the virtual machine fails with an error message similar to the following:
  unrecoverable memory allocation failures at bora/lib/snapshot/snapshotUtil.c:856
• Linux virtual machines with VMXNET2 virtual NIC might fail when the virtual machines are using MTU greater than the standard MTU of 1500 bytes (jumbo frames).
• If you are using a backup application that utilizes Changed Block Tracking (CBT) and the ctkEnabled option for the virtual machine is set to true, the virtual machine becomes unresponsive for up to 30 seconds when you remove snapshots of the virtual machine residing on an NFS storage.
• An ESXi host connected to an NFS datastore might fail with a purple diagnostic screen due to a corrupted response received from the NFS server for any read operation that you perform on the NFS datastore, displaying error messages similar to the following:
  Saved backtrace from: pcpu 16 SpinLock spin out NMI
  0x4100c00875f8:[0x41801d228ac8]ProcessReply+0x223 stack: 0x4100c008761c
  0x4100c0087648:[0x41801d18163c]vmk_receive_rpc_callback+0x327 stack: 0x4100c0087678
  0x4100c0087678:[0x41801d228141]RPCReceiveCallback+0x60 stack: 0x4100a00ac940
  0x4100c00876b8:[0x41801d174b93]sowakeup+0x10e stack: 0x4100a004b510
  0x4100c00877d8:[0x41801d167be6]tcp_input+0x24b1 stack: 0x1
  0x4100c00878d8:[0x41801d16097d]ip_input+0xb24 stack: 0x4100a05b9e00
  0x4100c0087918:[0x41801d14bd56]ether_demux+0x25d stack: 0x4100a05b9e00
  0x4100c0087948:[0x41801d14c0e7]ether_input+0x2a6 stack: 0x2336
  0x4100c0087978:[0x41801d17df3d]recv_callback+0xe8 stack: 0x4100c0087a58
  0x4100c0087a08:[0x41801d141abc]TcpipRxDataCB+0x2d7 stack: 0x41000f03ae80
  0x4100c0087a28:[0x41801d13fcc1]TcpipRxDispatch+0x20 stack: 0x4100c0087a58
• An ESXi host might stop responding if one of the mirrored installation drives that is connected to an LSI SAS controller is unexpectedly removed from the server.
• If there are read-only LUNs with valid VMFS metadata, rescanning of VMFS volumes might take a long time to complete because the ESXi server keeps trying to mount the read-only LUNs till the mount operation times out.
• When you simultaneously start several hundred virtual machines that are configured to use the e1000 virtual NIC, ESXi hosts might stop responding and display a purple diagnostic screen.
• When you migrate a virtual machine or restore a snapshot, you might notice a loss of application monitoring heartbeats. This issue occurs due to internal timing and synchronization issues. As a consequence, you might see a red application monitoring event warning, followed by the immediate reset of the virtual machine if the application monitoring sensitivity is set to High. In addition, application monitoring events that are triggered during the migration might contain outdated host information.
• When USB devices connected to EHCI controllers get reset, memory corruption might sometimes cause the ESXi host to fail with a purple screen and display error messages similar to the following:
  #GP Exception 13 in world 4634:vmm0:sofsqle @ 0x418015eab7a1
  86:01:33:10.118 cpu6:4634)Code start: 0x418015a00000 VMK uptime: 86:01:33:10.118
  86:01:33:10.119 cpu6:4634)0x417f810d77e8:[0x418015eab7a1]ehci_urb_done@esx:nover+0x34 stack: 0xffffff8d
  86:01:33:10.119 cpu6:4634)0x417f810d7858:[0x418015eabfd7]qh_completions@esx:nover+0x406 stack: 0x10
  86:01:33:10.119 cpu6:4634)0x417f810d78d8:[0x418015ead4b1]ehci_work@esx:nover+0xb8 stack: 0x1
  86:01:33:10.120 cpu6:4634)0x417f810d7928:[0x418015eafaa4]ehci_irq@esx:nover+0xeb stack: 0x417f810d79d8
  86:01:33:10.120 cpu6:4634)0x417f810d7948:[0x418015e99f3d]usb_hcd_irq@esx:nover+0x2c stack: 0x5
• When SCO OpenServer 5.0.7 virtual machines with multiple vCPUs are installed on a virtual SMP enabled ESXi Server, the SCO OpenServer 5.0.7 virtual machines start with only one vCPU instead of starting with all the vCPUs.
• When a Storage Virtual Appliance (SVA) presents an iSCSI LUN to the ESXi host on which it runs, occurrence of VMFS lockup might cause I/O timeouts in the SVA, resulting in messages similar to the following in the /var/log/messages file of the SVA virtual machine:
  sva1 kernel: [ 5817.054354] mptscsih: ioc0: attempting task abort! (sc=ffff88001f95b580)
  sva1 kernel: [ 5817.054360] sd 0:0:1:0: [sdb] CDB: Write(10): 2a 00 00 15 30 40 00 00 40 00
  sva1 kernel: [ 5817.182134] mptscsih: ioc0: task abort: SUCCESS (sc=ffff88001f95b580)
• If you configure primary or secondary private VLAN on vNetwork Distributes Switches while a virtual machine is migrating, the destination ESXi host might stop responding and displays a purple diagnostic screen with messages similar to the following:
  #PF Exception 14 in world 4808:hostd-worker IP 0x41801c96964a addr 0x38
  VLAN_PortsetLookupVID@esx:nover+0x59 stack: 0x417f823d77a8
  PVLAN_DVSUpdate@esx:nover+0x5cb stack: 0x0
  DVSPropESSetPVlanMap@esx:nover+0x81 stack: 0x1
  DVSClient_PortsetDataWrite@vmkernel:nover+0x78 stack: 0x417f823d7898
  DVS_PortsetDataSet@vmkernel:nover+0x6c stack: 0x1823d78f8 

   

• When VMware Fault Tolerance is enabled on a virtual machine and the ESXi host that runs the secondary virtual machines is powered off unexpectedly, the primary virtual machine might become unavailable for about a minute.

If you have been experiencing any of these symptoms, time to get your change management form filed and patch at will.

When we renamed the service account to have a different name from the vCenter server itself, all installed fine.  I had to post it, this issue really surprised me.

Duncan wrote an explanation in the community thread for what is going on:

“It most definitely has to do with the type of datamover used. When a different blocksize is used for the destination the legacy datamover is used which is the FSDM. When the blocksize is equal the new datamover is used which is FS3DM. FS3DM decides if is will use VAAI or just the software component, in either case unfortunately the zeroes will not be gobbled. I have validated it and reported it to engineering that this is desireable. The team will look into it but unfortunately I cannot make any promises if or when this feature would be added.”

It sounds to me like if your storage supports VAAI and ESXi offloads the svmotion to it, there’s no hope of shrinking because VAAI is not that intelligent.  When you svmotion between two different LUN block sizes (or between iSCSI, NFS or FC) it uses old-school svmotion (probably because the VMFS block layout changes) which will actually convert the VM to thin when it moves.

Hopefully VMware engineering will change svmotion to automatically use old-school svmotion when you select to change from thick or thin and only use VAAI when you choose to keep the same format during the move.  We’ll have to wait and see….

Here’s why:  In a true failover in SRM, the first step of the Recovery Plan is to shut down all of the VMs in the primary site that are protected.  This is so that when the VMs restart in the recovery site, they do not conflict on the network with the original VMs.  Here in Miami the typical disaster is, of course, hurricanes.  Hurricanes are typically predictable with a decent notice.  I can then assume that my odds are higher than normal that when the person hits the failover button here, both sites are still available and I will be avoiding a disaster and not recovering from one.  For this reason, I recommended to my customer that they add a message in their recovery plan right above “Prepare Storage” in the Recovery Plan.  You can do this by right-clicking “Prepare Storage” and selecting “Add Message”.

I added the following message to their Recovery Plan:

License Sale

Upgrade to vSphere Enterprise for $495 per CPU (normally $685/CPU) – Support and Subscription is required with purchase.  Pretty self-explanatory on the differences.  I’m a huge fan of Host Profiles, distributed switches and storage IO control.

50 Seats of View Premier with vSphere Enterprise Plus Upgrades – Customers who purchase Enterprise Plus (Ent+) will get 50 concurrent Desktops of View Premier Edition and 1 year of Production Support and Subscription.  This promo also includes all of the bundles that upgrade vSphere to Ent+ (including the $495 upgrade above).

15 VMs of CapacityIQ with upgrades to Standard, Advanced, Enterprise and Ent+ – Customers who purchase or upgrade upgrade to any of these editions or bundles containing any of these editions get 15 VMs of CapIQ.  Essentials and Essentials Plus bundles are not eligible.

The official disclaimer from VMware: “VMware reserves the right to amend the terms, conditions and requirements of these promotions.  List Pricing is for reference purposes only and is subject to change without notice and my vary within region. Please refer to your reselling partner or www.vmware.com for a quotation or actual product pricing.”

PerVM Licensing

CapIQ, AppSpeed, Chargeback, and Site Recovery Manager are switching to perVM licensing from perCPU.  Customers can stay on their perCPU licenses or they can convert.  Customers who convert will get 10 VMs of Appspeed for each CPU, 10VMs of CapIQ for each CPU, 20 VMs of Chargeback for each CPU and 5 VMs of Site Recovery Manager per CPU, respectively.  As I mentioned, customers can stay on their existing licenses and renew support for them if they want.  They will not be able to buy any new perCPU licenses after December 15th, 2010 for these 4 products listed above.  This is where I see a bit of a storm brewing.  Customers who run many VMs per host and want to protect most of them are in for a bit of a rude awakening.

My take on PerVM Licensing

Let’s say a customer runs SRM perCPU today.  They have 4 hosts running 100 VMs total and SRM protects them all.  Each host has 2 CPUs.  In the old licensing model, they needed 8 CPUs of SRM that retailed for $1,750 each.  8 x 1,750 = $14,000 (let’s exclude Support and Subscription for the moment to make the numbers easier but I recognize that SnS is required).  Under the new model, the PerVM licensing comes in packs of 25 VMs.  For our example we need 4 packs of 25 VMs that retail for $11,250 each or 4 x 11,250 = $45,000.  Yes, you just read that right.  The customers cost for SRM in our example just went from $14k to $45k.

The new licensing does benefit some customers however.  Those with large farms that want to protect a minority of their VMs.  Those customers can now just buy a pack of VMs and protect only the ones they need.  They can even split the licenses between sites and cross-replicate.  This is where this licensing model really helps.  It helps the customers who just want to do some SRM.

The last point I want to make is buried in the FAQ on PerVM Licensing.  If you are currently running perCPU SRM in a cluster, if you need to add a host after December 15th and you need SRM licenses for that new host, you will need to convert your licenses at a ratio of 5:1 for SRM and then purchase perVM for all your existing protected VMs that are not covered by your converted licenses.  I have a bad feeling this is going to be a wakeup call for some customers.  Another note: there’s no switching back.  Once you go perVM, you cannot go back to perCPU.

I try very hard to look out for my customers and keep them informed.  These licensing changes may benefit some customers wanting to start out with a small number of protected VMs with SRM.  However, most of my SRM customers are like the $45k example shown above.  I don’t see these licensing changes being a benefit to them.  Normally, I don’t discuss licensing in my blog articles.  Some customers have negative attitudes when it comes to licensing.  Some maybe got burned in the past, or just don’t like to talk about spending money.  My goal here is to make sure you can see how these changes can affect you before the impending deadline.  Sometimes I can see a storm brewing from off in the distance.  I just hope that the storm does not cause a disaster, the likes of which even SRM cannot recover from.

CapacityIQ 1.5 includes the following new features and enhancements:

• Storage Analytics – Adds disk space and disk I/O trending and storage analysis. The dashboard and views provide visibility into consumption of storage resources and ways to identify capacity bottlenecks. The data is optimized for vSphere and accounts for thin provisioning, I/O control, and linked clones.
• Resource optimization – Adds storage-aware workload modeling and what if scenarios to forecast future capacity needs. CapacityIQ provides outlier detection and filtering capabilities for improved analytics.
• Scheduled Reports – Adds report scheduling with email capabilities for automated delivery of capacity utilization and optimization reports.
• Performance and scalability improvements – Improves the response time in the interface and raises the scalability limits to 6000 powered on virtual machines and 8000 registered virtual machines.
• Virtual machine-based licensing – Supports virtual machine and CPU-based licensing. If you obtain a virtual machine-based license for CapacityIQ, install and manage the license from vCenter Server instead of the Administration Portal. You can continue to manage CPU-based licenses in the Administration Portal.

My initial take on it: Storage trending is a good addition.  It’s nice that it takes into account thin disks, etc.  Scheduled Reports is a nice add for proactive reporting.  Licensing going to vCenter for managing the license keys should have been done in v1.0.  I don’t like managing per-cpu licenses one way and per-vm another.  Overall sounds like a worthwhile release.  I’ll be plugging this into the lab later this week to kick the tires first hand.  Any additional pros and cons will be posted in an update.

You may know a little about Avamar.  It’s a backup solution that uses source-based deduplication to perform backups.  It basically always takes full backups and it only stores pieces of files that it has not seen before in the entire environment.  Every thing that it has seen across your organization is tracked.  This includes which client it was seen on and when, but only one copy of the file piece is stored on disk.  This creates extremely efficient and rapid backup.  For VMware enviornments, Avamar can take file level backups by running a client in the GuestOS or a VM image level backup by running a proxy VM in the infrastructure.

When you combine these two technologies together, the result is the best of both worlds.  Specifically referring to the image level backups with CBT enabled.  This means that Avamar only backs up the pieces of the vmdk files that it has not seen before and with CBT, it only scans the blocks that have changed from the last backup when looking for pieces to deduplicate.  Very efficient and very optimized – we’re talking hundreds of GB in just minutes.

Here the issue I ran into: I added a client to Avamar and setup a policy to do Image Level backups of the VM.  I kicked one off and the Avamar starts by creating a snapshot of the VM and mounting the snap to the Avamar Proxy VM.  Avamar then queries CBT on vSphere and gets the list of blocks that changed since the last backup.  The proxy then scan thru only the blocks that changed and only send the file segments within those blocks that it has not seen before to the actual disks for backup.  When finished, Avamar unmounts the snap from the proxy and deletes the snap.  When I ran thru this procedure at the customer site, the first backup took about 15 minutes for 100GB on their system.  This is expected as there is no CBT information yet so the proxy must read thru the entire 100GB to determine what file pieces it has and has-not seen before and that takes the majority of the 15 minutes.  On the second backup however, I expect that CBT will only show the proxy the blocks that changed and then it will dedupe only those and store all of the other blocks in Avamar from the inventory of blocks it already has (as CBT said those blocks have not changed).  When I did go and run the second backup it took 15 minutes. It should have taken only a minute or two.  What’s the deal?

The solution:  I did some hard digging on the net for a solution. I was sent this article on the EMC support site from one of our other Engineers (thanks Judson!).  Basically it said that VMware has an issue (documented here) with CBT and VMware snapshots.  In a very specific scenario, a customer could restore a snapshot of a VM from vCenter and it’s CBT information would be inaccurate.  When the backup or replication was looking to CBT for the blocks that changed, it could provide incorrect information.  This would backup or replicate incomplete information without showing an error of any kind.  That’s bad.

Avamar knows about this issue and protects people.  It does this by looking to see if CBT is in use and if there are any VMware snapshots older than the last retained backup of the data in Avamar.  If there is an older snap, Avamar assumes that a customer could revert to it any time (or already did) and that the CBT data could be invalid – so it ignores the CBT info and reads thru the entire VM.  This is why my backup above took 15 minutes each time.  I had snapshots on that VM older than the oldest Avamar backup retained.  When I removed the snaps the next backup took 15 minutes (I later found that this was to reset the CBT information).  The next backup after that took 47 seconds.  Now we’re in business.

If you see these kinds of performance issues on Image Level backups in Avamar, try cleaning out the VMware Snapshots.  This issue does not affect file level backups only Image-level. I hope this helps out the users who are trying to run Image level with Avamar.  Now you’ll know what to try when performance for the backups slows down for no apparent reason.

Thanks and good computing.

I found a few references here and there.  Most customers keep the paging file inside the standard VM disks to avoid making the environment too complex.  I was about to give up and suggest he not separate the paging file, until I came across this discussion in the VMware communities.  I was stunned to see one customer report that they were seeing a reduction of 60% of the replication traffic on certain VMs.  They even saw a 80% reduction of replicated traffic from one of their Citrix servers.  Now I was cooking.  This was amazing and made perfect sense to me how some servers could be more defined by this than others.  I was off to find a documented procedure from VMware to do so.  Unfortunately I came up empty in the Knowledge Base, white papers and best practices.  If you know of such a VMware documented procedure, please post in the comments with a reference link and I will update my article.

After reviewing the communities discussion line-by-line, I came across this NetApp SRM technical paper written by Jeremy Merill and Larry Touchette (whom I was fortunate enough to work with while I was at NetApp).  It contains some great procedures for optimizing NetApp storage and Site Recovery Manager.  Beginning on page 41 however, is a great vendor-agnostic procedure for separating out the Windows Paging file to reduce it’s impact on storage replication.  Jackpot.  Basically there are a few points to consider.  First the windows swap file is configured for a specific drive letter and path.  How do you make sure the recovered machine gets the same drive letter when it comes up in the recovery plan?  The answer is in the procedure.  Jeremy and Larry describe how to configure the source VM with it’s Windows Paging file seperated.  Then they clone the VMDK where the paging file resides and copy it to the destination side.  The reason they do this is because the disk has a signature on it that tells Windows what drive letter it is.  Then they altered the recovery plan for SRM to mount that destination disk to the VM before it powers on.  So that when the recovery VM does come online, it has it’s page file disk as the same letter with the page file intact.  Because the Windows paging file gets wiped on every boot, the data in it is not important, only the location where it’s stored.  They repeat this procedure for every VM in the recovery plan.  I realize that this could be a large undertaking to separate all these page files but the more VMs, the more replication data saved.

I’m very curious if some have tried separating out the page file and what replication improvements you have seen.  Please report those in the comments if you have tried it.  I’d love to hear the results.