Explore topic-wise InterviewSolutions in .

Clone

• A clone is a copy of virtual machine.
• You cannot CONVERT back the cloned Virtual Machine.
• A Clone of a Virtual Machine can be created when the Virtual Machine is powered on
• Cloning can be done in two ways namely Full Clone and Linked Clone.
• A full clone is an independent copy of a virtual machine that shares NOTHING with the parent virtual machine after the cloning operation. Ongoing operation of a full clone is entirely separate from the parent virtual machine.
• A linked clone is a copy of a virtual machine that shares virtual disks with the parent virtual machine in an ongoing manner. This conserves disk space, and allows multiple virtual machines to use the same software installation.
• Cloning a virtual machine can save time if you are deploying many SIMILAR virtual machines. You can create, configure, and install software on a single virtual machine, and then clone it multiple times, rather than creating and configuring each virtual machine individually.

Template

• A template is a master copy or a baseline image of a virtual machine that can be used to create many clones.
• Templates cannot be powered on or edited, and are more difficult to ALTER than ordinary virtual machine.
• You can convert the template back to Virtual Machine to update the base template with the latest released patches and updates and to install or upgrade any software and again convert back to template to be used for future DEPLOYMENT of Virtual Machines with the latest patches.
• Convert virtual Machine to template cannot be performed, when Virtual machine is powered on. Only Clone to Template can be performed when the Virtual Machine is powered on.
• A template offers a more secure way of preserving a virtual machine configuration that you want to deploy many times.
• When you clone a virtual machine or deploy a virtual machine from a template, the resulting cloned virtual machine is independent of the original virtual machine or template.

Clone

Template

VMware VMotion enables the live migration of running virtual machines from one physical server to another with zero downtime.

VMotion lets you:

• Automatically optimize and ALLOCATE entire pools of resources for maximum hardware utilization and AVAILABILITY.
• Perform hardware maintenance without any scheduled downtime.
• Proactively migrate virtual machines away from failing or under performing SERVERS.

Below are the pre-requisites for configuring vMotion :

• Each host must be correctly licensed for vMotion
• Each host must meet shared storage requirements
• vMotion migrates the vm from one host to another which is only possible with both the host are sharing a common storage or to any storage accessible by both the source and target hosts. 
• A shared storage can be on a Fibre Channel storage area network (SAN), or can be implemented using iSCSI SAN and NAS.
• If you use vMotion to migrate virtual machines with raw device mapping (RDM) files, make sure to maintain consistent LUN IDs for RDMs across all participating hosts.
• Each host must meet the networking requirements
• Configure a VMkernel port on each host.
• Dedicate at least one GigE adapter for vMotion.
• Use at least one 10 GigE adapter if you migrate WORKLOADS that have many memory operations.
• Use jumbo frames for best vMotion performance.
• Ensure that jumbo frames are enabled on all network devices that are on the vMotion PATH including physical NICs, physical switches and virtual switches.

VMware VMotion enables the live migration of running virtual machines from one physical server to another with zero downtime.

VMotion lets you:

Below are the pre-requisites for configuring vMotion :

• Server Virtualization – consolidating multiple physical servers into virtual servers that run on a single physical server.
• Application Virtualization – an application runs on another host from where it is installed in a variety of ways. It could be done by application streaming, desktop virtualization or VDI, or a VM package (like VMware ACE creates with a player). Microsoft Softgrid is an example of Application virtualization.
• Presentation Virtualization – This is what Citrix Met frame (and the ICA protocol) as well as Microsoft Terminal Services (and RDP) are able to create. With presentation virtualization, an application actually runs on another host and all that you see on the client is the screen from where it is run.
• Network Virtualization – with network virtualization, the network is “CARVED up” and can be used for multiple purposes such as running a protocol analyzer inside an Ethernet switch. Components of a virtual network could include NICs, switches, VLANs, network storage devices, virtual network containers, and network MEDIA.
• Storage Virtualization – with storage virtualization, the disk/data storage for your data is CONSOLIDATED to and managed by a virtual storage system. The servers connected to the storage system aren’t aware of where the data really is. Storage virtualization is sometimes described as “abstracting the logical storage from the physical storage.

