New Features in Windows Server 2012

User interface

Server Manager has been redesigned with an emphasis on easing management of multiple servers.The operating system, like Windows 8, uses the Metro UI unless installed in Server Core mode.Windows PowerShell in this version has over 2300 commandlets, compared with around 200 in Windows Server 2008 R2.There is also command auto­completion.

Task Manager

Windows 8 and Windows Server 2012 include a new version of Windows Task Manager together with the old version. In the new version, the tabs are hidden by default, showing applications. In the new Processes tab, the processes are displayed in various shades of yellow, with darker shades representing heavier resource use. It lists application names, application status, and overall utilization data for CPU, memory, hard disk, and network resources, moving the process information found in the older Task Manager to the new Details tab. The Performance tab is split into CPU, memory (RAM), disk, ethernet, and, if applicable, wireless network sections with graphs for each. The CPU tab no longer displays individual graphs for every logical processor on the system by default; instead, it can display data for each NUMA node. When displaying data for each logical processor for machines with more than 64 logical processors, the CPU tab now displays simple utilization percentages on heat­mapping tiles. The color used for these heat maps is blue, with darker shades again indicating heavier utilization. Hovering the cursor over any logical processor's data now shows the NUMA node of that processor and its ID, if applicable. Additionally, a new

Startup tab has been added that lists startup applications.The new task manager recognizes when a WinRT application has the "Suspended" status.

Installation options

Unlike its predecessor, Windows Server 2012 can switch between Server Core and the GUI (full) installation options without a full reinstallation. There is also a new third installation option that allows MMC and Server Manager to run, but without Windows Explorer or the other parts of the normal GUI

shell.

IP address management (IPAM)

Windows Server 2012 has an IPAM role for discovering, monitoring, auditing, and managing the IP address space used on a corporate network. IPAM provides for administration and monitoring of servers running Dynamic Host Configuration Protocol (DHCP) and Domain Name Service (DNS). IPAM includes components for:Automatic IP address infrastructure discovery: IPAM discovers domain controllers, DHCP servers, and DNS servers in the domains you choose. You can enable or disable management of these servers by IPAM. Custom IP address space display, reporting, and management: The display of IP addresses is highly customizable and detailed tracking and utilization data is available. IPv4 and IPv6 address space is organized into IP address blocks, IP address ranges, and individual IP addresses. IP addresses are assigned built­in or user­defined fields that can be used to further organize IP address space into hierarchical, logical groups. Audit of server configuration changes and tracking of IP address usage: Operational events are displayed for the IPAM server and managed DHCP servers. IPAM also enables IP address tracking using DHCP lease events and user logon events collected from Network Policy Server (NPS), domain controllers, and DHCP servers. Tracking is available by IP address, client ID, host name, or user name. Monitoring and management of DHCP and DNS services: IPAM enables automated service availability monitoring for Microsoft DHCP and DNS servers across the forest. DNS zone health is displayed, and detailed DHCP server and scope management is available using the IPAM console. Both IPv4 and IPv6 are fully supported.

Active Directory

Windows Server 2012 has a number of changes to Active Directory from the version shipped with Windows Server 2008 R2. The Active Directory Domain Services installation wizard has been replaced by a new section in Server Manager, and the Active Directory Administrative Center has been enhanced. A GUI has been added to the Active Directory Recycle Bin. Password policies can differ more easily within the same domain. Active Directory in Windows Server 2012 is now aware of any changes resulting from 12/28/2014 New Features in Windows Server 2012 virtualization, and virtualized domain controllers can be safely cloned. Upgrades of the domain functional level to Windows Server 2012 are simplified; it can be performed entirely in Server Manager. Active Directory Federation Services is no longer required to be downloaded when installed as a role, and claims which can be used by the Active Directory Federation Services have been introduced into the Kerberos token. Windows Powershell commands used by Active Directory Administrative Center can be viewed in a

"Powershell History Viewer".

Hyper­V

