Configuring disks to use VMware Paravirtual SCSI (PVSCSI) adapters

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

Details

This article includes supplemental information about configuring and using VMware Paravirtual SCSI (PVSCSI) adapters.

PVSCSI adapters are high-performance storage adapters that can result in greater throughput and lower CPU utilization. PVSCSI adapters are best suited for environments, especially SAN environments, where hardware or applications drive a very high amount of I/O throughput. The VMware PVSCSI adapter driver is also compatible with the Windows Storport storage driver. PVSCSI adapters are not suited for DAS environments.

 

This table shows the support matrix for use of Paravirtual SCSI adapters for data disks and boot disks for the various guest operating systems and ESX versions. Support shown in the table is from the listed ESXi/ESX version and later versions.

Guest operating system Data Disk Boot Disk
Windows Server 2012 R2 (64 bit only) ESXi 5.0 Update 2, ESXi 5.1, ESXi 5.5 ESXi 5.0 Update 2, ESXi 5.1, ESXi 5.5
Windows Server 2012 (64 bit only) ESXi 5.0 Update 1, ESXi 5.1, ESXi 5.5 ESXi 5.0 Update 1, ESXi 5.1, ESXi 5.5
Windows Server 2008 R2 (64 bit only) ESXi/ESX 4.0 Update 1, ESXi/ESX 4.1, ESXi 5.x ESXi/ESX 4.0 Update 1, ESXi/ESX 4.1, ESXi 5.x
Windows Server 2008 (32 and 64 bit) ESXi/ESX 4.x, ESXi 5.x ESXi/ESX 4.0 Update 1, ESXi/ESX 4.1, ESXi 5.x
Windows Server 2003 (32 and 64 bit) ESXi/ESX 4.x, ESXi 5.x ESXi/ESX 4.x, ESXi 5.x
Windows 8.1 (32 and 64 bit) ESXi 5.0 Update 2, ESXi 5.1, ESXi 5.5 ESXi 5.0 Update 2, ESXi 5.1, ESXi 5.5
Windows 8 (32 and 64 bit) ESXi 5.0 Update 1, ESXi 5.1, ESXi 5.5 ESXi 5.0 Update 1, ESXi 5.1, ESXi 5.5
Windows 7 (32 and 64 bit) ESXi/ESX 4.1, ESXi 5.x ESXi/ESX 4.1, ESXi 5.x
Windows Vista (32 and 64 bit) ESXi/ESX 4.1, ESXi 5.x ESXi/ESX 4.1, ESXi 5.x
Windows XP (32 and 64 bit) ESXi/ESX 4.1, ESXi 5.x ESXi/ESX 4.1, ESXi 5.x
CentOS 5.x (32 and 64 bit) ESXi/ESX 4.0 Update 4, ESXi/ESX 4.1 Update 2, ESXi 5.x Not Supported
CentOS 6.x (32 and 64 bit) * ESXi/ESX 4.0 Update 4, ESXi/ESX 4.1 Update 2, ESXi 5.x ESXi/ESX 4.0 Update 4, ESXi/ESX 4.1 Update 2, ESXi 5.x
CentOS 7.x (64 bit) ESXi 5.5 ESXi 5.5
Red Hat Enterprise Linux (RHEL) 5 (32 and 64 bit) and all update releases ESXi/ESX 4.x, ESXi 5.x Not Supported
RHEL 6 (32 and 64 bit) ESXi/ESX 4.0 Update 2, ESXi/ESX 4.1, ESXi 5.x ESXi/ESX 4.0 Update 2, ESXi/ESX 4.1, ESXi 5.x
RHEL 7 (64 bit) ESXi 5.5 ESXi 5.5
SUSE Linux Enterprise 11 SP1(32 and 64 bit) and later releases ESXi/ESX 4.0 Update 2, ESXi/ESX 4.1, ESXi 5.x ESXi/ESX 4.0 Update 2, ESXi/ESX 4.1, ESXi 5.x
Ubuntu 10.04 (32 and 64 bit) and later releases ESXi/ESX 4.0 Update 2, ESXi/ESX 4.1, ESXi 5.x ESXi/ESX 4.0 Update 2, ESXi/ESX 4.1, ESXi 5.x

 

 