This isn't the FILE containing the raw data. Instead it is the disk descriptor file which describes the size and geometry of the virtual disk file. This file is in text FORMAT and CONTAINS the NAME of the –flat.vmdk file for which it is associated with and also the hard drive adapter type, drive sectors, heads and cylinders, ETC. One of these files will exist for each virtual hard drive that is assigned to your virtual machine. You can tell which –flat.vmdk file it is associated with by opening the file and looking at the Extent Description field.

This isn't the file containing the raw data. Instead it is the disk descriptor file which describes the size and geometry of the virtual disk file. This file is in text format and contains the name of the –flat.vmdk file for which it is associated with and also the hard drive adapter type, drive sectors, heads and cylinders, etc. One of these files will exist for each virtual hard drive that is assigned to your virtual machine. You can tell which –flat.vmdk file it is associated with by opening the file and looking at the Extent Description field.

VMware ESX and ESXI are both bare METAL HYPERVISOR architectures that install directly on the server hardware.

Although neither hypervisor architectures relies on an OS for resource management, the vSphere ESX architecture RELIED on a Linux operating system, CALLED the Console OS (COS) or service console, to perform two management functions: executing scripts and installing third-party agents for hardware monitoring, backup or systems management.

In the vSphere ESXi architecture, the service console has been removed. The smaller code base of vSphere ESXi represents a smaller “attack surface” and less code to patch, improving reliability and security.

VMware ESX and ESXi are both bare metal hypervisor architectures that install directly on the server hardware.

Although neither hypervisor architectures relies on an OS for resource management, the vSphere ESX architecture relied on a Linux operating system, called the Console OS (COS) or service console, to perform two management functions: executing scripts and installing third-party agents for hardware monitoring, backup or systems management.

In the vSphere ESXi architecture, the service console has been removed. The smaller code base of vSphere ESXi represents a smaller “attack surface” and less code to patch, improving reliability and security.

Thick Provision Lazy Zeroed

• Creates a virtual disk in a default thick format.
• Space required for the virtual disk is allocated when the virtual disk is created.
• Data remaining on the physical device is not erased during creation, but is zeroed out on demand at a later time on first write from the virtual machine.
• Using the default flat virtual disk format does not zero out or eliminate the possibility of recovering deleted files or RESTORING old data that might be present on this allocated space.
• You cannot convert a flat disk to a thin disk.

Thick Provision Eager Zeroed

• A type of thick virtual disk that supports clustering features such as Fault Tolerance.
• Space required for the virtual disk is allocated at creation time.
• In contrast to the flat format, the data remaining on the physical device is zeroed out when the virtual disk is created.
• It might take much longer to create disks in this format than to create other types of disks.

Thin Provision

• It PROVIDES on on-demand allocation of blocks of data.
• All the space allocated at the time of creation of virtual disk is not utilized on the HARD disk, rather only the size with utilized data is locked and the size increases as the amount of data is INCREASED on the disk.
• With thin provisioning, storage capacity utilization efficiency can be automatically driven up towards 100% with very little ADMINISTRATIVE overhead.

Thick Provision Lazy Zeroed

Thick Provision Eager Zeroed

Thin Provision

• Promiscuous mode is a security policy which can be defined at the virtual switch or portgroup LEVEL
• A virtual MACHINE, SERVICE Console or VMkernel network interface in a portgroup which allows use of promiscuous mode can see all network traffic TRAVERSING the virtual switch.
• If this mode is set to reject, the packets are sent to intended port so that the intended virtual machine will only be able to see the communication.
• Example: In case you are using a virtual xp inside any Windows VM. If promiscuous mode is set to reject then the virtual xp won't be able to connect the network unless promiscuous mode is enabled for the Windows VM.

