Knowledge Base

VMWare

Expand allClose all

Convert a drive from IDE to SCSI in VMWare

Converting a virtual IDE disk to a virtual SCSI disk (1016192)

Symptoms

•Virtual machine contains an IDE virtual disk as the primary OS bootable disk after conversion from physical source.
•Virtual machine has an IDE virtual disk but the additional secondary virtual disks are SCSI with an LSI or Bus Logic controller.
•Virtual machine fails to boot with only a black screen after conversion with possible underscore. The Primary disk is an IDE virtual disk but LSI or Bus Logic was selected during conversion.
•After conversion using P2V, the virtual machine fails to boot.
•Virtual machine created after P2V failed between 95% and 99% and fails to boot.
•After powering off a virtual machine, you are unable to increase the size of its hard disk(s) when the disk is not SCSI based.

Resolution

When converting a physical machine to a virtual machine using VMware Converter or vCenter Converter Enterprise, if an adapter type is not selected during the initial customization the resulting virtual machine may contain an IDE disk as the primary OS disk.

You must convert the IDE disk to SCSI to get the best performance. If the primary disk is an IDE virtual disk, the newly converted virtual machine may fail to boot because the guest OS does not support the driver. Second reason for this issue is that in ESX 4.x the default disk type for Windows XP 32bit virtual machine creation is IDE. This default value can be manually changed during the virtual machine creation wizard by selecting the custom option. Windows XP 64bit will still use SCSI by default.

Note: For newer versions of Windows and Linux OS guests, the typical SCSI adapter types are the LSI Logic controllers. When using LSI Logic SCSI controllers in the Windows XP virtual machine, ensure to download and install the appropriate LSI driver before proceeding. For more information on downloading and installing LSI Logic SCSI drivers, see Storage Drivers for ESX 3.5.x and Microsoft Windows XP When Using the VMware LSI Logic Storage Adapter (1007035).

In situations where you are manually changing an IDE disk to a SCSI disk that holds a Windows Operating system volume, you may need to repair the master boot record of the disk. Please see Repairing boot sector problems in Windows NT-based operating systems (1006556)

To convert the IDE disk to SCSI:
1.Locate the datastore path where the virtual machine resides.

For example:

# cd /vmfs/volumes///

2.From the ESX Service Console, open the primary disk (.vmdk) using the vi editor. For more information, see Editing files on an ESX host using vi or nano (1020302)
3.Look for the line:

ddb.adapterType = “ide”

4.To change the adapter type to LSI Logic change the line to:

ddb.adapterType = “lsilogic”

To change the adapter type to Bus Logic change the line to:

ddb.adapterType = “buslogic”

5.Save the file.
6.From VMware Infrastructure/vSphere Client: a.Click Edit Settings for the virtual machine.
b.Select the IDE virtual disk.
c.Choose to Remove the Disk from the virtual machine.
d.Click OK.

Caution: Make sure that you do not choose delete from disk.

7.From the Edit Settings menu for this virtual machine: 1.Click Add > Hard Disk > Use Existing Virtual Disk.
2.Navigate to the location of the disk and select to add it into the virtual machine.
3.Choose the same controller as in Step 3 as the adapter type. The SCSI ID should read SCSI 0:0.

8.If a CDROM device exists in the virtual machine it may need to have the IDE channel adjusted from IDE 0:1 to IDE 0:0. If this option is greyed out, remove the CD-ROM from the virtual machine and add it back. This sets it to IDE 0:0

Mark as helpful. 0

No more space for the redo log error when attempting to start a virtual machine

No more space for the redo log error when attempting to start a virtual machine

Details

When starting a virtual machine, a dialog appears stating there is no more space for the redo log , and prompts you to retry or abort.

Solution

The datastore in which the virtual machine resides in is out of disk space. The following are steps used to commit all snapshots and attain additional disk space.

Note: There may be corruption on the last snapshot if the virtual machine was abruptly powered down due to lack of disk space.

Identify any virtual machine with snapshots by running the following command at the service console:
1.Log into the console of the ESX host as root.
2.Run the following command:

find /vmfs/volumes -name *-0000[0-9][0-9]*.vmdk
3.Make note of all the file locations and the virtual machine names which include delta VMDK files.

All snapshots must be successfully committed to free up any disk space within the datastore. The snapshot commit process can be done in one of several ways.

