Sysprep file locations and versions

Symptoms

• When attempting to customize the deployment of a virtual machine, the radio buttons are disabled (grayed out).
• When a virtual machine is deployed from a template, the SID is always the same, despite the fact that you chose the option to generate a new SID during template deployment and guest operating system customization.
• When attempting to create a new virtual machine from a template in vCenter Server, you see the error:
  
  Warning: Windows customization resources were not found on this server
  
• In the guestcust.log file, you see the error:
   
  deploy doesn't contain known sysprep files
  
  
• When you ignore the errors, the virtual machine deployment does not get customized

Purpose

This issue may occur if Microsoft's Sysprep files are not found on the vCenter Server host, are not the correct version, or are not in the location they are expected.

 

This article guides you through the process of determining the correct version of Sysprep to use and the correct locations for these files.

Resolution

Microsoft has a different version of Sysprep for each release and service pack of Windows. You must use the version of Sysprep specific to the operating system you are deploying.The differences are not immediately visible in the packaging and documentation of the service packs, so it is necessary to manually investigate.

 

The contents of the Sysprep deploy.cab file must be extracted to the Sysprep Directory on the vCenter Server host. If the file downloaded from the Microsoft Web Site is a .cab file, the Installing the Microsoft Sysprep Tools in the Virtual Machine Administration guide, details how to install the Sysprep Tools.

 

If the file downloaded from the Microsoft Web Site is a .exe file, these additional steps must be executed to extract the files from the .exe:

1. Open a Windows command prompt. For more information, see Opening a command or shell prompt (1003892).
2. Change to the directory where the .exe file is saved.
3. Enter the name of the .exe file with the /x switch to extract the files. For example:
   
   WindowsServer2003-KB926028-v2-x86-ENU.exe /x
    
4. When prompted, choose a directory for the extracted files.
5. Browse the directory and double-click the deploy.cab file.
   
   Note: In some cases, the deploy.cab file may be located within one of the subfolders created in Step 3.
   
6. Select all the files, and copy them to the Sysprep Directory.

When the contents of the of the Sysprep deploy.cab file have been extracted to the Sysprep Directory on the vCenter Server:

1. Log in to the vCenter Server as an Administrator.
2. Click Start > Programs > Accessories > Windows Explorer.
3. Navigate to the Sysprep Directory as listed in the table below.
4. Right-click on the Sysprep .exe file and choose Properties.
5. Click the Version tab. Record the number at the top next to File Version:.

The table below lists the Sysprep version for the Windows versions that are supported for Image Customization. Compare the Sysprep version number with the Windows version for which it is intended:

Notes:

• If vCenter Server is installed on Windows Server 2008 and above, <directory_path> is%ALLUSERSPROFILE%\VMware\VMware VirtualCenter\Sysprepwhich generally translates toC:\ProgramData\VMware\VMware VirtualCenter\Sysprep by default.
  
  Note: C:\ProgramData may be a hidden folder.
  
• If vCenter Server is installed on any other Windows operating system, <directory_path> is%ALLUSERSPROFILE%\Application Data\VMware\VMware VirtualCenter\Sysprep\ which generally translates to C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\Sysprep\ by default.
• To check the SID of a server deployed from a template, you can use the PsGetSid. For more information, seehttp://technet.microsoft.com/en-us/sysinternals/bb897417.  

 