Windows Server 2012, along with Windows 8, will include a new version of Hyper­V,as presented at the Microsoft Build Event Many new features have been added to Hyper­V, including network virtualization, multi­tenancy, storage resource pools, cross­premise connectivity, and cloud backup. Additionally, many of the former restrictions on resource consumption have been greatly lifted. Each virtual machine in this version of Hyper­V can access up to 32 virtual processors, up to 512 gigabytes of random­access memory, and up to 16 terabytes of virtual disk space per virtual hard disk (using a new .vhdx format). Up to 1024 virtual machines can be active per host, and up to 4000 can be active per failover cluster. The version of Hyper­V shipped with the client version of Windows 8 requires a processor that supports SLAT and for SLAT to be turned on, while the version in Windows Server 2012 only requires it if the RemoteFX role is installed.

ReFS

ReFS (Resilient File System, originally codenamed "Protogon") is a new file system initially intended

for file servers that improves on NTFS in Windows Server 2012. Major new features of ReFS include:

Improved reliability for on­disk structures

ReFS uses B+ trees for all on­disk structures including metadata and file data. The file size, total volume size, number of files in a directory and number of directories in a volume are limited by 64­bit numbers, which translates to maximum file size of 16 Exbibytes, maximum volume size of 1 Yobibyte (with 64 KB clusters), which allows large scalability with no practical limits on file and directory size (hardware restrictions still apply). Metadata and file data are organized into tables similar to relational database. Free space is counted by a hierarchal allocator which includes three separate tables for large, medium, and small chunks. File names and file paths are each limited to a

32 KB Unicode text string.

Built­in resiliency

ReFS employs an allocation­on­write update strategy for metadata, which allocates new chunks for every update transaction and uses large IO batches. All ReFS metadata has built­in 64­bit checksums which are stored independently. The file data can have an optional checksum in a separate "integrity stream", in which case the file update strategy also implements allocation­on­write; this is

controlled by a new "integrity" attribute applicable to both files and directories. If nevertheless file data or metadata becomes corrupt, the file can be deleted without taking down the whole volume offline for maintenance, then restored from the backup. As a result of built­in resiliency, administrators do not need to periodically run error­checking tools such as CHKDSKwhen using ReFS.

Compatibility with existing APIs and technologies ReFS does not require new system APIs and most file system filters continue to work with ReFS volumes. ReFS supports many existing Windows and NTFS features such as BitLockerencryption, Access Control Lists, USN Journal, change notifications, symbolic links, junction points, mount points, reparse points, volume snapshots, file IDs, and oplock. ReFS seamlessly[citation needed] integrates with Storage Spaces, a storage virtualization layer that allows data mirroring and striping, as well as sharing storage pools between machines.ReFS resiliency features enhance the mirroring feature provided by Storage Spaces and can detect whether any mirrored copies of files become corrupt using background data scrubbing process, which periodically reads all mirror copies and verifies their checksums then replaces bad copies with good ones. Some NTFS features are not supported in ReFS, including named streams, object IDs, short names, file

compression, file level encryption (EFS), user data transactions, sparse files, hard links,extended attributes, and disk quotas.ReFS does not itself offer data deduplication. Dynamic disks with mirrored or striped volumes are replaced with mirrored or striped storage pools provided by Storage Spaces. However,

in Windows Server 2012, automated error­correction is only supported on mirrored spaces, and booting from ReFS is not supported either. ReFS was first shown in screenshots from leaked build 6.2.7955, where it went by code name

"Protogon".Support for ReFS is absent in the developer preview (build 8102). ReFS is not readable by Windows 7 or earlier.

HA Slots Calculation in VMWare

This post will help you to understand how the HA slots can be calculated.

What is SLOT?

As per VMWare’s Definition,

“A slot is a logical representation of the memory and CPU resources that satisfy the requirements for any powered-on virtual machine in the cluster.”

If you have configured reservations at VM level, It influence the HA slot calculation. Highest memory reservation and highest CPU reservation of the VM in your cluster determines the slot size for the cluster.

Here is the Example,

If you have the VM configured with the highest memory reservation of 8192 MB (8 GB) and highest CPU reservation of 4096 MHZ. among the other VM’s in the cluster, then the slot size for memory is 8192 MB and slot size for CPU is 4096 MHZ. in the cluster.

VMware Networking: Configuring and troubleshooting a vNetwork DvSwitch

I will explain how to set up a distributed vNetwork (DVN) with VMware, and how to troubleshoot your vNetwork if problems occur. In part one, I discussed the basics of virtual networks, as well as how to create and configure a standard vNetwork.