* = CentOS 6.5 is not supported on ESXi/ESX 4.0. Support added in ESXi/ESX 4.1 Update 3, ESXi 5.0 Update 2 and above only.

The default type of newly hot-added SCSI adapter depends on the type of primary (boot) SCSI controller. This means that hot-adding a PVSCSI adapter is only supported for those versions that support booting from a PVSCSI adapter.

Paravirtual SCSI adapters also have these limitations:

  • Hot add or hot remove requires a bus rescan from within the guest.
  • Disks with snapshots might not experience performance gains when used on Paravirtual SCSI adapters if memory on the ESX host is over committed.
  • Do not use PVSCSI on a virtual machine running Windows with spanned volumes. Data may become inaccessible to the guest operating system.
  • If you upgrade from RHEL 5 to an unsupported kernel, you might not be able to access data on the virtual machine’s PVSCSI disks. You can run vmware-config-tools.pl with the kernel-version parameter to regain access.

Solution

To configure a new or existing data disk to use a PVSCSI adapter:

  1. Launch a vSphere Client and log in to an ESXi/ESX host or vCenter Server.
  2. Select a virtual machine, or create a new one.
  3. Ensure a guest operating system that supports PVSCSI is installed on the virtual machine.
  4. If it is an existing virtual machine, power it off.
  5. In the vSphere Client, right-click on the virtual machine and click Edit Settings.
  6. Click the Hardware tab.
  7. Click Add.
  8. Select Hard Disk.
  9. Click Next.
  10. Choose any one of the available options.
  11. Click Next.
  12. Specify the options you require. Options vary depending on which type of disk you chose.
  13. Choose a Virtual DeviceNode and specify whether you want to use Independent mode. For data disks, choose a Virtual Device Nodebetween SCSI (1:0)to SCSI (3:15). For a boot disk, choose Virtual Device Node SCSI (0:0), or choose the Virtual Device Node that boots in the order you require.
    Note: To set a disk to use Independent mode there must be no snapshots associated to the virtual disk, if there are existing snapshots commit them before changing the disk type.
  14. Click Next.
  15. Click Finish to finish the process and exit the Add Hardware wizard. A new disk and controller are created.
  16. Select the newly created controller and click Change Type.
  17. Click VMware Paravirtual and click OK.
  18. Click OK to exit the Virtual Machine Properties dialog.
  19. Power on the virtual machine.
  20. Install VMware Tools. VMware Tools includes the PVSCSI driver.
  21. If it is a new virtual disk, scan and format the hard disk within the guest operating system.

To configure an existing Windows boot disk to use a PVSCSI adapter:
This procedure is required as the guest operating system does not have the PVSCSI driver and the guest will BSOD on boot if using the above method. This workaround forces the guest operating system to install the PVSCSI driver.

  1. Power off the virtual machine.
  2. Create a new temporary 1GB disk(SCSI 1:0) and assign a new SCSI controller (default is LSI LOGIC SAS).
  3. Change the new SCSI controller to PVSCSI for the new SCSI controller.
  4. Click Change Type.
  5. Click VMware Paravirtual and click OK.
  6. Click OK to exit the Virtual Machine Properties dialog.
  7. Power on the virtual machine.
  8. Verify the new disk was found and is visible in Disk Management. This confirms the PVSCSI driver is now installed.
  9. Power off the virtual machine.
  10. Delete the temporary 1GB vmdk disk and associated controller (SCSI 1:0).
  11. Change the original SCSI controller(SCSI 0:X) to PVSCSI as detailed in Steps 3 to 5.
  12. Power on the virtual machine.

To deploy and boot a new Windows virtual machine from a disk attached to a PVSCSI adapter, the VMware PVSCSI driver must be installed in the Windows guest. Floppy disk images that contain the driver are available for the versions of ESXi/ESX that support this. The required floppy images are stored on the host and are located at the /vmimages/floppies/ directory. If the floppy images are not visible, see Unable to mount a floppy image in vCenter Server (1036836).

