Enhanced VMotion Compatibility (EVC)

What is EVC?

EVC automatically configures server CPUs with Intel FlexMigration or AMD-V Extended Migration technologies to be compatible with older servers.

What is the benefit of EVC?

No. An EVC-enabled cluster only allows CPUs from a single vendor in the cluster. VirtualCenter and vCenter Server do not allow you to add a host from a different vendor into an EVC-enabled cluster.

What is the difference between EVC and the old CPUID masking feature (accessed from the Virtual Machine Settings dialog box, Options tab, CPUID mask option)?

vCenter Server does not permit the addition of hosts that do not provide support for EVC into an EVC-enabled cluster.

To use EVC, you must be running ESX 3.5 Update 2 or higher with VirtualCenter 2.5 Update 2 or higher and have compatible processors in your servers. EVC does not allow for migration with VMotion between Intel and AMD processors.

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

The older masking feature involved applying manual masks to individual virtual machines. EVC takes effect on a whole cluster and all virtual machines in the cluster. More accurately, EVC affects the hosts themselves, making all the hosts in the cluster appear to be the same type of CPU hardware, even if they are different.

What happens when a host is removed from an EVC-enabled cluster?

When a host leaves an EVC-enabled cluster, it reverts to its normal behavior. New virtual machines started on that host can access all the features of the CPU, and are not limited by the EVC mode that was in effect while the host was in the EVC cluster. Note that virtual machines that were once able to migrate to the host might no longer be permitted to do so.

Can I add an ESX/ESXi 3.5 Update 1 or earlier host to an EVC-enabled cluster?

No. EVC is supported only on ESX/ESXi 3.5 Update 2 and later.

Because EVC allows you to migrate virtual machines between different generations of CPUs, with EVC you can mix older and newer server generations in the same cluster and be able to migrate virtual machines with VMotion between these hosts. This makes adding new hardware into your existing infrastructure easier and helps extend the value of your existing hosts.

How do I use EVC?

EVC is enabled for a cluster in the VirtualCenter or vCenter Server inventory. After it is enabled, EVC ensures that migration with VMotion is possible between any hosts in the cluster. Only hosts that preserve this property can be added to the cluster.

After EVC is enabled for a cluster in the VirtualCenter inventory, all hosts in that cluster are configured to present identical CPU features and ensure CPU compatibility for VMotion.

Does EVC allow AMD and Intel CPUs to be VMotion compatible?

EVC is short for Enhanced VMotion Compatibility. EVC allows you to migrate virtual machines between different generations of CPUs.

Enhanced VMotion Compatibility (EVC) simplifies VMotion compatibility issues across CPU generations.

All VM files

Detailed list of all the VM files

*.nvram file

vmdk files

o *flat.vmdk file - This is the actual raw disk file that is created for each virtual hard drive. Almost all of a .vmdk file's content is the virtual machine's data, with a small portion allotted to virtual machine overhead. This file will be roughly the same size as your virtual hard drive.

o *.vmdk file - This isn't the file containing the raw data anymore. 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.

o *delta.vmdk file - This is the differential file created when you take a snapshot of a VM (also known as REDO log). When you snapshot a VM it stops writing to the base vmdk and starts writing changes to the snapshot delta file. The snapshot delta will initially be small and then start growing as changes are made to the base vmdk file, The delta file is a bitmap of the changes to the base vmdk thus is can never grow larger than the base vmdk. A delta file will be created for each snapshot that you create for a VM. These files are automatically deleted when the snapshot is deleted or reverted in snapshot manager.

*.vmx file

*.vswp file

*.vmss file

*.log file

*.vmxf file

*.vmsd file