Commit via the Virtual Infrastructure Client
1.Right-click on the identified virtual machine.
2.Click Snapshot > Snapshot Manager.
3.Click Delete All to commit all of the snapshots to the parent disk.

Commit via the Command Line
1.Log into the Service Console of the ESX host hosting the identified virtual machine as root.
2.Run the following command to list the virtual machines being hosted by this ESX host:

vmware-cmd -l
3.Run the following command to commit all snapshots of the virtual machine:

vmware-cmd removesnapshots

Note: There is no way to predetermine how long the commit process takes. If the size of the snapshot files are large, the commit process may exceed the default timeout of the VI Client, and a timeout message may be reported. Despite this timeout message, the commit process continues with no progress bar or status indicator. There is no way to predetermine the amount of time it takes to commit the snapshot as it depends too many factors which include, but are not limited to, snapshot size, array performance, HBA performance, fiber/network performance, and load.

In the event that space is an issue, there are certain operations which can be conducted to free up space for the purposes of committing the snapshots. The operations include:
1.Powering off the virtual machine

This operation deallocates the swap file. A virtual machine’s swap file is usually the same size as the allocated amount of RAM. This operation does not have to be done to the machine which is running off of the snapshot. If the issue is affecting a production virtual machine, non-production machines residing in the same datastore can be powered off to free up storage for the commit operation. For more information, see http://www.vmware.com/pdf/esx3_memory.pdf .
2.Add an extent to the existing datastore

If there is a lack of disk space, the Add Extent wizard can be used to increase the amount of space available to this datastore. The Add Extent operation is irreversible, and creates a dependence of multiple LUNs for a single datastore. For more information, see http://www.vmware.com/pdf/vmfs-best-practices-wp.pdf .
3.Clone the virtual machine to a datastore that has more space

To clone the virtual machine to a datastore that has more space:
a.Right-click on the virtual machine which had been identified.
b.Select Clone.
c.Go through the clone wizard and select a datastore with adequate space.
d.Verify that the clone has no snapshots.
e.Start up the clone of the original virtual machine and verify that it is functioning in the same capacity as the original virtual machine.

Mark as helpful. 0

The Host IPMI System Event Log Status alarm is triggered repeatedly – VMWare

To determine why the log has filled up, investigate the hardware.

To stop the alarm from triggering repeatedly, clear the IPMI System Event log and reset the sensors.

To clear the log and to reset the sensors:
1.Open vCenter Server using vSphere Client.
2.In the vCenter inventory, select the ESX/ESXi host.
3.Click the Hardware Status tab.
4.Click System Event log under View and click the Reset Event log option. The red alert is removed from the System Event log.
5.Click the Reset Sensors option to reset the host sensors.

Additional Information

If you find an incorrect date and if you are unable to reset the logs, restart the management agents and sfcbd-watchdog on ESX, or the management agents on ESXi.

•From the console on ESX, run the command:

/etc/init.d/sfcbd-watchdog restart

Mark as helpful. 7

Disable HP services on VMWare server

@echo off REM Created Feb 13 2008 by Lawrence Dee REM —– REM INSTRUCTIONS: REM This is a script to disable the HP services REM to ease use in a Virtual Machine

REM —– REM – Set services to Manual (=’demand’ in SC) rather than Auto start pause

sc config “Cissesrv” start= demand sc config “CpqNicMgmt” start= demand sc config “CpqRcmc” start= demand sc config “cpqvcagent” start= demand sc config “cqmghost” start= demand sc config “CqMgServ” start= demand sc config “CqMgStor” start= demand sc config “sysdown” start= demand sc config “SysMgmtHp” start= demand

:STOPServices REM – stop services sc stop “Cissesrv” sc stop “CpqNicMgmt” sc stop “CpqRcmc” sc stop “cpqvcagent” sc stop “cqmghost” sc stop “CqMgServ” sc stop “CqMgStor” sc stop “sysdown” sc stop “SysMgmtHp”

pause

GOTO EXIT

REM Notes and descriptions from SC Query

SERVICE_NAME: Cissesrv DISPLAY_NAME: HP Smart Array SAS/SATA Event Notification Service

SERVICE_NAME: CpqNicMgmt DISPLAY_NAME: HP Insight NIC Agents