To install PVSCSI drivers:
Note: This procedure assumes that your virtual machine does not have a floppy driver. If the virtual machine already has a floppy drive, skip directly to Step 6.

  1. Right-click the virtual machine and click Edit Settings.
  2. Click Add.
  3. From list, click Floppy Drive and click Next.
  4. Click Next to accept the default option.
  5. Click Finish.
  6. Click New Floppy or Floppy Drive.
  7. Select the Use existing floppy image in datastore option.
  8. Click Browse.
  9. Navigate to the vmimages or floppies folder.
  10. Select the image and click Open. Note: When installing Windows 2012 Server, use the Windows 2008 image pvscsi-Windows2008.flp to install the driver.
  11. Click OK.
  12. Boot the virtual machine to install the PVSCSI drivers.

 

Enabling Change Block Tracking (CBT) on a Virtual Machine (VMware vSphere 5.1)

Source: http://www.lazywinadmin.com/2013/01/enabling-change-block-tracking-cbt-on.html+

 

How to Enable CBT on your VM ? (PowerShell/PowerCli)

You can do the following even if your VM is Powered ON.

# Check and Add the PowerCli Snaping if not already present
if(-not(Get-PSSnapin -Registered -Name "VMware.VimAutomation.Core"){
    Add-PSSnapin -Name VMware.VimAutomation.Core}

# Connect to my Vcenter
Connect-VIServer -Server vcenter.fx.lab

#Here is aRunning the script on TESTSERVER04 to enable CBT
$vmtest = Get-vm TESTSERVER04 | get-view
$vmConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec
$vmConfigSpec.changeTrackingEnabled = $true
$vmtest.reconfigVM($vmConfigSpec)

How to Apply this CBT configuration ?

Once you enable CBT, the VM must go through a stun-unstun cycle (power on, resume after suspend, migrate, or snapshot create/delete/revert) before the reconfiguration takes effect.

How to Check if CBT is enabled on your VM (PowerShell/PowerCli)

# Check if your VM has (Change Block Tracking) enabled or not
(Get-VM -Name TESTSERVER04).ExtensionData.Config.ChangeTrackingEnabled

# Find VMs where CBT (Change Block Tracking) is Enabled
Get-VM| Where-Object{$_.ExtensionData.Config.ChangeTrackingEnabled -eq $true}

 

Creating a persistent scratch location for ESXi 4.x and 5.x (1033696)

source: http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=1033696

 

VMware recommends that ESXi has a persistent scratch location available for storing temporary data including logs, diagnostic information, and system swap. (This is not a requirement, however.) Persistent scratch space may be provisioned on a FAT 16, VMFS, or NFS partition accessible by the ESXi host.

Note: Scratch space is configured automatically during installation or first boot of an ESXi host, and does not usually need to be manually configured. ESXi Installable creates a 4 GB Fat16 partition on the target device during installation if there is sufficient space, and if the device is considered Local.

If persistent scratch space is not available, ESXi stores this temporary data on a ramdisk, which is constrained in space. This might be problematic in low-memory situations, but is not critical to the operation of ESXi. Information stored on a ramdisk does not persist across reboots, so troubleshooting information such as logs and core files could be lost. If a persistent scratch location on the host is not configured properly, you may experience intermittent issues due to lack of space for temporary files and the log files will not be updated.

 

Configuring a persistent scratch location using PowerCLI

To configure persistent scratch space for ESXi using the vSphere PowerCLI interface:

Notes:

  • Before proceeding, ensure that /tmp/scratch exists. If it does not exist, use the command mkdir /tmp/scratch to create it.
  • For more information on vSphere PowerCLI usage, see the vSphere PowerCLI documentation.
  1. Open a command prompt where the PowerCLI is installed.
  2. Connect to the ESXi host using the command:connect-viserver esx_hostname_or_IP
  3. Obtain a list of datastores reachable from this ESXi host using the command:Get-Datastore
  4. Mount a datastore read/write as a PSDrive using the command:New-PSDrive -Name "mounteddatastore" -Root \ -PSProvider VimDatastore -Datastore (Get-Datastore "DatastoreName")
  5. Access the new PSDrive using the command:Set-Location mounteddatastore:
  6. Create a uniquely-named directory for this ESXi host using the command:New-Item "DirectoryName" -ItemType directory

    For example:

    New-Item ".locker-ESXHostname" -ItemType directory

  7. Check the current value of the ScratchConfig.ConfiguredScratchLocation configuration option using the command:Get-VMHostAdvancedConfiguration -Name "ScratchConfig.ConfiguredScratchLocation"

    NoteVMHostAdvancedConfiguration has been deprecated in PowerCLI 5.1 and replaced with AdvancedSetting. For more information, see the vSphere PowerCLI documentation.

  8. Change the ScratchConfig.ConfiguredScratchLocation configuration option, specifying the full path to the directory created in step 6, using the command:Set-VMHostAdvancedConfiguration -Name "ScratchConfig.ConfiguredScratchLocation" -Value "/vmfs/volumes/DatastoreName/DirectoryName"

    For example:

    Set-VMHostAdvancedConfiguration -Name "ScratchConfig.ConfiguredScratchLocation" -Value "/vmfs/volumes/Datastore1/.locker-ESXHostname"

  9. Put the ESXi host into maintenance mode and reboot for the configuration change to take effect.

Clipboard Copy and Paste does not work in vSphere Client 4.1 and later

To be able to copy and paste between the guest operating system and the remote console, you must enable the Copy and Paste options using the vSphere Client. Alternatively, you can use RDP (Remote Desktop Protocol) to connect to the Windows virtual machines.

To enable this option for a specific virtual machine:

Note: VMware Tools must be installed for Copy and Paste to work.

  1. Log into a vCenter Server system using the vSphere Client and power off the virtual machine.
  2. Select the virtual machine and click the Summary tab.
  3. Click Edit Settings.
  4. Navigate to Options > Advanced > General and click Configuration Parameters.
  5. Click Add Row.
  6. Type these values in the Name and Value columns:


                            Name                                                Value

  • isolation.tools.copy.disable    false
  • isolation.tools.paste.disable   false

Note: These options override any settings made in the VMware Tools control panel of the guest operating system.

  1. Click OK to close the Configuration Parameters dialog, and click OK again to close the Virtual Machine Properties dialog.
  2. Power on the virtual machine.

Note: If you vMotion a virtual machine to a host where the isolation.tools.*="FALSE" is already set, the copy and paste options are automatically activated for that virtual machine.

To enable this option for all the virtual machines in the ESX/ESXi host:

  1. Log in to the ESX/ESXi host as a root user,
  2. Take a backup of the /etc/vmware/config file.
  3. Open the /etc/vmware/config file using a text editor.
  4. Add these entries to the file:

    isolation.tools.copy.disable="FALSE"
    isolation.tools.paste.disable="FALSE"

  5. Save and close the file.

    The Copy and Paste options are only enabled when the virtual machines restart or resume the next time or shutdown and power-on the VM for changes to take effect

Note: These options do not persist after an upgrade. If you upgrade to a newer version after enabling these options, the changes are lost and you may have to re-enable them.

 

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

Clipboard Copy and Paste does not work in vSphere Client 4.1 and later

Starting with vSphere 4.1, the Copy and Paste options are, by default, disabled for security reasons.

 

To enable this option for a specific virtual machine:

  1. Log into a vCenter Server system using the vSphere Client and power off the virtual machine.
  2. Select the virtual machine and click the Summary tab.
  3. Click Edit Settings.
  4. Navigate to Options > Advanced > General and click Configuration Parameters.
  5. Click Add Row.
  6. Type these values in the Name and Value columns:Name                                                Value
    • isolation.tools.copy.disable    false
    • isolation.tools.paste.disable   false

    Note: These options override any settings made in the VMware Tools control panel of the guest operating system.

  7. Click OK to close the Configuration Parameters dialog, and click OK again to close the Virtual Machine Properties dialog.
  8. Power on the virtual machine.

Note: If you vMotion a virtual machine to a host where the isolation.tools.*="FALSE" is already set, the copy and paste options are automatically activated for that virtual machine.

To enable this option for all the virtual machines in the ESX/ESXi host:

  1. Log in to the ESX/ESXi host as a root user and open the /etc/vmware/config file using a text editor.
  2. Add these entries to the file:isolation.tools.copy.disable="FALSE"
    isolation.tools.paste.disable="FALSE"
  3. Save and close the file.The Copy and Paste options are only enabled when the virtual machines restart or resume the next time or shutdown and power-on the VM for changes to take effect

Note: These options do not persist after an upgrade. If you upgrade to a newer version after enabling these options, the changes are lost and you may have to re-enable them.

 

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

Disabling the Windows Logon Screen Saver

Screen savers are not necessary for virtual machines, to disable Windows Logon Screen Saver:
  1. Click Start > Run, type regedit, click OK.
  2. Locate the following registry key:

    HKEY_USERS\.DEFAULT\Control Panel\Desktop

  3. Double-click the ScreenSaveActive string value item in the Details pane.
  4. In the Value data box, replace the number 1 with the number 0 , and then click OK.

Alternatively, you can save the attached registry file and double click it. The key above is set for you (Windows 2000 and 2003 only).

Configuring SNMP Traps for ESX 3.5 and ESX 4.0

Details

To generate virtual machine and environmental traps from ESX 3.5 and ESX 4.0 hosts, you must configure and enable the embedded SNMP agent. You cannot use the Net-SNMP-based agent to generate these traps, although it can receive GET transactions and generate other types of traps.
 
This represents a change in behavior from ESX 3.0.x, in which the configuration file for the Net-SNMP-based agent controlled the generation of virtual machine traps. For more information, see Configuring SNMP on an ESX 3.0.x host (1008186).

Solution

Use the vicfg-snmp command from the Remote CLI or vSphere CLI to enable this SNMP agent and configure trap destinations. Each time you specify a target with the vicfg-snmp command, the settings you specify overwrite all previously specified settings. To specify multiple targets, specify them in a single command, separated by commas.

To enable and configure SNMP traps:
 
Note: For ESX 3.5, use the Remote CLI. For ESX 4.0, use the vSphere CLI. The commands for both are same.  vicfg-snmp.pl is located in the C:\Program Files\VMware\VMware vSphere CLI\bin directory after the VMware vSphere CLI installation, by default.
 
  1. Specify the communities and trap targets with the command:

    vicfg-snmp.pl –server <hostname> –username <username> –password <password> -t <target hostname>@<port>/<community>

    Note: Under ESX 4.0, you may need to use the -c <community> flag.

    For example, to send SNMP traps from the host host.example.com to port 162 on target.example.com using the public community, use the command:

    vicfg-snmp.pl –server host.example.com –username root –password password -t target.example.com@162/public
     

  2. To enable the SNMP service, run the command:

    vicfg-snmp.pl –server <hostname> –username <username> –password <password> –enable
     

  3. (Optional) Send a test trap to verify that the agent is configured correctly with the command:

    vicfg-snmp.pl –server <hostname> –username <username> –password <password> –test

The test trap generated is a warmStart trap.

source: http://kb.vmware.com/kb/1008065

CPUID – VMotion CPU Compatibility

We have problems doing a vmotion (ESX 4) from virtual machines from a Dell R710 to a Dell PowerEdge 2950. It gives a SSE4.2 error before we can vmotion it.

A quick solution is to set CPU Masks. To do this, do the following:

  1. Shut down the server
  2. Edit settings
  3. Go to Options
  4. Choose CPUID Mask
  5. Select the Expose Options
  6. Click Advanced
  7. Set the following options:
    Feature Level Row Mask
    SSE4.2 1 ecx —- —- 0–0 —- —- —- —- —-
    80000001 edx —- 0— —- —- —- —- —- —-
  8. Press OK twice

Now you can do a vmotion.