Windows Version	Sysprep Directory	Sysprep Version
Windows 2000 Server SP4 with Update Rollup 1 Download at http://www.microsoft.com/downloads/details.aspx?FamilyID=0c4bfb06-2824-4d2b-abc1-0e2223133afb Or The updated Deployment Tools are available in the Support\Tools\Deploy.cab file on the Windows 2000 SP4 CD-ROM. To download this file, visit the following Microsoft Web site: http://technet.microsoft.com/en-us/windowsserver/2000/bb735341.aspx	<directory_path>\2k	5.0.2195.2104
Windows XP Pro SP2 Download at http://www.microsoft.com/downloads/details.aspx?FamilyId=3E90DC91-AC56-4665-949B-BEDA3080E0F6	<directory_path>\xp	5.1.2600.2180
Windows 2003 Server SP1 Download at http://www.microsoft.com/downloads/details.aspx?familyid=A34EDCF2-EBFD-4F99-BBC4-E93154C332D6	<directory_path>\svr2003	5.2.3790.1830 (srv03_sp1_rtm.050324-1447)
Windows 2003 Server SP2 Download at http://www.microsoft.com/downloads/details.aspx?FamilyID=93f20bb1-97aa-4356-8b43-9584b7e72556	<directory_path>\svr2003	5.2.3790.3959 (srv03_sp2_rtm.070216-1710)
Windows 2003 Server R2 Download at http://www.microsoft.com/downloads/details.aspx?FamilyID=93f20bb1-97aa-4356-8b43-9584b7e72556&displaylang=en	<directory_path>\svr2003	5.2.3790.3959 (srv03_sp2_rtm.070216-1710)
Windows 2003 x64 Download athttp://www.microsoft.com/downloads/details.aspx?familyid=C2684C95-6864-4091-BC9A-52AEC5491AF7&displaylang=en	<directory_path>\svr2003-64	5.2.3790.3959 (srv03_sp2_rtm.070216-1710)
Windows XP x64 Download athttp://www.microsoft.com/downloads/details.aspx?familyid=C2684C95-6864-4091-BC9A-52AEC5491AF7&displaylang=en	<directory_path>\xp-64	5.2.3790.3959 (srv03_sp2_rtm.070216-1710)
Windows XP Pro SP3 Download at http://www.microsoft.com/downloads/details.aspx?familyid=673a1019-8e3e-4be0-ac31-70dd21b5afa7&displaylang=en	<directory_path>\xp	5.1.2600.5512
Windows Vista System Preparation tools are built into the Windows Vista operating system and do not have to be downloaded.	Not Applicable	Not Applicable
Windows Server 2008 System Preparation tools are built into the Windows Server 2008 operating system and do not have to be downloaded.	Not Applicable	Not Applicable
Windows Server 2008 R2 System Preparation tools are built into the Windows Server 2008 R2 operating system and do not have to be downloaded.	Not Applicable	Not Applicable
Windows 7 System Preparation tools are built into the Windows 7 operating system and do not have to be downloaded.	Not Applicable	Not Applicable
vCenter Server Virtual Appliance 5.0	/etc/vmware-vpx/sysprep/	Not Applicable

 

Source:-

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

ESXI5 Installation Step by Step

Check the Minimum system requirements for installing ESX/ESXi from this KB article:-

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

.VSWP File Size

In every VM .vswp file gets created as soon as you will power on the vm and it's deleted as soon as you will power off the vm. The size of this file depends upon two factors:-
1.)  Allocated Memory
2.)  Reserved Memory

Formula for calculating the .vswp file size:-
Allocated Memory - Reserved Memory

Let's Assume Allocated Memory is 1GB and Reserved Memory is also 1GB in this case the size of .vswp file will be 0. The size of this file will be automatically increased as soon as you reduce the reservation but it is not decreased as soon as you will increase the reservation of a vm memory. But if it is increased it is not reflected in the storage views tab it is only reflected by Browsing that datastore where vm file are stored. Check this attached Screenshot:-

HOW TO ENABLE FT IN NESTED VIRTUALIZATION

VMware Fault Tolerance fails to turn on in a two node cluster

 

Symptoms

• VMware Fault Tolerance (FT) is configured and functional for virtual machines in a two node cluster.
• FT is turned off so that the primary virtual machine can be vMotioned to a different host in the cluster.
• Attempts to turn on FT after vMotioning fail with the errors similar to:

The virtual machine is running in a monitor mode that is incompatible for Fault Tolerance.

The Fault Tolerance configuration of the entity <VM name> has an issue: The virtual machine's current configuration does not support Fault Tolerance.

Purpose

Running FT protected virtual machines in a two node cluster is supported. Problems can occur when there is a need to vMotion the primary virtual machine from one host to the other. As the primary and secondary virtual machines cannot reside on the same host, FT must be turned off so that the secondary virtual machines is destroyed. The primary virtual machines can then be vMotioned to the other host.

This article provides steps to prevent the monitor mode from changing during vMotioning that causes FT to fail.

Resolution

This issue occurs if the monitor mode changes during the vMotion process. FT requires the monitor mode be set to Use Intel VT-x/AMD-V for instruction set virtualization and software for MMU virtualization for the monitor mode to not change during the vMotion process.

