Issue 1: VM live
migration takes 15-20 minutes to complete the vMotion from one host to another
host.
Background: 1 VC Server, 2 Hosts part of HA and DRS
enabled Cluster.
Reason for the Issue: Since the VMs vMotion traffic
had to reach the external Switch for vMotion to happen, it was taking longer
time than expected. Since, we introduced cross over cable connectivity for
vMotion traffic, it was internal, and so the vMotion happened in seconds.
Solution: Introduced Cross over cable connectivity
for vMotion Traffic.
Steps:
1.
Add a physical NIC and attach the cross over
cable.
2.
Create a vSwitch and select the physical NIC
which has cross over cable attached.
3.
Create a VMKernel port group for vMotion.
4.
Perform vMotion.
Issue: the CPU Performance
was poor for 2 of the Virtual Machines in the Host in a HA enabled Cluster.
Reason for the Issue: The hyper
threading was enabled for the Host. Both the VMs were HIGH priority VMs and
were always utilizing max CPU. The CPU
affinity was setup for the both the VMs. Unfortunately, The 1 st VM was pinned
to CPU0 (Logical Processor1) and 2 nd VM was pinned to CPU1 (Logical Processor
2). Basically, both the HIGH priority VMs were pinned to the same PHYSICAL
CORE.As a result, the CPU Utilization was very poor.
Solution: Pinned the 2 nd VM to another Physical CPU, in
turn the CPU utilization was improved a lot better.
Troubleshooting Steps:
1.
Analyzed the VM’s Task Manager.
2.
Analyzed the ESXTOP performance statistics.
3.
The results were strange when checking the
ESXTOP Results. CPU USED % was very LOW compared to CPU UTIL %. As both the
CPUs were utilizing CPU all the time, the CPU UTIL % was HIGHER. Since the CPU
was BUSY all the time scheduling CPU cycles for the both the VMs, both the VMs
were unable to use the CPU resource to its maximum. Finally all these things
resulted in VMs poor CPU performance.
Issue: One of the
VM’s didn’t restart when the host fails though it’s part of HA in Vmware 3.5?
Note: In vSphere 4, this has been improved with the
introduction of the concept “DRS Over reservation”. As part of DRS over
reservation, the DRS will create a ghost VM in one of the hosts in the cluster
identical to the VM which didn’t restart due to HIGH Reservation. And then the
DRS will automatically load balance the cluster (defragment the resources) and
accommodate the HIGH Reservation n that host.
Reason for the Issue: The Admission control was enabled and the
Admission control policy we used was “The % of the cluster resources reserved
as failover spare capacity”. The VM had huge CPU and Memory reservation. The
aggregate % for the cluster was HIGH but that resources were fragmented and
none of hosts had enough resources to accommodate the VM.
Solution:
1.
Reduced the Memory and CPU Reservation for other
VMs that didn’t require.
Troubleshooting Steps tried:
1.
Select the Cluster and select the Summary tab.
2.
See the VMware HA stuff in the right hand side.
3.
Also, click on Advanced RUN TIME info to see
more info on % of the cluster resources available
Issue: vMotion
didn’t happen at all between the hosts in vSphere 4.1 Update 2.
Reason for the Issue: The value set for “Migrate” in Advanced
Options was 0.
Solution: Changed the value for “Migrate” in Advanced
Options from 0 to 1.
Troubleshooting Steps tried:
1.
Restarted the Management agents on an ESX Server
2.
Checked the VMKernel networking configuration.
3.
Tested the VMKernel and Service Console network
connectivity with the vmkping and ping command
4.
Verified that Name Resolution and Time Synch were
valid on ESX.
5.
Both the ESX were able to see the shared
storage, enough resources were available.
6.
There was no CD ROM or floppy drive connected to
the VM.
Issue : On-Board
NICs will be missing in HP Servers with vSphere 4.1 Update 2
Solution: Separate ISO Image was available for HP
Servers. VMware ISO image didn’t have the drivers required for On-board NICs.
No comments:
Post a Comment