All About : Fault Tolerance

                                 Fault Tolerence 

What is VMware Fault Tolerance?

VMware Fault Tolerance is a component of VMware vSphere and it provides continuous availability to applications by preventing downtime and data loss of Virtual machines in the event of ESXi server failures.


What is the name of the technology used by VMware FT?

VMware FT using a technology called vLockstep technology

What are requirements and Limitattions for ESX hosts & infrastructure components to run FT protected virtual machines in Vsphere 4 & 4.1?

1. VMware FT is available after versions of vSphere Advanced version (Advanced, Enterprise, Enterprise Plus)

2.Hardware Virtualization should be enabled in the BIOS

3.CPU should be compatible with FT. Please refer VMware site for supported processors.

4.FT enabled virtual machines should be placed in Shared storage (FC,ISCSI or NFS)

5. FT virtual machines should be placed in HA enabled cluster

6. FT cannot be used with DRS in vsphere 4.0 but FT is fully now integrated with DRS from vSphere 4.1

7. In vsphere 4.0, primary and secondary ESX should have same ESX version and patch level. This   limitation is no more from vSphere 4.1. The primary and secondary ESX need not be at same build and
patch level because FT has its own version associated with it.

8. Only 4 FT protetcted virtual machines is allowed per ESX/ESXi host.

9. vMotion and FT Logging should be enabled in vmkernel portgroup of the virtual machine (Separate NIC for vMotion & FT logging is recommeneded along with NIC teaming)

10. Host certificate checking should be enabled (enabled by default)

11. Dedicated 10 GB ethrenet card between ESX servers will give best performance results.

12.  FT ports 8100, 8200 (Outgoing TCP, incoming and outgoing UDP) must be open if any firewall exist between ESX hosts

13. Minimum of 3 hosts in HA enabled cluster is  the requirement for running FT protected virtual machines but 2 hosts is the strong requirement.

14. FT virtual Machines cannot be backed up using the backup technology like (VCB, vmware data recovery),which uses snapshot feature.

15. NPIV (N-PortID Virtualization) is not supported with vmware FT

16. USe Redundancy at all layers(like NIC teaming, multiple network switches, and storage multipathing) to fully utilize the FT features.

17. MSCS clustering is not supported with VMware Fault Tolerance.

18. In vSphere 4.0, Manual vmotion is allowed but automatic load balance using vmotion by DRS is fully supported from vSphere 4.1

19. We cannot use storage vmotion (SVmotion) to migrate FT protected virtual machines from one datastore to another.

20. EVC (enhanced vmotion compatibility) should be enabled in DRS cluster to utilize the automatic load balancing feature provided by DRS for the FT protected virtual machine.



What are Requirements and Limitations for Virtual Machine to Enable FT ?

1. FT protected virtual machine should be running on the supported Guest operating system

2. FT protected virtual machine's guest operating system and processor combination must be supported by Fault Tolerance. Please refer VMware Site for Supported Guest OS and CPU combination

3.Physical RDM is not supported for FT protected virtual machines but virtual mode RDM is supported

4.FT protected virtual machine should have eagerzeroed Thick disks. Virtual machine with  thin provisioned disk will be automatically converted to thick disk, while enabling FT for the virtual machine. Make sure enough free space is avaialble in the datastore for this operation.

5.SMP (symmetric multiprocessing) is not supported. Only 1 VCPU per virtual mahcine is allowed.

6.Only 64 GB of  maximum RAM is allowed for the FT VM's.

7.Hot add and remove devices are not allowed for FT protected VM's.

8.NPIV is not supported for FT VM's.

9.USB Passthough and VMDirectPath should not be enabled for FT VM's and it is not supported.

10. USB and Sound devices are not supported for FT VM's.

11.Virtual Machine snapshot is not supported for FT protected VM's.FT virtual Machines cannot be backed up using the backup technology like (VCB, vmware data recovery),which uses snapshot feature.

12. Virtual machine hardware version should be 7 and above