The default setting for the virtual machine monitor mode is Automatic and FT sets the monitor mode appropriately behind the scenes. If the hosts in the cluster support the Use Intel VT-x/AMD-V for instruction set virtualization and Intel EPT/AMD RVI for MMU virtualization option, the monitor mode is changed to this during the vMotion process.

To set the monitor mode explicitly to Use Intel VT-x/AMD-V for instruction set virtualization and software for MMU virtualization:

Note: In some instances, the virtual machine needs to be powered off in order to change the monitor mode.

1. Right-click the virtual machine in question and choose Edit Settings.
2. In the virtual machine Properties window, click Options and select the CPU/MMU Virtualization option under the Advanced heading.
3. Select the radio button next to Use Intel VT-x/AMD-V for instruction set virtualization and software for MMU virtualization.
4. Click OK.
5. For the setting to take effect, the virtual machine needs to be power cycled or vMotioned to another host. When this is complete, FT can be turned on for the virtual machine.

Source :-

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

Unpresenting a LUN in ESXi 5.x

Purpose

This article provides steps on how to unpresent a LUN from an ESXi 5.x host.

Resolution

Removing a LUN in ESX/ESXi 4.x is complex. Improvements have been made in ESXi 5.x to streamline the procedure to make it easier for Administrators to remove LUNs.

Unpresenting a LUN Checklist

Before unpresenting a LUN, ensure that:

• If the LUN is being used as a VMFS datastore, all objects (such as virtual machines and templates) stored on the VMFS Datastore are unregistered or moved to another datastore.
  
  Note: All CD/DVD images located on the VMFS datastore must also be unregistered from the virtual machines.
  
• The datastore is not part of a datastore cluster. For more information on datastore clusters, see the vSphere Resource Management Guide.
• The datastore is not managed by Storage DRS. For more information on Storage DRS, see the vSphere Resource Management Guide.
• Storage I/O Control is disabled for the datastore. For more information, see Managing Storage I/O Resources in thevSphere Resource Management Guide.
• The datastore is not used for vSphere HA heartbeat.
• No third party scripts or utilities running on the ESXi host can access the LUN in question. If the LUN is being used as a datastore, unregister all objects (such as virtual machines and templates) stored on the datastore.
• If the LUN is being used as an RDM, remove the RDM from the virtual machine. Click Edit Settings, highlight the RDM hard disk, and select Remove. Ensure that Delete from disk is selected and click OK.
  
  Note: This destroys the mapping file, but not the LUN content.
  
• Check if the LUN/Datastore is used as the persistent scratch location for the host. For more information on persistent scratch, see Creating a persistent scratch location for ESXi (1033696).
  
  This PowerCLI script can be used to check the current scratch location:
  
  $vcServer = "vCenter01"
  $cluster = "CL01"
  $esxCred = Get-Credential
  Connect-VIServer $vcServer | Out-Null
  #Connect to ESX hosts in cluster
  foreach ($esx in Get-Cluster $cluster | Get-VMHost) {
  Connect-VIServer $esx -Credential $esxCred | Out-Null
  Get-VMHostAdvancedConfiguration -Name "ScratchConfig.ConfiguredScratchLocation"
  }

Getting the NAA ID of the LUN to be removed

From the vSphere Client, this information is visible from the Properties window of the datastore.

From the ESXi host, run the command:

# esxcli storage vmfs extent list

The output is similar to: 

Volume Name VMFS UUID                           Extent Number Device Name                           Partition
----------- ----------------------------------- ------------- ------------------------------------  ---------
datastore1  4de4cb24-4cff750f-85f5-0019b9f1ecf6             0  naa.6001c230d8abfe000ff76c198ddbc13e        3
Storage2    4c5fbff6-f4069088-af4f-0019b9f1ecf4             0  naa.6001c230d8abfe000ff76c2e7384fc9a        1
Storage4    4c5fc023-ea0d4203-8517-0019b9f1ecf4             0  naa.6001c230d8abfe000ff76c51486715db        1
LUN01       4e414917-a8d75514-6bae-0019b9f1ecf4             0 naa.60a98000572d54724a34655733506751        1
Make a note of the NAA ID of the datastore, as this information is required later. 

