| Subcribe via RSS

Netcat for VMware ESX 3.5

August 23rd, 2010 | No Comments | Posted in Software, vmware

How to install Netcat on VMware ESX 3.5.
When migrating from a standalone VMware ESX 3.5 server to a vSphere 4.x server, you might want to use netcat and tar. Instead of using SCP.
Why? Because VMWare ESX throttles the service console, resulting in ridiculously low speeds (everything from 5-15 MB/s on a 1Gbit).

By using tar and SCP, you should be able to get at least 30 MB/s.

But, netcat is NOT included in VMware ESX 3.5. It is included in 2.5 and 4.x.

So how do you install netcat on VMware ESX 3.5?

1. Grab the RPM here:

(Don’t use any newer versions, like 1.10, because you will run into dependencies problems, like this:
[root@vmware-esx]# rpm -ivh netcat-1.10-980.1.i586.rpm
warning: netcat-1.10-980.1.i586.rpm: V3 DSA signature: NOKEY, key ID 9c800aca
error: Failed dependencies:
libc.so.6(GLIBC_2.3.4) is needed by netcat-1.10-980.1
rpmlib(PayloadIsLzma) <= 4.4.2-1 is needed by netcat-1.10-980.1 [root@vmware-esx] 2. Install the RPM: rpm -ivh netcat-0.7.1-1.i386.rpm [root@vmware-esx bin]# rpm -ivh netcat-0.7.1-1.i386.rpm warning: netcat-0.7.1-1.i386.rpm: V3 DSA signature: NOKEY, key ID b2d79fc1 Preparing... ########################################### [100%] 1:netcat ########################################### [100%] [root@vmware-esx] And you’re done!

Tags: , , , , ,

How to kill a VM (VMware ESX 4.0)

July 6th, 2010 | No Comments | Posted in vmware

Alright, it happens from time to time. Virtual Machines get stuck.
Sometimes during boot, sometimes during shutdown and sometimes during a restore operation.

So how do I kill a Virtual Machine?

I wrote this post, back in 2009, for ESX 3.5:

Both the “vmware-cmd /.vmx stop hard” method, and the following methods work, sometimes.. :

1. sudo vm-support -x
2. sudo less -S /proc/vmware/vm//cpu/status
3. sudo /usr/lib/vmware/bin/vmkload_app -k 9

But, when both of those fail? Then what?
How to kill a stuck VM when everything else fails?

It’s a bit brutal, but it works, but be warned, you might corrupt your VM.

1. sudo bash (for simplicity)
2. ps -ax | grep 3. Find the first number to the left, in the string with the right VM. This is the PID.
4. kill -9

Brutal? Yes. Efficient? Yes.

Tags: , , , , , , , , , , , ,

ESX 3.x and ESXi 3.x command line guide

January 5th, 2009 | No Comments | Posted in Software

While googling around for some documentation of some ESX specific commands, I discovered this command line reference guide for ESX 3.x and ESXi 3.x , written by B2V.

Its worth taking a look at.

Tags: , , , , ,

Howto: enable ssh on ESXi 3.5

October 16th, 2008 | No Comments | Posted in Software

By default, ssh access is disabled on VMware ESXi 3.5, so how do i enable ssh on VMware ESXi 3.5?

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


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!

Tags: , ,

VMWare ESX 3.5 express patch working

August 13th, 2008 | No Comments | Posted in Software

I can now confirm that the express patch VMWare released earlier today is working (tested on ESXi 3.5).

Tags: , , , , ,

VMware ESX 3.5.x Bug Update!

August 13th, 2008 | No Comments | Posted in Software

The express patch is here! VMWare released it some hours ago. You can download it, and read more on VMWare’s page: VMware ESX/ESXi 3.5 Update 2 Patch Release

Tags: , , , , ,

VMware ESX 3.5.x Bug and the solution

August 12th, 2008 | No Comments | Posted in Software

Ok, so there is a really big bug in VMWare ESX 3.5/3.5i Update 2. So if you are running an older version, don’t upgrade! If you try to power on or resume a suspended Virtual Machine, you get the following error:

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.

Tags: , , , ,