*.vmsn file - This is the snapshot state file, which stores the exact running state of a virtual machine at the time you take that snapshot. This file will either be small or large depending on if you select to preserve the VM's memory as part of the snapshot. If you do choose to preserve the VM's memory then this file will be a few megabytes larger then the maximum RAM memory allocated to the VM. This file is similar to the vmss (Suspend) file. A vmsn file will be created for each snapshot taken on the VM, these files are automatically deleted when the snapshot is removed. - This file is used to store metadata and information about snapshots. This file is in text format and will contain information such as the snapshot display name, uid, disk file name, etc. It is initially a 0 byte file until you create your first snapshot of a VM and from that point it will populate the file and continue to update it whenever new snapshots are taken. This file does not cleanup completely after snapshots are taken. Once you delete a snapshot it will still leave the fields in the file for each snapshot and just increment the uid and set the name to Consolidate Helper presumably to be used with Consolidated Backups - This is a supplemental configuration file in text format for virtual machines that are in a team. Note that the .vmxf file remains if a virtual machine is removed from the team. Teaming virtual machines is a Vmware Workstation feature and includes the ability to designate multiple virtual machines as a team, which administrators can then power on and off, suspend and resume as a single object making it particularly useful for testing client-server environments. This file still exists with ESX server virtual machines but only for compatibility purposes with Workstation.- This is the file that keeps a log of the virtual machine activity and is useful in troubleshooting virtual machine problems. Every time a VM is powered off and then back on a new log file is created. The current log file for the VM is always vmware.log. The older log files are incremented with a -# in the filename and up to 6 of them will be retained. (ie. vmware-4.log) The older .log files are always deleteable at will, the latest .log file can be deleted when the VM is powered off. As the log files do not take much disk space, most administrators let them be - This file is created when a VM is put into Suspend (pause) mode and is used to save the suspend state. It is basically a copy of the VM's RAM and will be a few megabytes larger than the maximum RAM memory allocated to the VM. If you delete this file while the VM is in a suspend state It will start the VM from a normal boot up instead of starting the vm from the state it was when it was suspended. This file is not automatically deleted when the VM is brought out of Suspend mode. Like the Vswp file this file will only be deleted when the VM is powered off (not rebooted). If a Vmss file exists from a previous suspend and the VM is suspended again then the previous file is re-used for the subsequent suspensions. Also note that if a vswp file is present it is deleted when a VM is suspended and then re-created when the VM is powered on again. The reason for this is that the VM is essentially powered off in the suspend state, it's RAM contents are just preserved in the vmss file so it can be quickly powered back on. - This is the VM swap file (earlier ESX versions had a per host swap file) and is created to allow for memory overcommitment on a ESX server. The file is created when a VM is powered on and deleted when it is powered off. By default when you create a VM the memory reservation is set to zero, meaning no memory is reserved for the VM and it can potentially be 100% overcommitted. As a result of this a vswp file is created equal to the amount of memory that the VM is assigned minus the memory reservation that is configured for the VM. So a VM that is configured with 2GB of memory will create a 2GB vswp file when it is powered on, if you set a memory reservation for 1GB, then it will only create a 1GB vswp file. If you specify a 2GB reservation then it creates a 0 byte file that it does not use. When you do specify a memory reservation then physical RAM from the host will be reserved for the VM and not usable by any other VM's on that host. A VM will not use it vswp file as long as physical RAM is available on the host. Once all physical RAM is used on the host by all its VM's and it becomes overcommitted then VM's start to use their vswp files instead of physical memory. Since the vswp file is a disk file it will effect the performance of the VM when this happens. If you specify a reservation and the host does not have enough physical RAM when the VM is powered on then the VM will not start.- This file is the primary configuration file for a virtual machine. When you create a new virtual machine and configure the hardware settings for it that information is stored in this file. This file is in text format and contains entries for the hard disk, network adapters, memory, CPU, ports, power options, etc. You can either edit these files directly if you know what to add or use the Vmware GUI (Edit Settings on the VM) which will automatically update the file. - These are the disk files that are created for each virtual hard drive in your VM. There are 3 different types of files that use the vmdk extension, they are: - This file contains the CMOS/BIOS for the VM. The BIOS is based off the PhoenixBIOS 4.0 Release 6 and is one of the most successful and widely used BIOS and is compliant with all the major standards, including USB, PCI, ACPI, 1394, WfM and PC2001. If the NVRAM file is deleted or missing it will automatically be re-created when the VM is powered on. Any changes made to the BIOS via the Setup program (F2 at boot) will be saved in this file. This file is usually less then 10K in size and is not in a text format (binary).

Understanding Snapshots

A good rule of thumb is to allow for disk space of at least 25% of the virtual machine's (VM's) total disk size. But this amount can vary depending upon the type of server, how long you keep the snapshots, and if you plan on using multiple snapshots. If you plan on including the memory state with your snapshots, you'll also need to allow for extra disk space equal to amount of RAM assigned to the VM.