13.Paravirtualized Guest OS and paravirtualized scsi adapter for FT protected virtual machine is not supported.

14.Windows Guest OS should not be using MSCS (Microsoft Cluster services) to Protect the Virtual Machine using FT.

15.FT Protected virtual machines should not be HA disbaled by Virtual Machine level HA settings.

16. FT protected virtual machines cannot be migrated using svmotion. If want to migrate FT protected virtual  machine, disable the FT on the VM, Migrate the VM using svmotion and re-enable the FT.

17. IPv6 is not supported by VMware HA so, it is not supported for FT.


What is FT Logging Traffic?

FT logging is the one of option in VMkernel port setting which is similar to enable vmotion option in the vmkernel port. when FT is enabled for the virtual machine, all the inputs (disk read.. wirte,etc..) of the primary virtual machine are recorded and sent to the secondary VM over via FT logging enabled VMkernel port.

All About vMotion !!!

Vmotion

1.What is vMotion?

Live migration of a virtual machine from one ESX server to another with Zero downtime called vMotion. VMs disk files stay where they are (on shared storage)


2. What are the use cases of vMotion ?

•    Balance the load on ESX servers (DRS)
•    Save power by shutting down ESX using DPM
•     Perform patching and maintenance on ESX server (Update Manager or HW maintenance)



3.  What are Pre-requisites for the vMotion to Work?

•      ESX host must be licensed for VMotion
•     ESX  servers must be configured with vMotion Enabled VMkernel Ports.  
•     ESX servers must have compatible CPU's for the vMotion to work
•     ESX servers should have Shared storage (FB, iSCSI or NFS) and VM's should be stored on that    storage.
•     ESX servers should have exact similar network & network names


4. What are the Limitations of vMotion?

•       Virtual Machine cannot be migrated with VMotion unless the destination swapfile location is the
              Same as the source swapfile location. As a best practice, Place the virtual machine swap files with
              the virtual  machine configuration file.
•     Virtual machines configured with the Raw Device Mapping(RDM) for clustering features using
              vMotion
•     VM cannot be connected to a CD-ROM or floppy drive that is using an ISO or floppy image
             restored on a drive that is local to the host server. The device should be disconnected before
             initiating the vMotion.
•      Virtual Machine affinity must not be set (aka, bound to physical CPUs).


5. Steps involved in VMWare vMotion ?
 
• A request has been made that VM-1 should be migrated (or "VMotioned") from ESX A to ESX B.
• VM-1's memory is pre-copied from ESX A to ESX B while ongoing changes are written to a memory
        bitmap on ESX A.
• VM-1 is quiesced on ESX A and VM-1's memory bitmap is copied to ESX B.
• VM-1 is started on ESX B and all access to VM-1 is now directed to the copy running on ESX B.
• The rest of VM-1's memory is copied from ESX A all the while memory is being read and written from
        VM-1 on ESX A when applications attempt to access that memory on VM-1 on ESX B.
• If the migration is successful, VM-1 is unregistered on ESX A.


So its all about vmotion.. Hope you find this blog benificial.. Thanks!!

Troubleshooting while doing Physical to Virtual conversion (P2V)

Troubleshooting while doing Physical to Virtual conversion

Conversions sometimes fail no matter how careful you are preparing the server. The failure can occur at various stages in the conversion process; these stages are based on the task bar percent and are estimated values.

1.      Creation of the target virtual machine (VM) (0%-5%)
2.      Preparing to Clone the Disk (5%-6%)
3.      Cloning (6%-95%)
4.      Post-cloning (95%-97%)
5.      Customization/Reconfig (97%-99%)
6.      Install Tools/Power On (99%-100%)

The conversion process may fail at any stage, but if it's going to fail, it will typically fail at 97%. Converter creates a detailed log file during the conversion process which will contain exact errors pertaining to why the conversion failed. This log file is located on the server you are converting that is running the Converter agent, and is usually named vmware-converter-0.log and is located in the C:\Windows\temp\vmware-temp directory. Open this log file and scroll towards the bottom and look for failure errors. Once the process fails, Converter will destroy the VM that it created automatically.

