Vsphere Challenge Lab

VSphere Challenge Lab
Challenge #1: Can't vMotion a VM

1. With vMotion, you can change the host on which a virtual machine is running, or
you can change both the host and the datastore of the virtual machine.
2. When you migrate virtual machines with vMotion and choose to change only the
host, the entire state of the virtual machine is moved to the new host. The
associated virtual disk remains in the same location on storage that is shared
between the two hosts. When you choose to change both the host and the
datastore, the virtual machine state is moved to a new host and the virtual disk is
moved to another datastore.
3. When you migrate a virtual machine with vMotion, the new host for the virtual
machine must meet compatibility requirements so that the migration can
proceed.
Migration with vMotion occurs in three stages:
1. When the migration with vMotion is requested, vCenter Server verifies that the
Existing virtual machine is in a stable state with its current host.
2. The virtual machine state information (memory, registers, and network
Connections) is copied to the target host.
3. The virtual machine resumes its activities on the new host.
If errors occur during migration, the virtual machine reverts to its original state
and location.
If we unable to migrate VM into another host, it may be configuration problem.

And may be the host does not have free CPU and deduce the vCPU in VM and
try to move the VM.
Challenge #2: Can't ping a VM

• To ensure a stable connection between vCenter Server, ESXi, and other
products and services, do not set connection limits and timeouts between the
products. Setting limits and timeouts can affect the packet flow and cause
services interruption.
• Isolate from one another the networks for host management, vSphere vMotion,
vSphere FT, and so on to improve security and performance.
• Dedicate a separate physical NIC to a group of virtual machines, or use
Network I/O Control and traffic shaping to guarantee bandwidth to the virtual
machines. This separation also enables distributing a portion of the total
networking workload across multiple CPUs. The isolated virtual machines can
then better handle application traffic, for example, from a Web client.
• To physically separate network services and to dedicate a particular set of NICs

to a specific network service, create a vSphere Standard Switch or vSphere
Distributed Switch for each service. If this is not possible, separate network
Services on a single switch by attaching them to port groups with different VLAN
IDs. In either case, verify with your network administrator that the networks or
VLANs you choose are isolated from the rest of your environment and that no
Routers connect them.
• Keep the vSphere vMotion connection on a separate network. When migration

With vMotion occurs, the contents of the guest operating systems memory is
Transmitted over the network. You can do this either by using VLANs to segment
a single physical network or by using separate physical networks (the latter is
Preferable).
• For migration across IP subnets and for using separate pools of buffer and
Sockets, place traffic for vMotion on the vMotion TCP/IP stack, and traffic for
Migration of powered-off virtual machines and cloning on the Provisioning TCP/IP
Stack.
• You can add and remove network adapters from a standard or distributed
switch without affecting the virtual machines or the network service that is
running behind that switch. If you remove all the running hardware, the virtual
machines can still communicate among themselves. If you leave one network
adapter intact, all the virtual machines can still connect with the physical network.
• To protect your most sensitive virtual machines, deploy firewalls in virtual

Machines that route between virtual networks with uplinks to physical networks
And pure virtual networks with no uplinks. Or you can consider VMware NSX for
The Micro-Segmentation or Isolation of those virtual machines.
• For best performance, use VMXNET 3 virtual machine NICs.
• Physical network adapters connected to the same vSphere Standard Switch or

VSphere Distributed Switch should also be connected to the same physical
Network.
• Configure the same MTU on all VMkernel network adapters in a vSphere

Distributed Switch. If several VMkernel network adapters, configured with
Different MTUs, are connected to vSphere distributed switches, you might
Experience network connectivity problems.
Basic Operations Management tasks.
VM Performance issue.
Temporary spikes in CPU usage indicate that you are making the best use of
CPU resources. Consistently high CPU usage might indicate a problem.
Host machine memory, A virtual machine's memory size must be slightly larger
than the average guest memory usage.
Use the disk charts to monitor average disk loads and to determine trends in disk
Usage. For example, you might notice a performance degradation with
Applications that frequently read from and write to the hard disk. If you see a
Spike in the number of disk read/write requests, check if any such applications
We’re running at that time.
Dropped network packets indicate a bottleneck in the network. Slow network

performance can be a sign of load-balancing problems.
Host Performance issue.
• Host CPU usage constantly is high. A high CPU usage value can lead to increased
ready time and processor queuing of the virtual machines on the host.
• Virtual machine CPU usage is above 90% and the CPU ready value is above 20%.
Application performance is impacted.
• The host probably is lacking the CPU resources required to meet the demand.
• There might be too many virtual CPUs relative to the number of regular CPUs.
• There might be an IO storage or networking operation that places the CPU in a wait
state.
• The Guest OS generates too much load for the CPU.
Fix
• Verify that VMware Tools is installed on every virtual machine on the host.
• Compare the CPU usage value of a virtual machine with the CPU usage of other
virtual machines on the host or in the resource pool. The stacked bar chart on
the host's Virtual Machine view shows the CPU usage for all virtual machines on
the host.
• Determine whether the high ready time for the virtual machine resulted from its
CPU usage time reaching the CPU limit setting. If so, increase the CPU limit on
the virtual machine.
• Increase the CPU shares to give the virtual machine more opportunities to run.
The total ready time on the host might remain at the same level if the host
system is constrained by CPU. If the host ready time doesn't decrease, set the
CPU reservations for high-priority virtual machines to guarantee that they receive
the required CPU cycles.
• Increase the amount of memory allocated to the virtual machine. This action
decreases disk and or network activity for applications that cache. This might
lower disk I/O and reduce the need for the host to virtualize the hardware. Virtual
machines with smaller resource allocations generally accumulate more CPU ready
time.
• Reduce the number of virtual CPUs on a virtual machine to only the number
required to execute the workload. For example, a single-threaded application on
a four-way virtual machine only benefits from a single vCPU. But the hypervisor's
maintenance of the three idle vCPUs takes CPU cycles that could be used for
other work.
• If the host is not already in a DRS cluster, add it to one. If the host is in a DRS
cluster, increase the number of hosts and migrate one or more virtual machines
onto the new host.
• Upgrade the physical CPUs or cores on the host if necessary.
• Use the newest version of hypervisor software, and enable CPU-saving features
such as TCP Segmentation Offload, large memory pages, and jumbo frames.

Vsphere Challenge Lab

Uploaded by

Copyright:

Available Formats

Vsphere Challenge Lab

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Vsphere Challenge Lab

Uploaded by

Copyright:

Available Formats

VSphere Challenge Lab

Challenge #1: Can't vMotion a VM

Migration with vMotion occurs in three stages:

If we unable to migrate VM into another host, it may be configuration problem.

Challenge #2: Can't ping a VM

• To physically separate network services and to dedicate a particular set of NICs

• Keep the vSphere vMotion connection on a separate network. When migration

• To protect your most sensitive virtual machines, deploy firewalls in virtual

• For best performance, use VMXNET 3 virtual machine NICs.

• Physical network adapters connected to the same vSphere Standard Switch or

• Configure the same MTU on all VMkernel network adapters in a vSphere

Dropped network packets indicate a bottleneck in the network. Slow network

Host Performance issue.

• The Guest OS generates too much load for the CPU.

• Upgrade the physical CPUs or cores on the host if necessary.

You might also like