Distributed virtual networks use a distributed virtual switch (DvSwitch) to manage data transmission between virtual machines and enable guest systems to connect to physical networks. As I explained in the last post, a DvSwitch works like a global switch; all of the hosts in a datacenter can connect to a single distributed switch. A DvSwitch also enables the use of private virtual local area networks (PVLANs), which divide VLAN domains into smaller sub-domains, enabling multiple hosts to use the same address space, but exist separately, or isolated, from one another.

Like standard virtual switches, distributed virtual switches provide virtual uplinks called distributed virtual uplinks (dvUplinks). Uplinks represent physical network adapters. When creating a DvSwitch, the virtualization platform finds the maximum number of uplinks associated with a host and uses that number as a basis when setting up the dvUplinks on the switch.

DvSwitches offer more ports than do standard virtual switches; the former offers up to 6,000, compared to the latter, which provides up to 4,088. A maximum of 64 hosts can connect to a single DvSwitch and up to 16 distributed switches can be implemented per host.

DvSwitches are stored to the VMkernel, but the settings linked to the DvSwitch are contained in the vCenter database. Therefore, to create a distributed switch in VMware, you must have vCenter installed.

Creating a Distributed Virtual Switch

1. In vCenter, select “Home” and then “Networking.” Click the datacenter on which the host or hosts reside.

2. Select from the toolbar the icon to launch the Create vNetwork Distributed Switch wizard. Name the vNetwork. Click “Next.”

3. Select each host to associate with the DvSwitch, and then select which network adapters to use with each ESX/ESXi host. Choose multiple network adapters to create uplink groups and provide load balancing and fault tolerance to a host. Make sure to select the correct network adapters during the creation process, as reassigning the adapters is not a simple process. Click “Next.”

4. Click “Finish” to create the DvSwitch in vCenter.

Configuring DvSwitches and Port Groups

DvSwitches and vSwitches share most of the same options, but distributed switches offer a little bit more control over the operation of the vNetwork. To access the settings, right-click the virtual switch and then select “Edit Settings” from the context menu.

On the General tab are options to change the name of the switch and the number of dvUplinks connected to the vNetwork. On the Advanced tab are options to increase or decrease the maximum transmission unit (MTU), which limits packet size, and enable Cisco Discovery Protocol. In later versions of vSphere, you can also set up features like NetFlow, which analyzes network communications transmitted between virtual machines and physical networks; or port mirroring, which copies packets from one port to another for monitoring purposes.

To configure the port group, right-click it and then click “Edit Settings.” Most of the options match those described in the previous article, with a few exceptions:

General

Static Binding: Adheres a virtual machine to a port on the DvSwitch that remains active even when the machine is powered off

Dynamic Binding: Assigns a port to a virtual machine at the time the machine is powered on

Ephemeral: Allocates a port to a virtual machine when powered on. If the machine reboots, it loses its old port and is assigned a new one

Advanced

Override Port Policies: Overrides the settings associated with the dvUplinks

Live Port Moving: Transfer stand-alone port groups to distributed port groups, assigning settings associated with distributed port group to the stand-alone group

Configure Reset at Disconnect: Port settings are reset when a port is disconnected from a virtual machine

Port Name Format: Changes the naming convention of a port group

Troubleshooting a vSwitch or DvSwitch

Under ideal circumstances, the vNetwork will work as intended after creating and configuring the virtual switches and port groups — but certain settings can interfere with how the virtual network functions.

A virtual machine uses a port group to communicate across a network. Port groups are associated with a parent switch, so if a machine’s virtual network adapter is not assigned the correct port group, it might not link to the correct distributed or standard switch, either. Furthermore, port group names are case-sensitive, so a group named “Test,” for example, is not the same as a group named “test.”

To confirm that a virtual machine is connected to the correct port group, right-click the virtual machine and then select “Edit Settings” from the context menu. Select the appropriate port group from the drop-down menu.

While in Virtual Machine Properties, also confirm that “Connected” and “Connect at Power On” are checked under the Device Status heading. Click “OK.” Restart the virtual machine or network services if the machine has not been assigned a static IP.

If the settings for the virtual machine are correct, move on to checking the vNetwork settings for the host. Click the Configuration tab after selecting the appropriate ESX/ESXi host and then select the Networking link.

Choose “Virtual Switch” or “Distributed Virtual Switch” from the menu. Click the call-out icon for the correct switch or port group and review the settings shown in the dialog box to confirm that the network configuration is correct.