SERVICE_NAME: CpqRcmc DISPLAY_NAME: HP ProLiant Remote Monitor Service

SERVICE_NAME: cpqvcagent DISPLAY_NAME: HP Version Control Agent

SERVICE_NAME: CqMgServ DISPLAY_NAME: HP Insight Server Agents

SERVICE_NAME: CqMgStor DISPLAY_NAME: HP Insight Storage Agents

SERVICE_NAME: sysdown DISPLAY_NAME: HP ProLiant System Shutdown Service

SERVICE_NAME: SysMgmtHp DISPLAY_NAME: HP System Management Homepage

REM – not listed in SC Query cqmghost.exe HP Insight Foundation Agents :EXIT

Mark as helpful.

Use Command Line to Power off a Virtual Machine – VMWare

Using the ESXi 5.x esxcli command to power off a virtual machine

The esxcli command can be used locally or remotely to power off a virtual machine running on ESXi 5.x. For more information, see the esxcli vm Commands section of the vSphere Command-Line Interface Reference.

  1. Open a console session where the esxcli tool is available, either in the ESXi Shell, the vSphere Management Assistant (vMA), or the location where the vSphere Command-Line Interface (vCLI) is installed.
  2. Get a list of running virtual machines, identified by World ID, UUID, Display Name, and path to the .vmx configuration file, using this command:
    esxcli vm process list
  3. Power off one of the virtual machines from the list using this command:
    esxcli vm process kill --type=[soft,hard,force] --world-id=WorldNumber
    Notes: Three power-off methods are available. Soft is the most graceful, hard performs an immediate shutdown, and force should be used as a last resort. Alternate power off command syntax is: esxcli vm process kill -t [soft,hard,force] -w WorldNumber
  4. Repeat Step 2 and validate that the virtual machine is no longer running.

For ESXi 4.1:

  1. Get a list of running virtual machines, identified by World ID, UUID, Display Name, and path to the .vmx configuration file, using this command:
    esxcli vms vm list
  2. Power off one of the virtual machines from the list using this command:
    esxcli vms vm kill --type=[soft,hard,force] --world-id=WorldNumber

Using the ESXi command-line utility vim-cmd to power off the virtual machine

  1. On the ESXi console, enter Tech Support mode and log in as root. For more information, see Tech Support Mode for Emergency Support (1003677).
  2. Get a list of all registered virtual machines, identified by their VMID, Display Name, and path to the .vmx configuration file, using this command:
    vim-cmd vmsvc/getallvms
  3. To get the current state of a virtual machine:
    vim-cmd vmsvc/power.getstate VMID
  4. Shutdown the virtual machine using the VMID found in Step 2 and run:
    vim-cmd vmsvc/power.shutdown VMID
    Note: If the virtual machine fails to shut down, use this command:
    vim-cmd vmsvc/power.off VMID

Mark as helpful. 0

Snapshot Consolidation in VMware ESXi 5.5 fails

Symptoms

  • Cannot perform snapshot consolidation in VMware ESXi 5.5 and ESXi 6.0.x.
  • Performing a snapshot consolidation in ESXi 5.5 fails.
  • When attempting to consolidate snapshots using the vSphere Client, you see the error:
    • maximum consolidate retries was exceeded for scsix:x
    • Consolidate Disks message: The virtual machine has exceeded the maximum downtime of 12 seconds for disk consolidation

Cause

This issue occurs because ESXi 5.5 introduced a different behavior to prevent the virtual machine from being stunned for an extended period of time.
This message is reported if the virtual machine is powered on and the asynchronous consolidation fails after 10 iterations. An additional iteration is performed if the estimated stun time is over 12 seconds.This occurs when the virtual machine generates data faster than the consolidated rate.
In comparison with previous version of ESXi, if the asynchronous consolidation fails after 10 iterations, the virtual machine is stunned until the remaining data is consolidated. For more information, see Virtual machines become unresponsive for over 30 minutes when removing a snapshot (2039754).

Resolution

To resolve this issue, turn off the snapshots consolidation enhancement in ESXi 5.5 and ESXi 6.0.x, so that it works like earlier versions of ESX/ESXi. This can be done by setting the snapshot.asyncConsolidate.forceSync to TRUE.
Note: If the parameter is set to true, the virtual machine is stunned for long time to perform the snapshot consolidation, and it may not respond to ping during the consolidation.