One clue to determine which stage it failed at is how fast it gets to 97%. If it jumps to 97% quickly and fails, this usually indicates a problem with network ports, DNS resolution or a required Windows service that is not running. Here are some things to try to resolve these types of problems.

1.      If you used a hostname to choose your VC/ESX server destination make sure you can resolve it on your source server. Also try using the FQDN of the server instead of the short name.


2.      On the source server make sure the Workstation, Server, TCP/IP NetBIOS Helper and VMware Converter services are running. On Windows XP and 2003 servers make sure the Volume Shadow Copy service is not disabled, by default it should be set to Manual. This service does not need to be running for Converter to work.


3.      Use telnet to see if you can connect to the required ports on the VC/ESX servers. From the source server type "telnet 902". You should get a response back from the VC/ESX server, also do this on port 443.


4.      Try rebooting the source server, this is a requirement for Windows NT and 2000 servers.


If it takes a long time to get to 97%, then typically the clone failed during the data cloning process or the post-cloning procedures. Some possible causes of these types of failures can be lost network connectivity between the servers, excessive network errors and source disk problems. Here are some steps to try to resolve these types of problems.

1.      Verify network speed/duplex settings match on your source server's NIC and the physical switch port it is connected to.


2.      If you have OS mirroring enabled, break the mirrors.


3.      Clean-up your boot.ini file and make sure it is correct.


4.      Make sure you are using the latest version of Converter. Earlier versions fail if the source server has dynamic disks.


5.      Run chkdsk on your source server to verify file system integrity.


6.      Ensure you have at least 200 MB of free disk on the source server.


7.      If your source server has more then two serial (COM) ports, edit the registry and look for HKLM\HARDWARE\DEVICEMAP\SERIALCOM and remove any ports above serial port 2. You can export the key before you do this and re-import after the conversion is completed if needed.


Finally, if your conversion completes successfully but your server will not boot (or boots to a blue screen) you can try the following things to fix it.

1.      Edit the boot.ini on the newly created VM to make sure the disks are in the proper order. Sometimes the boot disk will not be listed as the first partition. To do this, simply use a working VM as a helper and add an additional virtual hard disk. Browse to the newly created VM's disk file. You can then browse that disk and edit the boot.ini file. When complete, remove the disk from the helper VM. You can also try running Converter again and selecting "Configure Machine" and select your newly created VM. Run through the Wizard, and (when complete) try powering it on again.


2.      Verify you are using the proper SCSI controller for your virtual disk (BusLogic or LSI Logic).


3.      Boot the VM in safe mode to see if any hardware specific services/drivers are loading.

Enhancing performance in a new virtual machine
When your conversion completes, there are several steps you should to do clean your new VM up so it will perform better.

       

1.      Edit the VM's hardware. Remove all unnecessary hardware, including floppy drives and serial, parallel and USB ports. You should only give the VM as much RAM as it needs. Reduce it if you can. Most VM's run better with one vCPU, so consider reducing the number of CPUs if you came from a SMP physical server.


2.      Power on the VM, wait a few minutes to let it discover all it's new hardware then reboot it.


3.      Check the server HAL, if you came from a multiple CPU physical system and have a single CPU VM you need to go into Device Manager and edit the CPU (Computer). Select Update Driver, say No to Windows Update, select Install from List, select Don't Search and select ACPI Uniprocessor instead of ACPI Multiprocessor.


4.      Remove any hardware specific applications and drivers.


5.      Finally, my most important tip: Remove all non-present hardware devices. These are hardware devices that were removed from the system without having been uninstalled and are a by-product of the conversion. These devices are not physically present in the system anymore, but Windows treats them as they were there and devotes system resources to them. They can also cause conflicts when trying to set your new network adapter's IP address to the same address of the source server.
The reason for this is that the old NIC still exists as non-present hardware with an IP address. There will be dozens of non-present hardware devices left after the conversion. To remove them all simply go to a CMD prompt and type SET DEVMGR_SHOW_NONPRESENT_DEVICES=1. Then in the same CMD window type DEVMGMT.MSC and then select Show Hidden Devices when the Device Manager window opens. As you expand each hardware category you will see lots of non-present devices, indicated by grayed out icons. Right-click on each and select uninstall. Reboot once you have removed them all.