If you detected a problem with the settings, click the Properties link to make changes to the vSwitch. If you’re working with a distributed switch, follow the instructions in the above sections to change the switch’s properties. To learn more about the options available on these screens, go to the first part of this series and view “Configuring Port vSwitches and Port Groups.”

If you’re working with a vSwitch, make sure that the port group is using the original name assigned to it upon creation. If you’ve changed the name of the port group, you must edit the properties of every virtual machine originally connected to it and select the new name from the drop-down menu under Network Connection.

If your switches and port groups are all in order, the next things to check are the network adapters. If working with a standard switch, select the Network Adapters tab from the vSwitch properties window. If working with a DvSwitch, select “Manage Physical Adapters” from the Networking screen.

Confirm that the adapter is using the correct speed and duplex. If the adapter settings don’t match that of a network component or client, performance or connectivity issues can occur. Click “Edit” to change the adapter settings

VMware Networking: Configuring and troubleshooting a vNetwork

The term vNetwork refers to the technologies that VMware vSphere utilizes to integrate networking and input/output functions on an ESX/ESXi host. vSphere includes a number of features and enhancements to provide administrators thorough control over networking processes and make management of these processes simpler.

Implementing a vNetwork in ESX or ESXi is essential for enabling virtual machines to communicate with one another within a networking environment — but establishing a vNetwork on a host can be a difficult and complicated process if you don’t understand how virtual networking works in vSphere.

A virtual network is made up of virtual machines that run on a single, physical machine and transmit data to and from one another. In vSphere, a virtual switch is called a vSwitch. Virtual machines connect to the virtual ports that make up the vSwitch to create a vNetwork. The vSwitch then routes network traffic between the connected virtual machines. vSwitches can also use physical network adapters, or uplink adapters, to connect to a physical switch and associate the virtual network with a physical network.

In vSphere 4, VMware introduced an enhancement to vNetworks: the distributed virtual switch, or DvSwitch. A DvSwitch acts like a global switch, enabling administrators to associate a single switch with all ESX or ESXi hosts in a datacenter, rather than configure a vSwitch for each individual host.

vSphere separates vSwitches and DvSwitches into smaller groups called port groups. VMware uses port groups to connect virtual machines to a switch and define settings like traffic shaping, NIC teaming, load balancing, and other parameters.

Creating Standard Switches

In vSphere, vSwitches can be mapped to one network adapter or to multiple network adapters. vSwitches that have no associated network adapters can also be implemented as well.

A standard switch that has no associated adapters is called an internal vSwitch. Virtual machines connected to an internal vSwitch cannot communicate with other virtual machines outside of the host. These switches can be used to test virtual machines before mapping them to a production network. A vSwitch that is associated with two or more adapters is called a teamed vSwitch; these switches provide an added layer of protection to a network and are used for fault tolerance and load balancing.

A vSwitch starts out with 56 ports, by default, but can be configured to use up to 4,088 ports, and up to 20 network adapters can be associated with a host.

To create a standard switch in vSphere, follow the instructions below:

1. In vSphere, select the ESX or ESXi host. Click “Configuration.” Select “Networking” from the Hardware box. Click “Add Networking” to run the Add Network Wizard.

2. Select “Virtual Machine” and then click “Next.”

3. Select each network adapter to associate with the vSwitch. To create an internal vSwitch, make sure that all network adapters are deselected.

4. Create a unique name for the port group. Names are case-sensitive. (A couple things to keep mind when naming port groups: one, if the names aren’t consistent from host to host, problems will occur when migrating virtual machines or using VMotion; two, while it’s possible to rename a port group after-the-fact, virtual machines that were connected to that port group will disassociate with the switch. Therefore, to avoid potential complications, it’s best to keep track of port group names and follow a standardized naming convention.)

5. Click “Finish” to create a standard vNetwork.

Configuring vSwitches and Port Groups

After creating a vNetwork in vSphere, you can modify the vSwitch to add additional ports and change network parameters.

Add Port Groups

As I mentioned in “Creating Standard Switches,” vSwitches start out with 56 ports, but administrators can increase the port number up to 4,088. Increasing the number of ports per vSwitch is not recommended unless the operating environment requires it, as the ESX/ESXi host must be restarted after the change, and upping the port number requires additional overhead that will lead to wasted resources.