To set the parameter snapshot.asyncConsolidate.forceSync to TRUE using the vSphere client:

  1. Shut down the virtual machine.
  2. Right-click the virtual machine and click Edit settings.
  3. Click the Options tab.
  4. Under Advanced, right-click General
  5. Click Configuration Parameters, then click Add Row.
  6. In the left pane, add this parameter:
    snapshot.asyncConsolidate.forceSync
  7. In the right pane, add this value:
    TRUE
  8. Click OK to save your change, and power on the virtual machine.

To set the parameter snapshot.asyncConsolidate.forceSync to TRUE without shutting down the virtual machine, run this Powercli command:
get-vm virtual_machine_name | New-AdvancedSetting -Name snapshot.asyncConsolidate.forceSync -Value TRUE -Confirm:$False
Note
: To work around this issue, when under heavy IO load, you can alternatively retry snapshot consolidation at a time when the virtual machine is issuing less IO.

Additional Information

To be alerted when this article is updated, click Subscribe to Document in the Actions box.

 

You can increase the time limit on the snapshots consolidation by changing the configuration parameters.

 

To change the Configuration parameter to increase the time limit on the snapshots consolidation:

  1. Shut down the virtual machine.
  2. Right-click the virtual machine and click Edit Settings.
  3. Click the Options tab.
  4. Under Advanced, click General.
  5. Click Configuration Parameters and add snapshot.maxConsolidateTime = 30.

Mark as helpful. 0

After Installing or Upgrading to vCenter Server 6.0, logging in to the vSphere Web Client for all users reports the error: You do not have permissions to view this object or this object does not exist

After installing or upgrading to vCenter Server 6.0 on Windows, you experience these symptoms when logging into the vSphere Web Client with any authorized user account:

  • When browsing to any object, you see the error:

    You do not have permissions to view this object or this object does not exist

  • In the %ProgramData%\VMware\vCenterServer\runtime\VMwareSTSService\logs\lookupServer.log file on the Platform Services Controller, you see entries similar to:
[YYYY-MM-DDTHH:MM:SS:MS-04:00 pool-2-thread-1  ERROR com.vmware.vim.lookup.vlsi.util.VmodlEnhancer] Unable to load library ‘vmafdclient’: The specified module could not be found.
java.lang.UnsatisfiedLinkError: Unable to load library ‘vmafdclient’: The specified module could not be found.

[YYYY-MM-DDTHH:MM:SS:MS-04:00 pool-7-thread-1  ERROR com.vmware.vim.vmomi.server.impl.SoapBindingImpl] Method ‘list’ completed with undeclared fault of type ‘LookupFaultServiceFault’
(lookup.fault.ServiceFault) {
   faultCause = null,
   faultMessage = null,
   errorMessage = Unable to load library ‘vmafdclient’: The specified module could not be found.


[YYYY-MM-DDTHH:MM:SS:MS-04:00 pool-2-thread-1  INFO  com.vmware.vim.lookup.vlsi.VlsiSecurityChecker] Operation create is permitted for user {Name: machine-6b018b31-b0fb-11e3-a918-0050569817d1, Domain: vsphere.local}

[YYYY-MM-DDTHH:MM:SS:MS-04:00 pool-2-thread-1  ERROR com.vmware.vim.lookup.vlsi.util.VmodlEnhancer] Could not initialize class com.vmware.af.interop.VmAfClientAdapter$VmAfClientLibrary
java.lang.NoClassDefFoundError: Could not initialize class
com.vmware.af.interop.VmAfClientAdapter$VmAfClientLibrary

  • In the %ProgramData%\VMware\vCenterServer\logs\vapi\endpoint\endpoint.log file on the vCenter Server, you see entries similar to:

YYYY-MM-DDTHH:MM:SS:MS-04:00 | ERROR | state-manager1            | ComponentManagerClientWrapper  | Service lookup failed.
java.util.concurrent.ExecutionException: (cis.cm.fault.ComponentManagerFault) {

  • In the %ProgramData%\VMware\vCenterServer\logs\cm\cm.log file on the Platform Services Controller, you see entries similar to:

YYYY-MM-DDTHH:MM:SS:MS-04:00 [pool-14-thread-1  WARN  com.vmware.cis.services.cm.service.impl.LsVmomiSiteStore (46db3ac0-a783-422a-a8cf-ec9b7d19ba85)] Call to lookup service failed; uri:https://<Platform_Services_Controller_FQDN>/lookupservice/sdk [(vmodl.fault.SystemError) {

   faultCause = null,
   faultMessage = null,
   reason = Invalid fault
}]

