Downgrading the virtual machine hardware version in ESX/ESXi (1028019)

Symptoms

• A virtual machine does not boot after upgrading the virtual hardware version to 7, 8, 9, or 10.
• You cannot migrate or power on a virtual machine created on an newer version of ESX/ESXi to an older version.

Purpose

This article provides steps to downgrade virtual machine hardware from a newer version to an older version.

Resolution

To downgrade virtual machine hardware, power off the virtual machine and perform one of these options:

• Revert to a snapshot created before upgrading the virtual machine hardware. For more information, see Reverting Snapshots in thevSphere Virtual Machine Administration Guide. 
  
• Use VMware vCenter Converter Standalone and select the required virtual hardware version in the Specify Destination wizard. For more information, see Customize the Location of the Destination Virtual Machine in the VMware vCenter Converter Installation and Administration Guide or Customize the Location of the Destination Virtual Machine in your version of the VMware vCenter Converter Standalone User's Guide.
  
• Create a new virtual machine with required hardware version and attach the existing disk from the virtual machine.

Source:-

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1028019&src=vmw_so_vex_ragga_1012

vMotion migrations fail when using multiple VMkernel ports for vMotion in different IP subnets (2052092)

Symptoms

• When you attempt to migrate a virtual machine using vMotion and each of the VMkernel ports used for vMotion are in different VLANs or IP subnets, the operation fails.
• You see the error:
  
  The vMotion migrations failed because the ESX hosts were not able to connect over the vMotion network. Check the vMotion network settings and physical network configuration.
  
• When this issue occurs, the host has multiple VMkernel ports configured for vMotion.

Cause

There are two common scenarios that may warrant the use of multiple VMkernel ports for vMotion services:

• Multiple-NIC vMotion (introduced in vSphere 5.0): Multiple-NIC vMotion has specific requirements that must be adhered to for it to work correctly. In this case, all of the VMkernel ports configured for use with Multiple-NIC vMotion must be in the same IP subnet. If VMkernel ports are separated across subnets or VLANs, the service will not work correctly.
  
• Joining two separate environments with different vMotion networks: In this situation, a single host may have a VMkernel port in each of the two vMotion IP subnets/VLANs. If multiple VMkernel ports are selected for vMotion use, vMotion migrations may fail as the host can theoretically use either of the two VMkernel ports for vMotion purposes, and a connection may not be able to be established to the other hosts. The ability to select two VMkernel ports for vMotion purposes was introduced in vSphere 5.0 for Multiple-NIC vMotion purposes only.

Note: In ESXi/ESX 4.1 and earlier, it is not possible to select more than one VMkernel port for vMotion use.

Resolution

When using Multiple-NIC vMotion in vSphere 5.x, ensure that all VMkernel ports configured are in the same IP subnet/VLAN on all hosts. For more information on configuring Multiple-NIC vMotion, see Multiple-NIC vMotion in vSphere 5 (2007467).

Do not use multiple VMkernel ports that have been configured for vMotion for any purpose other than Multiple-NIC vMotion. When using a single VMkernel port for vMotion, all hosts participating in vMotion migrations must also have their vMotion VMkernel interface in the same IP subnet/VLAN.

Source:-

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2052092&src=vmw_so_vex_ragga_1012

How to the change default compatibility setting of a VM?

You can set the default compatibility for virtual machine creation on the host, cluster, or datacenter. These options ensure that when virtual machines are added to an existing vSphere environment, they will be compatible with the host versions that reside there.

The following conditions apply:

■	To set the default compatibility on the cluster, the cluster must contain hosts that are connected and not in maintenance mode.
■	A default compatibility setting on the host overrides a default cluster or datacenter setting.
■	A default compatibility setting on the cluster overrides a default datacenter setting.

Prerequisites

Required privileges:

■	On the host or cluster: Host.Inventory.Modify cluster
■	On the datacenter: Datacenter.Reconfigure datacenter

Procedure

♦

Select a host, cluster, or datacenter in the inventory. Option Action Host a Click the Manage tab, and click Settings. b In the Virtual Machines section, select Default VM Compatibility and click Edit. c Select the compatibility from the drop-down menu and click OK. Cluster a Click the Manage tab and click Settings. b Click the Edit button next to Default VM Compatibility. c Select the compatibility from the drop-down menu and click OK. Datacenter a Right-click the datacenter and select Edit Default VM Compatibility. b Select the compatibility from the drop-down menu and click OK.

When you create a virtual machine on one of these objects, the default compatibility setting is used.

