Showing posts with label vmware. Show all posts
Showing posts with label vmware. Show all posts

Thursday, October 6, 2016

Cisco UCS C220M4s and the Purple Screen of Death - Could not start pcpu 1: TSC sync timed out

Recently, I had to install ESXi 5.5 on a Cisco rackmount server. VMware crashed with the purple screen of death.

Here's the display:


These are relatively new servers, so there was nothing especially helpful on the web. Other people had this problem, but I couldn't find any real solutions, other than a reference to C states on the CPU.

I experimented a bit and figured that CPU power savings might be the problem (I'd seen this before on Opteron servers.)

The fix is to set CPU performance to HPC (it defaults to Enterprise) in BIOS:


That's advanced -> CPU Performance -> HPC (from Enterprise)

This solved the problem. 

Sunday, September 8, 2013

Enable SNMP Traps on VMware ESXi 5.x

1. Make sure you have the VMware CLI tools installed

  - from the command line prompt in the CLI tools directory, enable the SNMP service:


C:\Program Files (x86)\VMware\VMware vSphere CLI>vicfg-snmp.pl --server my.servername.or.ip
 --username root --enable

2. Set up a target (or two)

C:\Program Files (x86)\VMware\VMware vSphere CLI>vicfg-snmp.pl --server my.servername.or.ip
. --username root -t mysnmptraptarget@162/snmptrapcommunity

3. Send a test message

C:\Program Files (x86)\VMware\VMware vSphere CLI>vicfg-snmp.pl --server my.servername.or.ip
 --username root --test

Monday, August 12, 2013

VMware ESXi: Recovering from Accidental Changes to the Ethernet Address/VM uuid

I recently ran into an issue that presented itself in two forms:


Scenario 1: Moving a VM from Workstation to ESXi - MAC/uuid change

    In case 1, a VM was migrated from a VMware Workstation format to an ESXi 5.1 server. The conversion was done using VMware converter. When you use converter, you are not given the option to "move" the VM. The uuid and mac addresses for the interfaces are automatically regenerated. I figured I could just paste the old MAC address into the ethernet configuration on ESXi by using the manual setting. However, I discovered that VMware reserves the MAC addresses starting with 00:0c for auto generation and the VM would not start correctly in ESXi.

The solution is modify the .vmx file for the VM on the ESXi server. I'd recommend copying the vmx file to an alternate name (i.e., cp myVM.vmx myVM.vmx.backup.) Do these changes at your own risk:


1. Shut down the VM

2. SSH to the ESXi server and find the vmx file in question (somewhere in /vmfs/volumes/name/of/vms/directory

3. Edit the file and replace the following 4 (or more lines) with the equivalent values from the Workstation vmx file:


uuid.location = "56 2d af 08 59 0b 10 8c-78 9d 96 3d 9c 82 fe d4"
uuid.bios = "56 2d 92 33 47 3b 9e 16-e1 12 56 db 8f 32 4f 3f"
vc.uuid = "52 c3 f7 68 14 da 8f a4-16 a1 d1 54 07 85 f3 16"
ethernet0.generatedAddress = "00:0c:31:33:4a:3f"

You may have more than one ethernet interface, so change them all.

4. Remove the VM from the ESXi server's inventory (but do not remove it from Disk!), so that it will notice the change (this is done in configuration -> storage management, of course.)

5. Add it back to the machine's inventory

6. When you start it up now, it should have the same ethernet MAC addresses.

Scenario 2: Moving a VM by removing it from the inventory of one ESXi host to another ESXi host

    In this case, the VM was shut down. It resided on shared storage, so the other hypervisor head could see it. When importing it into the new machine, the person performing the operation chose "I copied it" instead of "I moved it."

This was more complex. The solution is very, very similar.


1. ssh to the new ESXi host

2. cd to the VM's directory

3. look for old log files and cat out the info you need (for instance, if the "copy" happened today, a log file from yesterday would suffice (ls -la vmware*.log)

4. Assuming the older log file is called vmware-1.log,

cat vmware-1.log | egrep  egrep "(generatedA|uuid)" > mydata.txt

5. make a backup copy of the vmx file

6. look in the mydata.txt file and grab the data you need.

7. edit the vmx file and replace the appropriate lines from the current config with the config from the mydata.txt file. You'll need to remove some text from mydata.txt

8. remove the host from ESXi's inventory and re-add it.


Monday, November 12, 2012

VMware Workstation 9 and Windows 8 - Hyper-V issues

I recently installed Windows 8 on a laptop, as well as VMware workstation 9. Later on, I added Hyper-V roles. When I tried to power Workstation back up, I got the following error message:

VMware Workstation and Hyper-V are not compatible. Remove the Hyper-V role from the system before running VMware Workstation.


Removing the  Hyper-V role, entirely, seems to suffice. I tried removing the Hyper-V role and shutting down the Hyper-V management service without rebooting, but that did not help. After rebooting, the Hyper-V management service was gone and VMware Workstation could launch VMs properly again.


Saturday, January 28, 2012

Patching Changes with ESXi 5.x

updated 12/14/2014

VMware has been pushing people to buy their update manager for a while, but they allowed command line updates through a perl utility in the vSphere cli bundle. To use that procedure on a 4.x ESXi server, look at this post:
Upgrading to ESXi 4.1 from 4.0

To update ESXi 5.x, download the patches from the VMware Patch Portal, upload the patch or patches to a datastore on the ESXi 5.x server. You'll need to update your VMware cli tools. The easiest way to download it is to browse to the web server on the management interface of your ESXi 5.x server (https://ip_address_or_hostname_of_your_esxi5_server)

You'll see it on the upper right:

vSphere Remote Command Line


You'll also need to enable ESXi cli on the ESXi server (it's in the console in the same location that you enable SSH) as well as set the server to maintenance mode.

You can then run the esxicli utility.

You need to know the name of the patch bundle and its location on the datastore. For my server, I was able to list the patch contents of the bundle like so:

G:\Program Files (x86)\VMware\VMware vSphere CLI>bin\esxcli.exe --server=my_server_ip --username=root software sources vib list --depot=/vmfs/volumes/datastore1/patches//ESXi500-201112001.zip


as well as a large list of patches

And I installed it:


G:\Program Files (x86)\VMware\VMware vSphere CLI>bin\esxcli.exe --server=my_server_address --username=root software vib update --depot=/vmfs/volumes/datastore1/patches/ESXi500-201112001.zip
Enter password:
Installation Result
   Message: The update completed successfully, but the system needs to be reboot
ed for the changes to be effective.
   Reboot Required: true

as well as a list of patches. Of course, after that you need to reboot and exit maintenance mode.

vSphere local patching over SSH

 There is no need to even install the esxcli tool. You can simply 1. copy the zip file over 2. enable ssh (security profile - just start the ssh service) and run esxcli after connecting via ssh as an admin user.

The command line is a little different as you have no need for a username or a server name, nor do you need .exe on the command, being a linux binary.

i.e.,

esxcli  software vib update --depot=/vmfs/volumes/datastore1/patches/ESXi550-201410001.zip

Friday, August 27, 2010

Upgrading to ESXi 4.1 from 4.0.

I recently needed to update an ESXi 4.0 host to ESXi 4.1. After discovering that the host update utility was not supported with ESXi 4.1, I resorted to my other option, the vSphere CLI.
Here's the session (on Windows 7 64bit):

 C:\Program Files (x86)\VMware\VMware vSphere CLI>bin\vihostupdate.pl --server my_server -b upgrade-from-ESXi4.0-to-4.1.0-0.0.260247-release.zip -i

The output:


 Please wait patch installation is in progress ...
 The update completed successfully, but the system needs to be rebooted for the changes to be effective.


Followed by a reboot:


 C:\Program Files (x86)\VMware\VMware vSphere CLI> bin\vicfg-hostops.pl --server my_server -o reboot

 Host my_server rebooted successfully.