vSphere 5

vSphere supports several command‐line interfaces for managing your virtual infrastructure including the vSphere Command‐Line Interface (vCLI), a set of ESXi Shell commands, and PowerCLI. You can choose the CLI set best suited for your needs, and write scripts to automate your CLI tasks.

The vCLI command set includes vicfg- commands and ESXCLI commands. The ESXCLI commands included in the vCLI package are equivalent to the ESXCLI commands available on the ESXi Shell. The vicfgcommand set is similar to the deprecated esxcfg- command set in the ESXi Shell.

You can manage many aspects of an ESXi host with the ESXCLI command set. You can run ESXCLI commands as vCLI commands or run them in the ESXi Shell in troubleshooting situations. You can also run ESXCLI commands from the PowerCLI shell by using the Get-EsxCli cmdlet. See the vSphere PowerCLI Administration Guide and the vSphere PowerCLI Reference. The set of ESXCLI commands available on a host depends on the host configuration. The vSphere Command‐Line Interface Reference lists help information for all ESXCLI commands. Run esxcli --server <MyESXi> --help before you run a command on a host to verify that the command is defined on the host you are targeting.

You can use this link to get your copy of the VMware ESXi 5.0 Reference Poster.

vSphere 5 introduces a new latency-aware Metro vMotion feature that not only provides better performance over long latency networks but also increases the round-trip latency limit for vMotion networks from 5 milliseconds to 10 milliseconds. Previously, vMotion was supported only on networks with round-trip latencies of up to 5 milliseconds. In vSphere 4.1, vMotion is supported only when the latency between the source and destination ESXi/ESX hosts is less than 5 ms RTT (round-trip time). For higher latencies, not all workloads are guaranteed to converge. With Metro vMotion in vSphere 5.0, vMotion can be used to move a running virtual machine when the source and destination ESX hosts have a latency of more than 5ms RTT. The maximum supported round trip time latency between the two hosts is now 10ms. Metro vMotion is only available with vSphere Enterprise Plus license.

Related Video – Carter Shanklin’s WANatronic 10001

Fellow vExpert Forbes Guthrie has released his vSphere 5.0 documentation notes.

Here are my condensed notes for the vSphere 5.0 documentation. They’re excerpts taken directly from VMware’s own official PDFs.  The notes aren’t meant to be comprehensive, or for a beginner; just my own personal notes.  I made them whilst studying for the VCP5 beta exam, and its part of the process I use to collate information for the vSphere Reference Card.

http://www.vreference.com/vsphere-5-notes/

This paper describes some use cases of deploying SAP with vShield App. vShield App provides microsegmentation / zoning of different landscapes which enables a secure SAP deployment. The configurations covered here are examples only, but provide a starting point from which to plan for a security architecture to cover a SAP installation on VMware in production and non-production environments.

Workload characterizations conducted against SAP show that CPU resources are required by vShield firewall virtual machines, the extent of which is dependent on the network traffic generated by the application. When there is a need for additional firewall capacity, administrators can add CPU or memory resources to the vShield App appliance. If the cluster is resource limited, administrators can add another host to the cluster along with the vShield App appliance and the hypervisor module.

Customer workloads will differ from those tested here which will result in different utilizations of the vShield App firewall appliance. Situations where systems are designed as two-tier instead of three-tier would reduce network traffic between virtual machines and lower firewall appliance utilization. For example, some SAP customers may deploy database and application instances in a single large virtual machine.

Categorizing applications into a container such as vApp greatly simplifies management of firewall policies with vShield App. Application and security administrators can respond rapidly to specific demands in a dynamic landscape, and while virtual machine templates enable quick deployment of systems, vShield App facilitates speedy security compliance.

VMware-vShield-App-Protecting-Virtual-SAP-Deployments.pdf

A vSphere Installation Bundle (VIB) is a single software package that may contain drivers, CIM providers, VMkernel modules, or otili her software. A depot is a repository of VIBs available online to Update Manager users. You create and maintain a depot to control the VIB files that Update Manager users can access. The depot and Web service portal use a static Web site to deliver a set of files intended for consumption by Update Manager. Before you provide updates to users through a depot, use the Workbench-based developer kit or the VIB Suite to generate the following files:

• A vendor-index.xml file. The index lists the product ID and version number, and points to metadata.zip files.
• One or more metadata.zip files. The metadata.zip files point to the location of the VIB files. Names of metadata.zip files cannot conflict with other filenames within your set of files or with the files of other vendors.
• One or more bulletins describing the VIB file. A bulletin is an XML file that describes the VIB included in a consumable package, metadata.zip. At least one bulletin must be included in every metadata.zip file.
• One or more VIB files.
  

From the vendor depot, Update Manager downloads a list of supported vendor Web site URLs. Based on the list of URLs, Update Manager obtains a list of metadata URLs from the publishing Web site, where it downloads the metadata. The metadata, in turn, contains the URLs for the VIB files. You can create the files required for an update depot by using VIB tools that are part of VMware Workbench. To create an online depot, unzip the contents of an offline bundle created by Workbench to the Web server root directory.

http://www.vmware.com/files/pdf/techpaper/vsphere-50-update-manager-depot.pdf

I’ve created a real cool video which shows you how to configure your vSphere 5 network in order to use multiple network adapters for vMotion. The idea for this video came from fellow VCI and virtualization friend Frank Brix Pedersen. More information about vMotion Architecture, Performance, and Best Practices in VMware vSphere 5 can be found here.


When using the multiple–network adaptor feature, configure all the vMotion vmnics under one vSwitch and create one vMotion vmknic for each vmnic. In the vmknic properties, configure each vmknic to leverage a different vmnic as its active vmnic, with the rest marked as standby. This way, if any of the vMotion vmnics become disconnected or fail, vMotion will transparently switch over to one of the standby vmnics. When all your vmnics are functional, though, each vmknic will route traffic over its assigned, dedicated vmnic.