To increase the number of ports per switch:

1. Select the host and then click the Configuration tab. Click “Networking” from the Hardware box.

2. Select the Properties link. Click “vSwitch.” Click “Edit.”

3. Choose from the drop-down menu the number of ports to use with the standard switch. Click “OK.”

Set Network Policies

You can change the parameters of a vSwitch to apply global policies to the vNetwork. Port groups feature options similar to those available to switches and can be used to add greater flexibility to a virtual network, as the settings associated with the port group can act as exceptions to the global policies. You can access the network settings using the same method as described in the section above.

I’ll provide a brief overview of the options you’ll find on each tab:

Security

Promiscuous Mode: Enables a network adapter to retrieve and read all network traffic. Used for packet sniffing to troubleshoot and diagnose network issues.

MAC Address Changes: Allows the virtual MAC address associated with a virtual machine to be changed. Used to create cluster addresses for services like Network Load Balancing, used by Windows Server.

Forged Transmits: Enables a virtual machine to transmit network traffic even if the MAC address on the guest operating system doesn’t match the MAC address stored to the .vmx file (the file that holds the virtual machine’s configuration information).

Traffic Shaping

Traffic shaping is used to control bandwidth on a vNetwork. Traffic shaping focuses on outbound traffic sent from a virtual machine to the physical network; it doesn’t interfere with inbound traffic. The vast majority of administrators will never need to use this feature, particularly because traffic shaping in the vSphere environment is not dynamic and can hinder network performance.

NIC Teaming

NIC Teaming is used for fault tolerance; you can configure standby adapters to take over when the primary adapter fails.

Load Balancing: Configures how outgoing traffic is handled across multiple network adapters in a teamed vSwitch.

Network Failover Detection: Specifies how the host detects network failure.

Notify Switches: Tells the physical switches to route network traffic from virtual machines to different physical network adapters.

Failback: Specifies how the failed adapter should operate if it comes online again.

That’s it for configuring standard switches in vSphere. In part two, I’ll explain how to set up a vNetwork that runs on a distributed switch, and how to troubleshoot your vNetwork if problems occur.

Four mistakes that can kill virtual machine performance

Screensavers, managing from the console, real-time security scans and certain Windows Server power options can all undermine virtual machine performance. Here's how to avoid VM performance killers.

Ah, how I love the easy ones. In many cases, the easiest mistakes cause some of the biggest performance problems in virtualization environments. In my consulting, I've seen a few major errors that are worth sharing. Some of these may seem obvious, but consider checking your settings. You may be surprised at what you find.

Easy Mistake 1: Virtual machine screensavers

Screensavers are an absolute requirement for desktops in the hallways of our brick-and-mortar offices. They ensure that a user who walks away from his computer returns to one that has been secured against prying eyes. Screensavers can also provide protection in data centers. If screensavers on servers activate and lock the console after a few minutes of inactivity, they can protect that environment from an intruder who gains physical access.

But screensavers are a quiet consumer of processor resources. No matter how insignificant that screensaver seems, the processor power required to draw the pipes crawling across the screen or to scroll your favorite company slogan consume a percentage points of overall processor power. While that might not seem like much, consolidated virtual environments might have 10 or 15 virtual machines (VMs) running on a single virtual host. These percentage points add up when they are multiplied by the number of VMs. Even worse, if your environment uses hosted desktops through a virtual desktop implementation, this practice likely costs even more.

So turn them off. Remember that many environments enforce screensavers through group policies, which may mean an exclusion from existing group and corporate security policies.

Easy Mistake 2: Managing from the console

This second mistake is one of my favorites, because it is common among IT administrators everywhere. Do you manage your infrastructure components by remoting and logging into their individual servers? Do you run the Exchange Management Console from your Exchange server? Do you check domain name server (DNS) settings from the server's console? Do you manage Active Directory by remoting your domain controllers?

If you are, stop.

As with screensavers, this practice is a big no-no in virtualized environments because of the level of resources required to create and maintain an instance of the Explorer shell. Just logging into a virtual machine is hard on that VM's processor utilization. The process of creating a shell for the console can spike processor utilization during the login and logout process. Actually using any of the consoles on that server further consumes valuable resources. Logging in and accomplishing activity on your VMs' desktops increases the amount of memory they consume.