Note: Alternatively, you can run the esxcli storage filesystem list command, which lists all file systems recognized by the ESX host.

Unpresenting a LUN from vSphere Client

To unpresent a LUN from an ESXi 5.0 host using vSphere Client:

1. If the LUN is an RDM, skip to Step 2. Otherwise, in the Configuration tab of the ESXi host, click Storage. Right-click the datastore being removed, and click Unmount.
   
   A Confirm Datastore Unmount window appears. When the prerequisite criteria have been passed, click OK.
   
   Note: To unmount a datastore from multiple hosts, from the vSphere Client select Hosts and Clusters, Datastores and Datastore Clusters view (Ctrl+Shift+D). Perform the umount task and select the appropriate hosts that should no longer access the datastore to be unmounted.
   
2. Choose the Devices View (Under Configuration > Storage):
   
   
   
3. Right-click the NAA ID of the LUN (as noted above) and click Detach. A Confirm Device Unmount window is displayed. When the prerequisite criteria have been passed, click OK.
   
   Note: If you choose the Delete option after unmounting the LUN, it will delete all data from the LUN and remove the partition table from it.
   
4. Under the Operational State of the Device, the LUN will be listed as Unmounted.
5. The LUN can now be unpresented from the SAN. For more information, contact your storage array vendor.
6. Perform a rescan on all ESXi hosts which had visibility to the LUN. The device is automatically removed from the Storage Adapters.

When the device is detached, it stays in an unmounted state even if the device is represented (that is, the detached state is persistent). To bring the device back online, the device needs to be attached.

If the device is to be permanently decommissioned from an ESXi servers(s) , you may have to manually remove the NAA entries from the host configuration by issuing these commands:

1. To list the permanently detached devices:
   
   # esxcli storage core device detached list
   The output is similar to:
   
   Device UID                            State
   ------------------------------------  -----
   naa.50060160c46036df50060160c46036df  off
   naa.6006016094602800c8e3e1c5d3c8e011  off 
   
2. To permanently remove the device configuration information from the system:
   
   # esxcli storage core device detached remove -d NAA_ID
   
   For example:
   
   # esxcli storage core device detached remove  -d naa.50060160c46036df50060160c46036df

Unpresenting a LUN from the command line 

To unpresent a LUN from an ESXi 5.0 host from the command line:

1. If the LUN is an RDM, skip to step 4. Otherwise, to get a list of all datastores mounted to an ESXi host, run the command:
   
   # esxcli storage filesystem list
   
   The output, which lists all VMFS datastores, is similar to:
   
   Mount Point                                       Volume Name UUID                                Mounted Type         Size         Free
   ------------------------------------------------- ----------- ----------------------------------- ------- ------ -----------  -----------
   /vmfs/volumes/4de4cb24-4cff750f-85f5-0019b9f1ecf6 datastore1  4de4cb24-4cff750f-85f5-0019b9f1ecf6    true  VMFS-5   140660178944   94577360896
   /vmfs/volumes/4c5fbff6-f4069088-af4f-0019b9f1ecf4 Storage2    4c5fbff6-f4069088-af4f-0019b9f1ecf4    true  VMFS-3   146028888064    7968129024
   /vmfs/volumes/4c5fc023-ea0d4203-8517-0019b9f1ecf4 Storage4    4c5fc023-ea0d4203-8517-0019b9f1ecf4    true  VMFS-3   146028888064  121057050624
   /vmfs/volumes/4e414917-a8d75514-6bae-0019b9f1ecf4 LUN01       4e414917-a8d75514-6bae-0019b9f1ecf4    true  VMFS-5   146028888064   4266131456
   
2. Unmount the datastore by running the command:
   
   # esxcli storage filesystem unmount [-u <UUID> | -l <label> | -p <path> ]
   
   For example, use one of these commands to unmount the LUN01 datastore:
   
   # esxcli storage filesystem unmount -l LUN01
   # esxcli storage filesystem unmount -u 4e414917-a8d75514-6bae-0019b9f1ecf4
   # esxcli storage filesystem unmount -p /vmfs/volumes/4e414917-a8d75514-6bae-0019b9f1ecf4
   Note: If the VMFS filesystem you are attempting to unmount has active I/O or has not fulfilled the prerequisites to unmount the VMFS datastore, the vmkernel logs show this error:
   
   WARNING: VC: 637: unmounting opened volume ('4e414917-a8d75514-6bae-0019b9f1ecf4' 'LUN01') is not allowed.
   VC: 802: Unmount VMFS volume f530 28 2 4e414917a8d7551419006bae  f4ecf19b 4 1 0 0 0 0 0 : Busy
   