• VDI stands for Virtual Desktop INFRASTRUCTURE where end USER physical machine like desktop or laptop are virtualized due to which VMware described VDI as "delivering desktops from the data center”.
• Once VDI is used the end user connect to their desktop using a DEVICE called thin client.
• The end user can also connect to their desktop using VMware Horizon View INSTALLED on any desktop or mobile DEVICES

• VMware HA i.e. High Availability which works on the host level and is configured on the Cluster.
• A Cluster configured with HA will migrate and RESTART all the vms running under any of the host in case of any host-level failure AUTOMATICALLY to another host under the same cluster.
• VMware HA continuously MONITORS all ESX Server hosts in a cluster and DETECTS failures.
• VMware HA agent placed on each host maintains a heartbeat with the other hosts in the cluster using the service console network. Each server sends heartbeats to the others servers in the cluster at five-second intervals. If any servers lose heartbeat over THREE consecutive heartbeat intervals, VMware HA initiates the failover action of restarting all affected virtual machines on other hosts.
• You can set virtual machine restart priority in case of any host failure depending upon the critical nature of the vm.

NOTE: Using HA in case of any host failure with RESTART the vms on different host so the vms state will be interrupted and it is not a live migration

NOTE: Using HA in case of any host failure with RESTART the vms on different host so the vms state will be interrupted and it is not a live migration

VMware HA is used in the event when any of the hosts inside a cluster fails then all the virtual machines running under it are restarted on different host in the same cluster.

Now HA is dependent on vMotion to perform live migration of the vms to different host so vMotion is just used for the migration purpose between multiple hosts which is also used by other functionality like DRS.

NOTE: Anyhow HA can WORK very will WITHOUT vMotion as its PRIMARY functionality is to restart the vm from the affected host to the WORKING host but this will be service affecting as the vms will be 'powered off' and then 'powered on' on the new host.

VMware HA is used in the event when any of the hosts inside a cluster fails then all the virtual machines running under it are restarted on different host in the same cluster.

Now HA is dependent on vMotion to perform live migration of the vms to different host so vMotion is just used for the migration purpose between multiple hosts which is also used by other functionality like DRS.

NOTE: Anyhow HA can work very will without vMotion as its primary functionality is to restart the vm from the affected host to the working host but this will be service affecting as the vms will be 'powered off' and then 'powered on' on the new host.

• Storage vMotion is similar to vMotion in the sense that "something" related to the VM is moved and there is no downtime to the VM GUEST and end USERS. However, with SVMotion the VM Guest stays on the server that it resides on but the virtual disk for that VM is what moves.
• With Storage vMotion, you can MIGRATE a virtual machine and its disk files from one DATASTORE to another while the virtual machine is running.
• You can choose to place the virtual machine and all its disks in a single location, or select separate locations for the virtual machine configuration file and each virtual disk.
• During a migration with Storage vMotion, you can transform virtual disks from Thick-Provisioned Lazy Zeroed or Thick-Provisioned Eager Zeroed to Thin-Provisioned or the reverse.
• Perform live migration of virtual machine disk files across any Fibre Channel, iSCSI, FCOE and NFS storage

Here DRS stands for Distributed Resource Scheduler which dynamically balances resource across various host under Cluster or resource POOL:

• VMware DRS allows users to define the rules and policies that decide how virtual machines share resources and how these resources are prioritized among MULTIPLE virtual machines.
• Resources are allocated to the virtual machine by either migrating it to another server with more available resources or by making more “space” for it on the same server by migrating other virtual machines to different servers.
• The live migration of virtual machines to different physical servers is executed completely transparent to end-users through VMware VMotion
• VMware DRS can be configured to operate in either automatic or manual mode. In automatic mode, VMware DRS DETERMINES the best possible distribution of virtual machines among different physical servers and automatically MIGRATES virtual machines to the most APPROPRIATE physical servers. In manual mode, VMware DRS provides a recommendation for optimal placement of virtual machines, and leaves it to the system administrator to decide whether to make the change.