Microsoft provides the Remote Systems Administration Toolkit, PowerShell and VBScript, as well as many other tools for efficient virtual machine management. All these lightweight tools require much less VM capacity than a traditional login. So use them, and avoid wasting processing power and memory like an amateur.

Easy Mistake 3: Antivirus and anti-malware scanning of VM disk files

Your corporate security policy might not allow for the exclusion of Virtual Hard Disk or Virtual Machine Disk Format (VMDK) files from antivirus and anti-malware scans. But be aware that the real-time scans of such products can substantially reduce the overall performance of these files -- and, thus, their virtual machines. Since a VM's processing is highly dependent on its disk subsystem, any extra activities that slowdown that process slow it down as well.

That's not to say that VM disk files shouldn't be subject to security scanning. Scheduled scans of such files can ensure that they don't get infected, without the processing overhead of real-time scans. Also, some of today's more advanced scanning products are beginning to incorporate virtualization awareness to reduce their overall impact. If your security policy will allow it -- or if you can bribe your security officer to look the other way -- definitely consider excluding these files from your real-time scans.

Easy Mistake 4: Windows Server's power options

At conferences around the country, I've encountered the final mistake repeatedly. The default power option of Windows Server 2008 upon installation is set to "Balanced." Of the three options available -- Balanced, Power Saver and High-Performance -- this is the second of the three in terms of overall system performance. You might save a few dollars on energy, but at the cost of wasting some of the server's processing power. Resetting the radio button to the high-performance option has a noticeable effect on how well VMs will perform.

Group policy is probably the easiest way to do so. If you create a new policy and navigate to "Computer Configuration > Policies > Administrative Templates > System > Power Management," look for the policy called "Select an Active Power Plan." Configuring this policy across your server infrastructure ensures that you always run with highest performance.

If you've got an easy mistake that I've missed, I've love to hear about it. Drop by e-mail @ Ismail_syscon@yahoo.com and tell me about your own fixes for easy virtualization mistakes!

Tips for Troubleshooting VMware vSphere

Performance Monitoring Tools:-

The vSphere performance charts allow you to display useful information when you are connected either to the ESXi host directly or to the vCenter Server. The performance charts can provide a lot of useful information, even if they do not provide all of the counters that you will find with esxtop.

The host based tool esxtop provides for some inherent advantages over the vSphere performance charts and third-party tools when it comes to performance analysis. One big advantage is that esxtop incurs very little overhead on the ESXi host. Since, esxtop is lightweight and the footprint is small, it is an excellent tool to measure performance. If you have a situation where poor performance is affecting connectivity to the host, you can use resxtop (remote esxtop). Another advantage of using esxtop is you can export the data into a comma delimited file.

If You Suspect a Network Performance Issue, Check Some of the Following Metrics

If the droppedRx (receive) is greater than 0 for a host, look at the CPU utilization. Check metrics such as CPU overhead and high CPU utilization, which can cause the VM to be too busy to take on new packets or delays in receiving the packets. A possible solution is to increase CPU reservations for the VM or check the application to see if it supports adding more vCPUs.

If the droppedTx (transmit) is greater than 0, this usually means congestion at the physical layer. When a VM is transmitting packets, the packets get queued in the buffer of the virtual switch port until the packets are transmitted on the physical nic. To prevent the dropping of transmit packets, look for ways to increase the physical network capabilities, such as adding more nics or adding 10 GB Ethernet.

Make sure you have the correct network device driver installed on the VM. By default, if VMware tools is not installed or running, the Vlance network adapter will be used. Vlance is a 10Mbps NIC, which is great for older 32-bit guest operating systems but not so useful running in a 1 GB Ethernet network.

Metrics to Check for a Possible Storage Problem

esxtop/resxtop, which comes with ESXi 5, is an excellent tool to measure performance. Some of the more significant statistics are commands queued. To check these metrics, open a vSphere Management Assistant (vMA) console and start resxtop. Type d to enter the Storage Adapter screen. Type f to select the fields that you want to view. The fields to view should be A (adapter name), F (queue stats), and K (error stats).

There are other esxtop fields that can be utilized to indicate that there could be a storage problem. To identify disk-related performance problems look at throughput and latency.