YYYY-MM-DDTHH:MM:SS:MS-04:00 [pool-14-thread-1  ERROR com.vmware.cis.services.cm.service.ServiceManagerImplTemplate (46db3ac0-a783-422a-a8cf-ec9b7d19ba85)] search v1: Failed to search

(vmodl.fault.SystemError) {
   faultCause = null,
   faultMessage = null,
   reason = Invalid fault

Note: The preceding log excerpts are only examples. Date, time, and environmental variables may vary depending on your environment.

Cause

This issue occurs when the Local System user overrides the Local Machine‘s Path registry key and prevents the VMware Secure Token Service (STS) from starting properly.

Resolution

This is a known issue affecting VMware vCenter Server 6.0.

Currently, there is no resolution.

To workaround this issue, use any one of these options:
  • Rename the Path Registry Key

    Note: Use this method if you do not need this Path registry key for the Local System and can use the system wide path from Local Machine, you can remove this path.

  • Include Addition Values to the Path Registry Key

    Note: Use this method if you require the Local System Path registry to remain unique for you Windows system.

Rename the Path Registry Key (Simple)
If you do not need this Path registry key for the Local System and can use the system wide path from Local Machine, you can remove this path.

Note: This procedure modifies the Windows registry. Before making any registry modifications, ensure that you have a current and valid backup of the registry and the virtual machine. For more information on backing up and restoring the registry, see the Microsoft Knowledge Base article 136393.

  1. Connect to the external Platform Services Controller or the vCenter Server with Embedded Platform Services Controller remotely as a local administrator.
  2. Click Start > Run, type regedit, and click OK. The registry editor window opens.
  3. Navigate to the Environment registry key for Local System:

    HKEY_USERS\S-1-5-18\Environment

  4. Right-Click on Path and select Rename.
  5. Set the name of the registry key to Old_Path.
  6. Restart the VMware Secure Token Service. For more information, see Stopping, starting, or restarting VMware vCenter Server 6.0 services (2109881).
Including Addition Values to the Path Registry Key (Advanced)
If you require the Local System Path registry to remain unique for your Windows system.

Note: This procedure modifies the Windows registry. Before making any registry modifications, ensure that you have a current and valid backup of the registry and the virtual machine. For more information on backing up and restoring the registry, see the Microsoft Knowledge Base article 136393.

  1. Connect to the external Platform Services Controller or the vCenter Server with Embedded Platform Services Controller remotely as a local administrator.
  2. Click Start Run, type regedit, and click OK. The registry editor window opens.
  3. Navigate to the Path registry key for Local Machine:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment

  4. Right-click Path and click Modify….
  5. Locate and copy the MIT\kerberos path contained with the key.

    By default, MIT\kerberos this path should be:

    c:\Program Files\MIT\Kerberos\bin

  6. Navigate to the Environment registry key for Local System:

    HKEY_USERS\S-1-5-18\Environment

  7. Right-click Path and click Modify….
  8. Append the the MIT\kerberos path from Step 5 to the registry key’s Value data field.

    Use the following as a model:

    C:\Program Files\System Center Operations Manager 2007;c:\Program Files\MIT\Kerberos\bin

  9. Click OK.
  10. Restart the VMware Secure Token Service. For more information, see Stopping, starting, or restarting VMware vCenter Server 6.0 services (2109881).

Mark as helpful. 0

All Changes Revert Back After Reboot/Shutdown And BSOD (CtxMcsWbc.sys) in XenApp 7.11

Symptoms or Error

  1. VDA will randomly crash with BSOD.
  2. All changes in master image machine (with local HDD) will revert back after reboot/shutdown.

Solution

Cause 1: 
“PvsVmBoot” is missing from below mentioned registry location
Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager
Name: BootExecute
Type: REG_MULTI_SZ

Solution 1:

  1. Shutdown the VM.
  2. Boot the VM with Hiren’s Boot ISO (http://www.hirensbootcd.org/download/)
  3. Launch Mini XP
  4. Edit registry with Registry Editor PE (Step 3: https://www.wintips.org/how-to-edit-and-modify-registry-offline/)
  5. Expand below mentioned registry location and edit “BootExecute” registry string HKEY_LOCAL_MACHINE\REMOTE_SYSTEM\ControlSet001\Control\Session Manager

User-added image

 

  1. Verify the same under HKEY_LOCAL_MACHINE\REMOTE_SYSTEM\ControlSet002\Control\Session Manager
  2. Close Registry Editor
  3. Remove Hiren’s Boot CD from boot order and reboot the VM.

 

Cause 2:
CtxMcsWbc.sys Driver is not behaving as expected

 

NOTE: The workaround provided below with effectively disable this driver and leave the VDA in a state that is inconsistent.

This workaround may be used for troubleshooting, but will leave the VDA in an inconsistent state. This driver controls the MCS I/O  Optimization feature The full effect of disabling this driver is not clear at this point.

Workaround

  1. Shutdown the VM.
  2. Boot the VM with Hiren’s Boot ISO (http://www.hirensbootcd.org/download/)
  3. Edit registry with Registry Editor PE
  4. Disable the Citrix MCS cache service by changing the Start value from 0 to 4 from the following sub key:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CtxMcsWbc
  5. Delete the “CtxMcsWbc” entry in the “UpperFilters” value in the following sub key:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4d36e967-e325-11ce-bfc1-08002be10318}
  6. Unload the System hive from the mounted VHD.
  7. Detach the mounted VHD.
  8. Start the VM  normally.

Recommendation
Upgrade to XenDekstop 7.15


Problem Cause

Issue with CtxMcsWbc.sys Driver.


Additional Resources

This is a known issue and has been fix in XenDesktop 7.14 [LC6488]

Affected version: XenDekstop 7.9 & 7.11

Mark as helpful. 0

WINDOWS VM BLUE SCREEN “CRITICAL_STRUCTURE_CORRUPTION”

On a Windows Server Virtual Machine that is running VMWare ESXi 5.0.x, you receive a “CRITICAL_STRUCTURE_CORRUPTION” Stop error code that begins as follows:

Bugcheck code 00000109
Arguments a3a01f58`92797517 b3b72bde`e4f976b6 00000000`c0000103 00000000`00000007

To resolve this problem, go to the following VMWare website:

Windows 8.1/Windows Server 2012 virtual machines fail with a blue screen and report the error: CRITICAL_STRUCTURE_CORRUPTION (2060019)

This is a known issue that affects ESXi 5.0.x. For more information, contact VMWare.

To work around this issue, manually create a CPUID mask for the affected virtual machines. To do this, follow these steps:

  1. Turn off the virtual machine.
  2. Right-click the virtual machine, and then click Edit Settings.
  3. Click the Options tab.
  4. Under Advanced, click CPUID Mask.
  5. Click Advanced.
  6. In the Register column, locate the edx register under Level 80000001.
  7. In the Value field, enter the following character string exactly:

    —-:0—:—-:—-:—-:—-:—-:—-

  8. Click OK two times.

The third-party products that this article discusses are manufactured by companies that are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, about the performance or reliability of these products.

https://support.microsoft.com/en-us/help/2902739/stop-error-0x109-critical-structure-corruption-on-a-vmware-virtual-mac
https://kb.vmware.com/s/article/2060019?sliceId=1&dialogID=158133794&docTypeID=DT_KB_1_1&stateId=0+0+158145165

Mark as helpful. 0

Update Firmware on HP ESXI Host

You want to run a HP CPxxxxxx.scexe firmware update file on your ESXi Host and it doesn’t work?

Follow the steps below to make it happen – most problems are caused by the missing executable permission:

  • enable SSH on your ESXi host (configuration tab, Security Profile, Properties)
  • copy the CPxxxxxx.scexe file to /tmp on your ESXi Host using eg. WinSCP
  • logon as root at your ESXi host and change to /tmp
  • check with “ls” if your CP file is there
  • change file permission to executable: “chmod +x CPxxxxxx.scexe”
  • now run the file: “./CPxxxxxx.scexe”

update_HP_CP

Once complete reboot the ESXi host – done!

 

Mark as helpful. 0