1. Right Click on ESXi Host ---> All vCenter Actions ---> Edit defaultVMCompatibility

2. Then Select the Compatibility and Click on OK

 

What is Beacon Probing?

If you’ve built a virtual infrastructure you’ve probably had to decide whether or not to use Beacon Probing when setting up your vSwitch uplink ports. But what is it, and why do we need it?

Let me propose a scenario. Assume that we have a virtual switch with three uplinks, and one of those uplinks fails.

 

 

If the uplinks are setup correctly, they will see the failed uplink and start sending their frames over the other active uplinks. This is standard network fault tolerance from vSphere.

But what happens if the link failure happens further upstream like between an access switch and the core switch?

 

 

Under normal circumstances the ESXi uplink will still show a connection and route frames to physical switch (A), even though this physical switch’s upstream switch link is down. This situation could be just as bad as having an uplink down on the ESXi host, but the ESXi server is unaware of the link failure.

Depending on how your network is setup, you could be using Link-State Tracking on your access switches which means that if the link between switch A and your core switch is down, it will put all of the downstream ports into an error state. If this is the case, the ESXi server will be able to determine that there is a failure and to use the other uplink ports.
However, if your network isn’t using Link-State Tracking and you are in a situation where an upstream switch could cause a failure, it might be a good idea to use beacon probing.

Beacon probing is a software alternative provided by VMware vSphere, to detect uplink failures. During the Beacon Probing process the ESXi host periodically sends out a broadcast packet which vSphere expects will be forwarded by all of the physical switches. The ESXi server then listens on all of the other NICs in the team to hear that broadcast frame. If the other NICs don’t hear three consecutive broadcasts then ESXi will mark the Nic with the problem path as failed.

 

For More Info refer Vmware KB 1005577

*Images used here are the VMware Patented Images, Special thanks to VMware  for the Images.*

Hardware Features Available with Virtual Machine Compatibility Settings

The virtual machine compatibility setting determines the virtual hardware available to the virtual machine, which corresponds to the physical hardware available on the host. You can review and compare the hardware available for different compatibility levels to help you determine whether to upgrade the virtual machines in your environment.

Thanks to Vmware Documentation

Supported Features for Virtual Machine Compatibility

Feature	ESXi 5.5 and later	ESXi 5.1 and later	ESXi 5.0 and later	ESX/ESXi 4.x and later	ESX/ESXi 3.5 and later
Hardware version	10	9	8	7	4
Maximum memory (MB)	1035264	1035264	1035264	261120	65532
Maximum number of logical processors	64	64	32	8	4
Maximum number of cores (virtual CPUs) per socket	64	64	32	8	1
Maximum SCSI adapters	4	4	4	4	4
Bus Logic adapters	Y	Y	Y	Y	Y
LSI Logic adapters	Y	Y	Y	Y	Y
LSI Logic SAS adapters	Y	Y	Y	Y	N
VMware Paravirtual controllers	Y	Y	Y	Y	N
SATA controllers	4	N	N	N	N
Virtual SCSI disk	Y	Y	Y	Y	Y
SCSI passthrough	Y	Y	Y	Y	Y
SCSI hot plug support	Y	Y	Y	Y	Y
IDE nodes	Y	Y	Y	Y	Y
Virtual IDE disk	Y	Y	Y	Y	N
Virtual IDE CD-ROMs	Y	Y	Y	Y	Y
IDE hot plug support	N	N	N	N	N
Maximum NICs	10	10	10	10	4
PCNet32	Y	Y	Y	Y	Y
VMXNet	Y	Y	Y	Y	Y
VMXNet2	Y	Y	Y	Y	Y
VMXNet3	Y	Y	Y	Y	N
E1000	Y	Y	Y	Y	Y
E1000e	Y	Y	Y	N	N
USB 1.x and 2.0	Y	Y	Y	Y	N
USB 3.0	Y	Y	Y	N	N
Maximum video memory (KB)	524288	524288	131072	131072	131072
SVGA displays	10	10	10	10	1
SVGA 3D hardware acceleration	Y	Y	Y	N	N
VMCI	Y	Y	Y	Y	N
PCI passthrough	6	6	6	6	0
PCI Hot plug support	Y	Y	Y	Y	N
Nested HV support	Y	Y	N	N	N
vPMC support	Y	Y	N	N	N
Serial ports	4	4	4	4	4
Parallel ports	3	3	3	3	3
Floppy devices	2	2	2	2	2