VMware products End of Support (EOS)

VMware products reach their End of Support (EOS) phase. It’s very important to keep an eye on support because products that are “EOS” do no longer receive security updates or bugfixes from VMware. Always keep your environment up to date and supported.

Lifecycle Support Phases

General Support Phase

The General Support phase begins on the date of general availability of a Major Release (“GA”) and lasts for a fixed duration. During the General Support phase, for customers who have purchased VMware support, VMware offers maintenance updates and upgrades, bug and security fixes, and technical assistance.

Technical Guidance Phase

Technical Guidance, if available, is provided from the end of the General Support phase and lasts for a fixed duration.  Technical Guidance is available primarily through the self-help portal and telephone support is not provided. Customers can also open a support request online to receive support and workarounds for low-severity issues on supported configurations only.  During the Technical Guidance phase, VMware does not offer new hardware support, server/client/guest OS updates, new security patches or bug fixes unless otherwise noted.  This phase is intended for usage by customers operating in stable environments with systems that are operating under reasonably stable loads. ( See Lifecycle Support Summary Table)

End of Support Life (EOSL)

A product has reached its end of support life when it is no longer generally supported by VMware. End of support life for a specific product is either end of General Support or end of Technical Guidance, if available for that specific product.

End of Availability (EOA) / End Of Distribution (EOD)

A product has reached its end of availability when it is no longer available for purchase from VMware. A product has reached its end of distribution when VMware can no longer make it available as a download from vmware.com or distribute the product in other ways. The end of availability.

Lifecycle products Matrix

vCenter

ESXi

SRM

VCenter operation Manager

Nexus 1000v

VCenter converter

VRealize log Insight

When a product has reached its end of support (EOS) life, VMware does not offer new hardware support, server/client/guest OS updates, new security patches or bug fixes. During the Technical Guidance Phase support is available primarily through the self-help portal. Customers can open a support request online to receive support and workarounds for low-severity issues on supported configurations.

VMware announces vRealize Log Insight 3.3

Log Insight is a log aggregation, management and analisys tool, that VMware first introduced in 2013 and now is fiercely competing against.

Today the company announced Log Insight 3.3 that will be released shortly.

Among the new capabilities you can find:

• Multiple VIPs with Tags that now allow to tag incoming traffic
• Webhooks sent by both system and user alerts
• Enhanced vSphere Integration which mainly covers new tagging capabilities for vCenter Servers and ESXi hosts
• Additional OVF properties which includes DNS searchpath and DNS domain
• New Parsers that includes LTSV (Labeled Tab-Separated Values), Regex and Syslog
• IPv6 Support
• copytruncate Support from logrotate
• Windows 10 Support
• A set of new APIs including Authentication API, Query API and a new Importer Utility

Log Insight 3.3 will also include in TP an Agent Configuration Builder, pure IPv6 support for the Virtual Appliance and a new set of Configuration APIs.

vSphere 6.0 Update 1b released

VMware release vSphere vCenter Server and ESXi 6.0 Update 1b. A few updates and fixes i think will be useful for at least some of my readers are listed below:

• VMware now supports Cisco Nexus 1000V
• Virtual machines protected by VMware vShield App lose network connectivity on the ESXi 6.0 hosts
• Windows 10 VM VMX fails
• Hostd repeatedly stops responding with Signal 11 error
• Attempts to take a backup on VMware vCenter Server might fail
• The esxtop utility reports incorrect statistics for DAVG/cmd and KAVG/cmd on VAAI supported LUNs
• Virtual machine stops responding during snapshot consolidation on ESXi 6.0
• Expansion of eager zeroed VMDK causes the VM to be inaccessible
• Attempts to upgrade VMware Tools fail with a 21009 error code
• Update to the OpenSSL library
• If user is a member of more than 300+ groups in the Active Directory, the Windows Session Authentication login might fail due to an error in the VMware Client Integration Plugin
• Unable to configure an ESXi host for Active Directory authentication
• The esxcli vm process list command might display old VM name after you rename a powered on VM
• CBT functionality, QueryChangedDiskAreas API, might return incorrect sectors

Download vCenter Server 6.0 U1b here and read the entire release notes here

Download ESXi 6.0 U1b here and read the entire release notes here

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.