vSphere 5 - 3

Logging in vSphere 5.0 has been significantly enhanced. You now have fine-grained control over system logs, the location where logs are sent, and, for each log, default size and rotation policy. You can set up logging with the vSphere Client or with the esxcli system syslog command and the PowerCLI VMHostSysLogServer Commandlets. You can also set up logging behaviour for a host by using the Host Profiles interface in the vSphere Client and can then import that host profile into other hosts. VMware vSphere ESXi 5.0 hosts run a syslog service (vmsyslogd) which provides a standard mechanism for logging messages from the VMkernel and other system components. By default in ESXi, these logs are placed on a local scratch volume or a ram disk. To preserve the logs further, ESXi can be configured to place these logs to an alternate storage location on disk, and to send the logs across the network to a syslog server. You have to install the vSphere Syslog Collector to enable ESXi system logs to be directed to a server on the network, rather than to a local disk. It’s possible install the Syslog Collector on the same machine as the associated vCenter Server, or on a different machine that has network connection to the vCenter Server. The Syslog Collector service binds to an IPv4 address for communication with vCenter Server, and does not support IPv6. The vCenter Server can be on a host machine in an IPv4-only, IPv4/IPv6 mixed-mode, or IPv6-only network environment, but the machine that connects to the vCenter Server through the vSphere Client must have an IPv4 address for the Syslog Collector service to work. In the ESXi Software panel there's an Advanced Setting called Syslog.global.LogHost, the value of this setting presents the remote host to which syslog messages are forwarded and port on which the remote host receives syslog messages. You can include the protocol and the port, for example, ssl://hostName1:514. UDP (default), TCP, and SSL are supported. The remote host must have syslog installed and correctly configured to receive the forwarded syslog messages. Checkout the video how the syslog service is installed on the vCenter host. You can also set up ESXi Syslog from the Host Profiles Interface. Hosts provisioned with Auto Deploy usually do not have sufficient local storage to save system logs. You can specify a remote syslog server for those hosts by setting up a reference host, saving the host profile, and applying that host profile to other hosts as needed. Best practice is to set up the syslog server on the reference host with the vSphere Client or the esxcli system syslog command and save the host profile. In some situations, setting up syslog from the Host Profiles interface is an alternative.

VMware supports in-place upgrades on 64-bit systems from vCenter Server 4.x to vCenter Server 5.0. You can upgrade VirtualCenter 2.5 Update 6 or later and vCenter Server 4.0.x to vCenter Server 5.0 by installing vCenter Server 5.0 on a new machine and migrating the existing database.

This upgrade method makes it possible to upgrade from a 32-bit system to a 64-bit system. Alternatively, if the VirtualCenter or vCenter Server database is on a remote machine, you can upgrade the database. vCenter Server 5.0 can manage ESX 3.5.x/ESXi 3.5.x hosts in the same cluster with ESX 4.x/ESXi 4.x hosts.

You cannot upgrade a vCenter Server 4.x instance that is running on Windows XP Professional x64 Edition to vCenter Server 5.0, because vCenter Server 5.0 does not support Windows XP Professional x64. This article provides information about upgrading to vCenter Server 5.0.

VMware KB: Upgrading to vCenter Server 5.0 best practices

What are datastore heartbeats?

The host-X-hb (where X is the host’s MOID) is Located on each heartbeat datastore, this file is used to check for slave liveness through the heartbeat datastore. This file is checked by the master host if the master loses network heartbeats from the slave.
 
For VMFS datastores, the vSphere HA agent locks this file with an exclusive lock and relies on the VMkernel heartbeat to indicate liveness. For NFS datastores, vSphere HA periodically updates the time stamp to this file to indicate liveness.

The host-X-poweron (where X is the host’s MOID) is a per-host file that contains the list of all virtual machines that are powered on. This file is used as a communication channel if a management network outage occurs. Isolated slaves use this file to tell the master that it is isolated as well as to tell the master which virtual machines it has powered off.

The master host must determine whether the slave host:

• Actually crashed
• Is not responding because of a network failure
• The HA agent is in an unreachable state

The absence of both a network and datastore heartbeat indicates full host failure. Datastores are used as a backup communication channel to detect virtual machine and host heartbeats. Datastore heartbeats are used to make the distinction between a failed, an isolated or a partitioned host.

vCenter Chargeback Manager is an end-to-end cost reporting solution for virtual environments that are using VMware vSphere. vCenter Chargeback Manager provides functionality to define unit costs and calculate the overall costs based on the actual usage or reservation of computing resources. This Web-based application interacts with the vCenter Server Database to retrieve usage information, calculates the cost by using the defined chargeback formulas, and generates cost and usage reports.