3. To verify that the datastore has been unmounted, run the command:
   
   # esxcli storage filesystem list
   
   The output is similar to:
   
   Mount Point                                       Volume Name UUID                                Mounted Type         Size         Free
   ------------------------------------------------- ----------- ----------------------------------- ------- ------ -----------  -----------
   /vmfs/volumes/4de4cb24-4cff750f-85f5-0019b9f1ecf6 datastore1  4de4cb24-4cff750f-85f5-0019b9f1ecf6    true  VMFS-5   140660178944   94577360896
   /vmfs/volumes/4c5fbff6-f4069088-af4f-0019b9f1ecf4 Storage2    4c5fbff6-f4069088-af4f-0019b9f1ecf4    true  VMFS-3   146028888064    7968129024
   /vmfs/volumes/4c5fc023-ea0d4203-8517-0019b9f1ecf4 Storage4    4c5fc023-ea0d4203-8517-0019b9f1ecf4    true  VMFS-3   146028888064  121057050624
                                                    LUN01       4e414917-a8d75514-6bae-0019b9f1ecf4   false  VMFS-unknown version    0     0
   Note that the Mounted field  is set to false, the Type field is set to VMFS-unknown version, and that no Mount Point exists.
   
   Note: The unmounted state of the VMFS datastore persists across reboots. This is the default behavior. However, it can be changed by appending the --no-persist flag.
   
4. To detach the device/LUN, run this command:
   
   # esxcli storage core device set --state=off -d NAA_ID
   
5. To verify that the device is offline, run this command:
   
   # esxcli storage core device list -d NAA_ID
   
   The output, which shows that the status of the disk is off, is similar to:
   
   naa.60a98000572d54724a34655733506751
      Display Name: NETAPP Fibre Channel Disk (naa.60a98000572d54724a34655733506751)
      Has Settable Display Name: true
      Size: 1048593
      Device Type: Direct-Access
      Multipath Plugin: NMP
      Devfs Path: /vmfs/devices/disks/naa.60a98000572d54724a34655733506751
      Vendor: NETAPP
      Model: LUN
      Revision: 7330
      SCSI Level: 4
      Is Pseudo: false
      Status: off
      Is RDM Capable: true
      Is Local: false
      Is Removable: false
      Is SSD: false
      Is Offline: false
      Is Perennially Reserved: false
      Thin Provisioning Status: yes
      Attached Filters:
      VAAI Status: unknown
      Other UIDs: vml.020000000060a98000572d54724a346557335067514c554e202020
   
   Running the partedUtil getptbl command on the device shows that the device is not found.
   
   For example:
   
   # partedUtil getptbl /vmfs/devices/disks/naa.60a98000572d54724a34655733506751
   
   Error: Could not stat device /vmfs/devices/disks/naa.60a98000572d54724a34655733506751- No such file or directory.
   Unable to get device /vmfs/devices/disks/naa.60a98000572d54724a34655733506751
   
6. The LUN can now be unpresented from the SAN. For more information, contact your storage array vendor.
7. To rescan all devices on the ESXi host, run the command:
   
   # esxcli storage core adapter rescan [ -A vmhba# | --all ]
   
   The devices are automatically removed from the Storage Adapters.
   
   Note: A rescan needs to be run on all hosts that had visibility of the removed LUN.
   
   Note: When the device is detached, it stays in an unmounted state even if the device is represented (that is, the detached state is persistent). To bring the device back online, the device needs to be attached. To do this via the command line, run the command:
   
   # esxcli storage core device set --state=on -d NAA_ID
   