A VM with only one snapshot requires no extra disk space when deleting, or committing, it. (The term committing is used because the changes saved in the snapshot's delta files are now committed to the original virtual machine disk file, or VMDK.) But if you have multiple snapshots, you will need extra disk space available when deleting all snapshots. This is because of the way they are merged back into the original disk file.

An alternate method of deleting multiple snapshots that requires less additional disk space is to delete the snapshots one by one, starting with the VMs farthest down the snapshot tree. This way, the snapshots grow individually when they are merged into the previous snapshot, and subsequently deleted. If a little more tedious, this method requires far less extra disk space.

Important: Don't run a Windows disk defragmentation while the VM has a snapshot running. Defragment operations change many disk blocks and can cause very rapid growth of snapshot files.

If you've created a snapshot of a VM, and run the VM, the snapshot is active. If a snapshot is active, the performance of the VM will be degraded because ESX writes to delta files differently and less efficiently than it does to standard VMDK files. Because there is a lock on the metadata, nothing else can be written to the delta file when a write is made to the disk. Also, as the delta file grows by each 16 MB increment, it will cause another metadata lock. This can affect your VMs and ESX hosts. How big an impact on performance this will have varies based on how busy your VM and ESX hosts are.

Never expand a disk file with a snapshot running, If you do expand a virtual disk using vmkfstools while a snapshot is active, the VM will no longer start and you will receive an error: "Cannot open the disk ".vmdk" or one of the snapshot disks it depends on. Reason: The parent virtual disk has been modified since the child was created."

delta.vmdk file - This is the differential file created when you take a snapshot of a VM (also known as REDO log). When you snapshot a VM it stops writing to the base vmdk and starts writing changes to the snapshot delta file. The snapshot delta will initially be small and then start growing as changes are made to the base vmdk file, The delta file is a bitmap of the changes to the base vmdk thus is can never grow larger than the base vmdk. A delta file will be created for each snapshot that you create for a VM. These files are automatically deleted when the snapshot is deleted or reverted in snapshot manager

A snapshot can never grow larger the the original disk.

vSphere 4 Guided Consolidation

Guided Consolidation is a tool that will allow you to monitor a physical computer and determine it’s potential for adding to your virtual environment.

It has an easy to use interface with a more simplified approach than using the full VMware Capacity Planner utility.

Once the tool begins to scan the system, it will gather data and display CPU information and utilization, memory information and utilization as well as the computer name. Sometimes it may take up to 1hr before this process begins. Be prepared to allow 24 to 48hrs for this process to complete as Guided Consolidation builds a confidence metric level. Once a high enough confidence level is reached, the status of the system changes to "Ready for consolidation".

At this point, a consolidation plan is available by selecting the analyzed computer and clicking the "Plan Consolidation" button.

This plan will include a star rating which will indentify how likely the physical computer is for virtualization and will even make a recommendation for the target host. The rating system ranges from 1 to 5 stars, with 5 stars indicating the system is a high candidate for the proposed host. From the Consolidation Wizard, you can change several things, the name of the VM, the host being assigned too or even remove a VM altogether from the list.

Diffrence SAN & NAS

NAS	SAN
NAS uses TCP/IP Networks: Ethernet, FDDI, ATM (perhaps TCP/IP over Fibre Channel someday)	SAN uses Fibre Channel.
NAS uses File Server Protocols: NFS, CIFS, HTTP.	SAN uses Encapsulated SCSI.
Almost any machine that can connect to the LAN (or is interconnected to the LAN through a WAN) can use NFS, CIFS or HTTP protocol to connect to a NAS and share files.	Only server class devices with SCSI Fibre Channel can connect to the SAN. The Fibre Channel of the SAN has a limit of around 10km at best
A NAS identifies data by file name and byte offsets, transfers file data or file meta-data (file's owner, permissions, creation data, etc.), and handles security, user authentication, file locking	A SAN addresses data by disk block number and transfers raw disk blocks.
A NAS allows greater sharing of information especially between disparate operating systems such as Unix and NT.	File Sharing is operating system dependent and does not exist in many operating systems.
File System managed by NAS head unit	File System managed by servers
Backups and mirrors (utilizing features like NetApp's Snapshots) are done on files, not blocks, for a savings in bandwidth and time. A Snapshot can be tiny compared to its source volume.	Backups and mirrors require a block by block copy, even if blocks are empty. A mirror machine must be equal to or greater in capacity compared to the source volume.

IP 4 Address Space