If this for some reasons doesnt work (like me accidentaly deleting the .vmx file), you can try the
following:

1. Run the following command (to get a list of running VMs):
sudo vm-support -x

The output will look something like this:

VMware ESX Server Support Script 1.29

Available worlds to debug:

vmid=1126       vm-01
vmid=1151       vm-02
vmid=1272       vm-03
vmid=1291       vm-04
vmid=1150       vm-05
vmid=1420       vm-06
vmid=1433       vm-07

2. Then run the command (remember to replace the number with the “vmid” of your VM):

less -S /proc/vmware/vm/1433/cpu/status

Press the right arrow key.

In the right corner there should be som info about the “group”:
group
vm.1432

3. By running the following command, you can safely kill your VM without risking corrupting it
(remember to replace the number with your “group number”):
sudo /usr/lib/vmware/bin/vmkload_app -k 9 1432

4. If successful, you should see a message like this:
Warning: Jan 06 06:42:49.717: Sending signal ‘9′ to world 1432.

Share/Save

Its worth taking a look at.

Share/Save

First, get shell access on the console: Howto: ESXi shell access

Then:

1. Type “vi /etc/inetd.conf” and press “enter”.

2. Locate the line that starts with “#ssh     stream  tcp     nowait  root    /sbin/dropbearmulti…….”

3. Move the marker over the “#” and press “x”.

4. Press “Escape” and write “:wq”, then press “enter”.

5. Type “/sbin/services.sh restart” and press “Enter”. Note: If you are running ESXi 3.5 Update 2, the services.sh no longer restarts the inetd process. You will have to manually kill the inetd process, in order to restart it and enable ssh access without a reboot.  Type “ps | grep inetd” and press “enter”. You will then see something similiar to “1289 1289 busybox              inetd”. Then write “kill -HUP 1289″, and remember to write the number “ps | grep inetd” returns to you!

Share/Save

They are trying to patch 3 security issues in VMware Ace, Player and Workstation, and 4 other security issues in VMware server. Read more here: VMware releases updates - don’t forget to patch

Share/Save

1. Hook up a screen and a keyboard to the VMWae ESXi server.
2. Press “Alt+F1″
3. Write “unsupported” and press Enter (if you screw up, and think you’ve typed something wrong,
you can use Ctrl+U to clear the input field).
4. Enter the root password, an voila, shell access.

Share/Save

Share/Save

Share/Save

A general system error occurred: Internal Error
This Product has expired. Be sure that your host machine’s date and time are set correctly.

The products affected are:

• VMware ESX 3.5.x
• VMware ESXi 3.5.x Embedded
• VMware ESXi 3.5.x Installable

There is a knowledge base article about it: Unable to Power On virtual machine with “A General System error occurred: Internal error”

But according to the kb article:

An issue with ESX/ESXi 3.5 Update 2 causes the product license to expire on August 12, 2008. VMware engineering has isolated the root cause of this issue and will reissue the various upgrade media including the ESX 3.5 Update 2 ISO, ESXi 3.5 Update 2 ISO, ESX 3.5 Update 2 upgrade tar and zip files by noon, PST on August 13. These will be available from the page: http://www.vmware.com/download/vi. Until then, VMware advises against upgrading to ESX/ESXi 3.5 Update 2.

The Update patch bundles will be released separately later in the week

So? What if you’ve already upgraded. Some of you might run your entire infrastructure on ESX, and if “waiting for a patch” doesn’t sound like a suitable solution, there is a workaround!

The Workaround

Note: This is only tested on a ESXi 3.5 machine. If you try it on a ESX machine you might need to change the date format, just give it a try.

1. Log in to the Service Console (its the Command Line Interface).

2. Write date -s “08102008″ and press enter.

You should now be able to power on your Virtual Machines (or resume them).

Note: You are setting back the date, so if you are running critical infrastructure on your virtual machines, you might want to turn of “host time sync”. So your VMs won’t sync the time with the server. And if you are running NTP on your ESX/i-server you should turn it off (if you don’t, there is no point in setting back the time).

You also might want to set the time further back, like a couple of weeks, depending on how long time you think VMWare will use to get the patch ready.

Share/Save

Read more details about how the DNS workaround failed in Mac OS X 10.5 or how the DNS Workaround Failed in Mac OS X 10.4

Share/Save

Read the details here: WMware Fusion 2 Beta 2

Share/Save