Here DRS stands for Distributed Resource Scheduler which dynamically balances resource across various host under Cluster or resource pool:

• VMware Fault Tolerance PROVIDES CONTINUOUS availability to applications running in a virtual machine, preventing downtime and data loss in the event of server failures.
• VMware Fault Tolerance, when enabled for a virtual machine, creates a live shadow instance of the primary, running on another physical server.
• The two instances are kept in virtual lockstep with each other using VMware vLockstep technology
• The two virtual machines play the EXACT same set of events, because they get the exact same set of inputs at any given time.
• The two virtual machines CONSTANTLY heartbeat against each other and if either virtual machine instance loses the heartbeat, the other takes over immediately. The heartbeats are very frequent, with millisecond intervals, MAKING the failover instantaneous with no loss of data or state.
• VMware Fault Tolerance requires a dedicated network connection, separate from the VMware VMotion network, between the two physical servers.

You can PLACE the ORIGINAL (or Primary virtual machine). You have full control with DRS or vMotion to assign it to any node. The PLACEMENT of the Secondary, when CREATED, is automatic based on the AVAILABLE hosts. But when the Secondary is created and placed, you can vMotion it to the preferred host.

You can place the original (or Primary virtual machine). You have full control with DRS or vMotion to assign it to any node. The placement of the Secondary, when created, is automatic based on the available hosts. But when the Secondary is created and placed, you can vMotion it to the preferred host.

vCenter Server 4.x and vCenter Server 5.x SUPPORT 1 virtual CPU PER PROTECTED virtual machine.

vCenter Server 4.x and vCenter Server 5.x support 1 virtual CPU per protected virtual machine.

When Fault Tolerance is configured for a virtual machine, vCenter Server NEED not be online for FT to work. EVEN if vCenter Server is OFFLINE, failover still occurs from the Primary to the Secondary virtual machine. ADDITIONALLY, the spawning of a new Secondary virtual machine also occurs without vCenter Server.

When Fault Tolerance is configured for a virtual machine, vCenter Server need not be online for FT to work. Even if vCenter Server is offline, failover still occurs from the Primary to the Secondary virtual machine. Additionally, the spawning of a new Secondary virtual machine also occurs without vCenter Server.

Type 1 Hypervisor:

• This is ALSO known as Bare METAL or Embedded or Native Hypervisor.
• It works directly on the hardware of the host and can monitor operating systems that run above the hypervisor.
• It is completely independent from the Operating System.
• The hypervisor is small as its main task is sharing and managing hardware resources between DIFFERENT operating systems.
• A major ADVANTAGE is that any problems in one virtual machine or guest operating system do not AFFECT the other guest operating systems running on the hypervisor.
• Examples: VMware ESXi Server, Microsoft Hyper-V, Citrix/Xen Server

Type 2 Hypervisor :

• This is also known as Hosted Hypervisor.
• In this case, the hypervisor is installed on an operating system and then supports other operating systems above it.
• It is completely dependent on host Operating System for its operations
• While having a base operating system allows better specification of policies, any problems in the base operating system a ffects the entire system as well even if the hypervisor running above the base OS is secure.
• Examples: VMware Workstation, Microsoft Virtual PC, Oracle Virtual Box

Type 1 Hypervisor:

Type 2 Hypervisor :

• Monitoring the state of slave hosts. If a slave host fails or becomes unreachable, the master host identifies which virtual machines need to be RESTARTED.
• Monitoring the power state of all protected virtual machines. If one virtual machine fails, the master host ensures that it is restarted. Using a local placement engine, the master host also determines where the restart should be done.
• Managing the lists of CLUSTER hosts and protected virtual machines.
• Acting as VCENTER Server management INTERFACE to the cluster and reporting the cluster HEALTH state.

The Master and SLAVE HOSTS uses two types of MONITORING the status of the hosts