Hopefully the information in these articles will help you in converting your physical servers to virtual ones.

Favorite question of interviewer : Difference between Esxi 4 & esxi5

Hi Guys,

A really interesting topic .. For which i was searched a lot . And ofcourse this is the most favourire question now a days in vmware interviewer and terror for candidates.. So i bring some points here .. Which will surely help you...

Features	vSphere 4.1	vSphere 5.0
Hypervisor	ESX & ESXi	Only ESXi
VMA	Yes VMA 4.1	Yes VMA 5
HA Agent	AAM Automatic Availability Manager	FDM Fault Domain Manager
HA Host Approach	Primary & Secondary	Master & Slave
HA Failure Detection	Management N/W	Management N/W and Storage communication
HA Log File	/etc/opt/vmware/AAM	/etc/opt/vmware/FDM
DNS Dependent on DNS	Yes	NO
Host UEFI boot support	NO	boot systems from hard drives, CD/DVD drives, or USB media
Storage DRS	Not Available	Yes
VM Affinity & Anti-Affinity	Available	Available
VMDK  Affinity & Anti-Affinity	Not Available	Available
Profile driven storage	Not Available	Available
VMFS version	VMFS-3	VMFS-5
VSphere Storage Appliance	Not Available	Available
Iscsi  Port Binding	Can be only done via Cli using ESXCLI	Configure dependent hardware iSCSI and software iSCSI adapters along with the network configurations and port binding in a single dialog  box using the vSphere Client.
Storage I/O control for NFS	Fiber Channel	Fiber Channel & NFS
Storage Vmotion Snapshot support	VM with Snapshot cannot be migrated using Storage vMotion	VM with Snapshot can be migrated using Storage vMotion
Swap to SSD	NO	Yes
Network I/O control	Yes	Yes with enhancement
ESXi firewall	Not Available	Yes
vCenter Linux Support	Not Available	vCenter Virtual Appliance
vSphere Full Client	Yes	Yes
vSphere Web Client	Yes	yes with lot of improvements
VM Hardware Version	7	8
Virtual CPU per VM	8 vCpu	32 vCpu
Virtual Machine RAM	255 GB	1 TB of vRAM
VM Swapfile size	255 GB	1 TB
Support for Client connected USB	Not Available	Yes
Non Hardware Accelerated 3D grpahics support	Not Available	Yes
UEFI Virtual BIOS	Not Available	Yes
VMware Tools Version	4.1	5
Mutlicore vCpu	Not Available	Yes  configure at VM setting
MAC OS Guest Support	Not Available	Apple Mac OS X Server 10.6
Smart card reader support for VM	Not Available	Yes
Auto Deploy	Not Available	Yes
Image Builder	Not Available	Yes
VM's per host	320	512
Max Logical Cpu per Host	160	160
RAM per Host	1 TB	2 TB
MAX RAM for Service Console	800 MB	Not Applicable (NO SC)
LUNS per Server	256	256
Metro Vmotion	Round-trip latencies of up to 5 milliseconds.	Round-trip latencies of up to 10 milliseconds. This provides better performance over long latency networks
Storage Vmotion	Moving VM Files using moving to using dirty block tracking	Moving VM Files using I/O mirroring with better enhancements
Virtual Distributed Switch	Yes	Yes with more enhancements like deeper view into virtual machine traffic through Netflow and enhances monitoring and troubleshooting capabilities through SPAN and LLDP
USB 3.0 Support	NO	Yes
Host Per vCenter	1000	1000
Powered on virtual machines  per vCenter Server	10000	10000
Vmkernel	64-bit	64-bit
Service Console	64-bit	Not Applicable (NO SC)