8. If the device is to be permanently decommissioned from an ESXi servers(s), (that is, the LUN has been destroyed), remove the NAA entries from the host configuration by issuing these commands:
   
   
   1. To list the permanently detached devices:
      
      # esxcli storage core device detached list
      
      The output is similar to:
      
      Device UID                            State
      ----------------------------  -----
      naa.50060160c46036df50060160c46036df  off
      naa.6006016094602800c8e3e1c5d3c8e011  off 
      
      
   2. To permanently remove the device configuration information from the system:
      
      # esxcli storage core device detached remove -d NAA_ID
      
      For example:
      
      # esxcli storage core device detached remove  -d naa.50060160c46036df50060160c46036df
   
   The reference to the device configuration is permanently removed from the ESXi host's configuration.

Source of this Info :- http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2004605

Upgrading from ESX 4.x to ESXi 5.0 using the interactive installer

Upgrading to ESXi 5.0 using Update Manager 5.0

USB support for ESX/ESXi 4.1 and ESXi 5.0

ESX/ESXi 4.1 and ESXi 5.0 supports USB device passthrough from an ESX or ESXi to a virtual machine.

 

This article provides information on:

• USB device passthrough requirements and limitations
• How to add a USB controller and a USB device.

For More Info Check this KB article:-

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

What is a Virtual Machine and What are the Components of a VM?

What is a virtual machine?

A virtual machine is a tightly isolated software container that can run its own operating systems and applications as if it were a physical computer. A virtual machine behaves exactly like a physical computer and contains it own virtual (that is, software-based) CPU, RAM hard disk and network interface card (NIC).

What are the components of a virtual machine?

A virtual machine is composed of several processes or userworlds that run in the VMkernel. Combined, the processes collectively make up a group. The following is a summary of components of a virtual machine:

• Virtual Machine Executable (VMX) process - A process that runs in the VMkernel that is responsible for handling I/O to devices that are not critical to performance. The VMX is also responsible for communicating with user interfaces, snapshot managers, and remote console.
• Virtual Machine Monitor (VMM) process - A process that runs in the VMkernel that is responsible for virtualizing the guest OS instructions, and manages memory. The VMM passes storage and network I/O requests to the VMkernel, and passes all other requests to the VMX process. There is a VMM for each virtual CPU assigned to a virtual machine.
• Mouse Keyboard Screen (MKS) process - A process that is responsible for rendering the guest video and handling guest operating system user input.

Check this KB article for more info:-

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

Renaming a virtual machine and its files

A virtual machine's files may be renamed during a disk migration operation, such as Cold Storage Migration, or by manually renaming them in-place from the ESX/ESXi console. Select your preferred method.
Alternatively, a virtual machine could be cloned to a new virtual machine using the Clone method in vCenter Server or using vCenter Converter, and deleting the old virtual machine.

For More Info Check this KB Article:-
http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&externalId=1029513

vSphere5 Storage vMotion does not rename virtual machine files on completing migration

This is a known issue affecting vSphere 5.0 and is scheduled to be resolved in a future update.

For More Info Check this KB Article:-
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2008877 

Changing a forgotten root password on an ESX/ESXi host

Reinstalling the ESXi host is the only supported way to reset a password on ESXi.

For More Info Here is link of KB Article:-
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1317898

Disable and Change the default behaviour of Esxi and Active Directory Integration

As soon as domain is joined by the esxi then if in your active directory a group called "ESX Admins" is present then whatever the users are their in this group will automatically get the administrative rights on the esxi. So i am going to tell all of you how you can change this default behaviour that's given in this picture and You can even completely disable this functionality by setting the option  Config.HostAgent.plugins.hostsvc.esxAdminsGroupAutoAddto false.

Removing the Administrator role from the group is initially successful, but rebooting the ESX/ESXi host grants the Administrative role again to the group if you will remove this group from esxi by directly connecting it. So the best practice is to change it to no access rather than removing it.
Hope this is Helpful for Everyone......Enjoy

Enable/Size/Disable memory compression cache

Memory compression is used to improve VM performance when you have memory overcommitment and is enabled by default.  ESXi will attempt to compress memory pages that can be sized down to 2kb.  By default, ESXi will use 10% of the allocated memory to the VMs on the host for memory caching, but can be changed using the advanced options below.

Must modify host advanced settings – Mem.MemZipEnable = 1 – enable or disable memory caching.

Must modify host Advanced Settings – Mem.MemZipMaxPct = (value specified in percentage between 5 and 100)