• DATASTORE Heartbeat
• Network Heartbeat

The Master and Slave hosts uses two types of monitoring the status of the hosts

When we CONFIGURE multiple hosts for HA CLUSTER, a single host is automatically elected as the master host. The master host communicates with vCenter Server and monitors the STATE of all protected virtual machines and of the SLAVE hosts. When you add a host to a vSphere HA cluster, an agent is uploaded to the host and configured to communicate with other agents in the cluster.

When we configure multiple hosts for HA cluster, a single host is automatically elected as the master host. The master host communicates with vCenter Server and monitors the state of all protected virtual machines and of the slave hosts. When you add a host to a vSphere HA cluster, an agent is uploaded to the host and configured to communicate with other agents in the cluster.

When VSPHERE HA is enabled for a cluster, all active hosts (those not in standby or maintenance mode, or not disconnected) participate in an election to CHOOSE the cluster's master HOST. The host that MOUNTS the greatest number of datastores has an advantage in the election. Only one master host typically exists per cluster and all other hosts are SLAVE hosts.

If the master host fails, is shut down or put in standby mode, or is removed from the cluster a new election is held.

When vSphere HA is enabled for a cluster, all active hosts (those not in standby or maintenance mode, or not disconnected) participate in an election to choose the cluster's master host. The host that mounts the greatest number of datastores has an advantage in the election. Only one master host typically exists per cluster and all other hosts are slave hosts.

If the master host fails, is shut down or put in standby mode, or is removed from the cluster a new election is held.

vSphere HA is not dependent on vCenterserver for its operations as when HA is configured it installs an AGENT into each host which does its part and is not dependent on vCenterserver. Also HA doesnot uses vMotion, it justs restarts the VMS into another host in any CASE of host failure.
Further vSphere DRS is very much dependent on vCenterserver as it uses vMotion for its action for live migration of vms between multiple hosts so in case vCenterserver goes down the vMotion won't work leading to failure of DRS.

vSphere HA is not dependent on vCenterserver for its operations as when HA is configured it installs an agent into each host which does its part and is not dependent on vCenterserver. Also HA doesnot uses vMotion, it justs restarts the vms into another host in any case of host failure.
Further vSphere DRS is very much dependent on vCenterserver as it uses vMotion for its action for live migration of vms between multiple hosts so in case vCenterserver goes down the vMotion won't work leading to failure of DRS.

VMware Tools is a suite of utilities that enhances the performance of the virtual MACHINE's guest operating system and improves management of the virtual machine. Without VMware Tools installed in your guest operating system, guest performance lacks important functionality.
Installing VMware Tools eliminates or improves these issues:

• Low video resolution
• INADEQUATE color depth
• Incorrect display of network speed
• Restricted movement of the mouse
• Inability to COPY and paste and drag-and-drop files
• Missing sound
• Provides the ability to take quiesced snapshots of the guest OS
• SYNCHRONIZES the time in the guest operating system with the time on the HOST
• Provides support for guest-bound calls created with the VMware VIX API

VMware Tools is a suite of utilities that enhances the performance of the virtual machine's guest operating system and improves management of the virtual machine. Without VMware Tools installed in your guest operating system, guest performance lacks important functionality.
Installing VMware Tools eliminates or improves these issues:

It is a PROGRAM that allows multiple OPERATING SYSTEMS to share a single hardware host. Each operating SYSTEM appears to have the host's processor, memory, and other resources all to itself. However, the hypervisor is actually controlling the host processor and resources, ALLOCATING what is needed to each operating system in turn and making sure that the guest operating systems (called virtual machines) cannot disrupt each other.

It is a program that allows multiple operating systems to share a single hardware host. Each operating system appears to have the host's processor, memory, and other resources all to itself. However, the hypervisor is actually controlling the host processor and resources, allocating what is needed to each operating system in turn and making sure that the guest operating systems (called virtual machines) cannot disrupt each other.