vCenter Chargeback Manager runs on an Apache Tomcat server instance. Users interact with vCenter Chargeback Manager through a load balancer (Apache HTTP Server). vCenter Chargeback Manager connects to the vCenter Chargeback Manager database that stores application-specific information, such as the defined chargeback hierarchies, cost models, users, roles, and so on. The application interacts with the vCenter Server using VIM APIs and with the vCenter Server database through a data collector. The data collector communicates with the vCenter Server Database using JDBC.

Continue reading "VMware has released vCenter Chargeback Manager..." »

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 vicfg command 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 Continue reading "Video - Using the ESXI 5.0 vCLI Command Set " »

vSphere Replication is a replication engine that is part of SRM 5.0 and requires ESXi 5.0 and later, giving an alternative means of protecting and replicating virtual machines between sites. It is entirely managed within the SRM interface after initial deployment and configuration, and integrates with storage array–based replication to provide full coverage of the virtual environment.

The assumption is that there are multiple databases for vSphere Replication already configured for use, one at each site. In this evaluation guide, we will be using Microsoft SQL Server as a database, and using native SQL authentication for access. Workflow covered will be as follows:

1. Deploy vSphere Replication Management Servers (VRMS).
2. Configure VRMS.
3. Pair VRMS.
4. Deploy vSphere Replication Server (VRS).
5. Register VRS.
6. Configure virtual machines for protection with vSphere Replication.
7. Create a protection group using vSphere Replication–protected virtual machines.

Fred van Donk has written an extensive article on Deploying vSphere Replication and setting up multiple Microsoft SQL databases.

VMware vShield is a suite of security virtual appliances built for VMware vCenter Server and VMware ESX integration. vShield is a critical security component for protecting virtualized datacenters from attacks and misuse helping you achieve your compliance-mandated goals. vShield App is an interior, vNIC-level firewall that allows you to create access control policies regardless of network topology. A vShield App monitors all traffic in and out of an ESX host, including between virtual machines in the same port group. vShield App includes traffic analysis and container-based policy creation.

In this video I'll show you that vShield App installs as a hypervisor module and firewall service virtual appliance. vShield App integrates with ESX hosts through VMsafe APIs and works with VMware vSphere platform features such as DRS, vMotion, DPM, and maintenance mode. vShield App provides firewalling between virtual machines by placing a firewall filter on every virtual network adapter. The firewall filter operates transparently and does not require network changes or modification of IP addresses to create security zones. You can write access rules by using vCenter containers, like datacenters, cluster, resource pools and vApps, or network objects, like Port Groups and VLANs, to reduce the number of firewall rules and make the rules easier to track.

You should install vShield App instances on all ESX hosts within a cluster so that VMware vMotion operations work and virtual machines remain protected as they migrate between ESX hosts. By default, a vShield App virtual appliance cannot be moved by using vMotion. The Flow Monitoring feature displays allowed and blocked network flows at the application protocol level. You can use this information to audit network traffic and troubleshoot operational.

A few weeks ago I’ve delivered a VMware Site Recovery Manager training course and one of the attendees was Arnim van Lieshout. Besides being a co-author of the VMware vSphere PowerCLI Reference: Automating vSphere Administration guide, Arnim also works as a VMware PSO consultant. While we were trying to set-up SRM Host Based Replication, Arnim showed me a real cool trick to do some fast troubleshooting regarding the VPXD daemon, also known as the vCenter Service.

This video guides you through the process of troubleshooting a corrupted vCenter Server database with vpxd.exe -s and helps you to fix VPX daemon start-up problems. The video also helps you eliminate common causes for your problem by verifying the configuration of your database, validating network connectivity, and verifying the configuration of the vCenter Server service with vpxd.exe -b.

This white paper provides detailed information on how to integrate VMware vSphere 5.0 with HP P4000 LeftHand SAN Solutions. VMware vSphere is an industry leading virtualization platform and software cloud infrastructure enabling critical business applications to run with assurance and agility by virtualizing server resources. Complementing this technology, the HP P4000 LeftHand SANs address the storage demands and cost pressures associated with server virtualization, data growth, and business continuity.

P4000 SANs scale capacity and performance linearly without incurring downtime, enabling it to meet the requirements of small pay-as-you-grow customers to the mission-critical applications of an enterprise. This document presents configuration guidelines, best practices and answers to frequently asked questions that will help you accelerate a successful deployment of VMware vSphere 5.0 on HP P4000 SAN Solutions.

HP P4000 LeftHand SAN Solutions with VMware vSphere Best Practices

Juan's HP resources for VMware - http://jreypo.wordpress.com/hp-resources-for-vmware/