Throughput fields in esxtop (READS/s + WRITES/s = I/O operations/second (IOPS):READS/s – Number of disk reads per secondWRITES/s – Number of disk writes per second

Latency fields in esxtop:

DAVG – Average delay from the adapter to the target in ms, value greater than 10 – 15 milliseconds indicates that the storage might be slow or overutilizedKAVG – Average delay from the vmkernel to the adapter in ms, value greater than 4 milliseconds indicates the VMs are attempting to send more data to storage than the storage can handle

GAVG – Average delay for the guest, which will be DAVG + KAVG = GAVG

Log Files to View in vSphere 5

All log messages are now generated by syslog, and messages can now be logged on either local and one or more remote log servers, or both. In addition, a given log server can log messages from more than one ESXi host.

To view ESXi system logs, in the vSphere Client menu bar, select View > Administration > System Logs.

/var/log/auth.log             ESXi Shell authentication success and failure

/var/log/dhclient.log      DHCP client service

/var/log/esxupdate.log ESXi patches and updates log

/var/log/hostd.log           Host management service logs

/var/log/shell.log             ESXi Shell usage, including enable/disable and every command entered

/var/log/sysboot.log      VMkernel startup and module loading

/var/log/syslog.log          Management service initialization, watchdogs, scheduled tasks, DCUI

/var/log/usb.log               USB device arbitration events, such as discovery and pass-through to VM

/var/log/vob.log               VMkernel Observation events, similar to vob.component.event

/var/log/vmkernel.log   Core VMkernel logs (devices, storagage/network device/driver events, and VM

startup.

/var/log/vmkwarning.log             VMkernel Warning and Alert log messages.

/var/log/vmksummary.log           ESXi startup/shutdown, uptime, VMs running, and service resource consumption

Logs from vCenter Server Components on ESXi 5

/var/log/vpxa.log             vCenter vpxa agent logs

/var/log/fdm.log              High Availability logs, produced by the Fault Domain Manager (FDM) service

Last-Level Cache (LLC) Performance Issue

The ESXi CPU scheduler, by default, tries to place the vCPUs of a Symmetric Multiprocessor (SMP) VM into as much Last-Level Cache (LLC) as possible. ESXi, by default, is going to place as many vCPUs of a SMP VM into as many of the L LLCs as possible. Therefore, ESXi is going to attempt to spread out the cycle, and find space to run the workload. If you are running a very

CPU-intensive workload, you might benefit from setting up a clone of the application VM. Then turn on the LLC setting below and test the cloned application to see if there is a performance increase. If the modification works, the CPU scheduler is going to attempt to consolidate the vSMP VM into one CPU package, thus one shared LLC pool. Therefore, the CPU scheduler will now attempt to run the VM on the same package more than it would otherwise.

Using the vSphere client:

Power off the VM.

Right click the VM and select Edit Settings.

Select the Options tab.

Under Advanced, click General, and on the right click the configuration Parameters button.

Click Add Row.

Add sched.cpu.vsmpConsolidate set to true.

Power on the VM.

From the command line interface:

Power off the VM.

Add the following line into the configuration file (.vmx) of the VM.

sched.cpu.vsmpConsolidate = “true”.

Power on the VM.

Cannot Migrate a VM Using VMotion

Check the ESX(i) hosts to make sure all of the requirements have been met. Then check to make sure that the CPU is compatible. If the VM is running a 64-bit operating system, the problem might be that the source machine has Intel Virtualization Technology (VT) enabled in the BIOS, and the destination host does not have VT enabled in the BIOS. If this is the case, you will have to make a change in the BIOS so both hosts match. Also, both hosts must have a VMkernel port on the same LAN. The IP address and subnet mask should match the network configuration for VMKernel gateway.

You could run from command line:

# vmkping <Destination_IP _address> to test the VMkernel TCP/IP stack.

Any VLAN settings should match the VLAN configuration of the local LAN. VMkernel ports should have the check box VMotion enabled. There should be no router separating the hosts.

Check the VMs to make sure all of the requirements have been met.

Check that there are no local devices connected to the VM.

Check CD-ROM mappings to any ISO file on local storage, Floppy, SCSI, USB, CPU affinity, .vswp files stored on local storage.

Check that the VM has enough CPU and memory resources on the destination host

Exploring the vSphere Web Client and Configuring Active Directory Permissions