In fact it is one of the biggest reasons I updated so quickly; I have been running it now for almost 3 months now.

The USB Pass Through feature has been in VMware workstation for a long time (if memory and search serve me right, it was introduced in VMware Workstation 3, which feels like a decade ago).
The first VMware workstation versions supported only a few USB devices, newer versions supported more and more.
The current VMware workstation and player now even support MIDI over USB.

As an alternative in ESX/ESXi, you could use USB over IP (sometimes called USB over Ethernet).
This thread points to a few devices and software solutions that work that way.
Getting those to work wasn’t always easy, as Bob K Merz explains.

ESXi 4.0 added the possibility to add an USB Host Controller to a VM, but you could not connect an USB device through the controller (which is also mentioned in the ESXi 4.0 release notes).

ESXi 4.1 now does allow you to connect an USB device through the controller.

And it is deceptively easy; as easy as VMware workstation!
Quote a few people already wrote how to do it: Christian Mohn (vNinja), Mike (PricklyTech), Roger Lund (with a video), james (peacon blog) and of course the VMware KB.

I have used it for various devices now, and these work like a charm:

• USB Audio Devices (GigaPort HD and GigaPort AG)
• USB hard disks

–jeroen

via: USB Passthrough with ESXi 4.1.

Well, that turned out to be harder than I thought…

Trying to get XP to run on 4 cores in a VM

The conversion went all right, except for one thing:
the VM would recognize 2 CPUs in the Device Manager, but only 1 in the Task Manager.

While researching this, sometimes during a boot, I was getting a “STOP 0x0000007f (0×00000000, 0×00000000, 0×00000000, 0×00000000)“.
Fixing that was easy:

1. Shut down the VM
2. Switch the CPU count of the VM in ESXi to 1
3. Boot the VM in safe mode
4. Reboot the VM in normal mode
5. Shutdown the VM
6. Switch the CPU count of the VM in ESXi to 2
7. Boot the VM in safe mode
8. Reboot the VM in normal mode

Most of the times, you can skip the “safe mode” reboot, but irregularly it is needed.
Better “safe” than sorry :-)

Lets have XP use the 2 cores

Having XP now booting with 2 CPU cores is promising.
The Device Manager correctly showed the 2 CPU cores.
But the Task Manager only showed one.

I went through the usual hoopla of making sure I have this ‘show 1 graph per CPU‘, but I already had that setting right.

The problem was the HAL.
The Device Manager showed the wrong HAL type:
it was “Advanced Configuration and Power Interface (ACPI) PC”  in stead of “ACPI Multiprocessor PC”.
This is because the machine started as a single CPU machine, for which the standard ACPI HAL is sufficient.

Though

For changing the HAL, Microsoft recommends an in-place reinstall of Windows.
I have done that before because of broken drivers, usually with bad results.

So I looked for a way to do this from within the Device Manager, which turns out to be impossible.
That page however, is the best I could find on changing the HAL, and points to “Problems updating to a dualcore CPU Not anymore“, which is an invalid URL because  www.hardware.info just reorganized their site and broke the existing links.

Google to the rescue:  the cache of that page, had a link to HALu-0.2.0.zip. That link was invalid too, but searching for HALu-0.2.0.zip revealed a few download locations, for instance in this virtual box forum thread.

HALu is a wrapper around devcon.exe, which is a command-line interface to the same underlying layer as the Device Manager is a GUI interface to.
You can download the complete devcon package from the Microsoft site.
After having found out about devcon, it appears that HALu is doing the same as this HAL_update.bat batch file on Mike Laverick’s RTFM Education site.
Mike explains this in much more detail (including upgrading from non ACPI systems) in this PDF.

Back to HALu: it is dead easy to use:

1. Run it
2. Select the “ACPI Multiprocessor PC” HAL
3. Let it install
4. Reboot (sometimes it needs to reboot twice)
5. Check if Task Manager shows 2 CPUs
6. Done

Having all the right keywords (devcon, ACPI, etc), I found other posts explaining how to do the multi-core HAL switch: there are many of them if you know what to search for :-)

If HALu doesn’t cut it, you can use this batch file from the “updating the HAL for multiprocessor support” message:

devcon sethwid @ROOT\ACPI_HAL\0000 := +acpiapic_mp !acpiapic_up
devcon update c:\windows\inf\hal.inf acpiapic_mp

Make sure you have devcon.exe and he above batchfile in the same directory.

Now I had a 2 core system, but wanted a 4 core system.

So I shut down the VM, bumped up the CPU count in the ESXi management interface to 4, then rebooted.
Device Manager showed 4 cores, but task manager only 2.

After a long search most of the results were forum postings.

A more official document is the Microsoft Windows XP Professional EULA. It indicates the maximum number of (apparently physical processors) is 2.
Similar for the Microsoft Windows XP Home EULA: it indicates a maximum of 1 processor.
There are similar documents for other versions and editions of Windows

Since VMware cannot simulate hyperthreaded cores or multi-core processors, you are stuck with a maximum of 2 virtual CPUs, each having one core.

Conclusion

• Non-sever versions of Windows only support 2 physical CPUs.
  There are not many places to find this, the Windows XP EULA section “Installation and use” hints this.
• Virtualization tools provide CPUs, not cores.
  So the maximum core count inside such non-server version of Windows is 2.
• In order for Windows XP to support multiple CPUs, you will need a

–jeroen

• Upgraded from ESX 3.5 to ESXi 4.1 (I needed this anyway because of Pass Through USB support)
• Upgraded the community edition appliance from Endian 2.2 to Endian 2.4 (which has more configuration options, and better ways for reporting and logging)

Then I went on solving the issue, which I suspected was a kind of routing problem.The steps below are specifically for the Endian FireWall Community Edition version 2.4 (I’ll call this Endian 2.4 from now on) running on VMware ESXi 4.1.
Endian 2.2 on ESX 3.5 behaved differently: for XP, I didn’t need to add a VPN traffic firewall rule, nor a default route.  For Windows 7, I couldn’t get it to work, and since I needed to upgrade both anyway, I did the upgrades first.

After an extensive search, the below two posts (follow the links to read more than just the quotes) got me into the right direction.

1. mrkroket (from somwehere down under) posted an OpenVPN  checklist as an answer on the efwsupport.com forum.
2. bucho posted on Connected client can access EFW but no other hosts telling about the VMware promiscuous mode at the same forum.

Thanks guys, you are great forum members!

These were the steps I had to perform on Endian 2.4 to get PING to hosts on the GREEN LAN working through the OpenVPN:

Endian 2.4 configuration changes

Add VPN traffic firewal rule that allows ANY traffic.
Steps:

1. Logon to the web interface of your Endian 2.4 box
2. Click on the “Firewall” link in the dark grey main menu bar
3. Click on the “VPN traffic” link in the left submenu bar
4. If the state button is disabled (it then looks like ), then click on the button until it is enabled (it then looks like )
5. Click on the link “Add a new VPN firewall route”
6. For logging purposes, you can check the “Log all accepted packets”
   (make sure you turn that off if your routing works!)
7. In my case (I wanted all OpenVPN users to be able to reach the green zone), I choose this configuration:
   

   #	Source	Destination	Service	Policy	Remark	Actions
   1	GREEN + OPENVPN	RED GREEN + OPENVPN ORANGE IPSEC Uplink main	<ANY>		Allow ANY for GREEN + OpenVPN to ANY

   Legend

   Enabled (click to disable)

   Disabled (click to enable)

   Edit

   Remove

8. In the big green area that appeared on top, press the “Apply’ button

Examining the firwall logs is easy:

1. Logon to the web interface of your Endian 2.4 box
2. Click on the “Logs” link in the dark grey main menu bar
3. Click on the “Firewall” link in the left submenu bar

Watch the incoming ping requests coming :-)

Some people also need the Endian OpenVPN server to push the GREEN LAN as a route.
I didn’t need to to that, but in case you need, these are the steps to follow:

1. Logon to the web interface of your Endian 2.4 box
2. Click on the “VPN” link in the dark grey main menu bar
3. Click on the “Advanced” link in the light grey sub menu bar
4. In the “Global push options” section, make sure that next to “Push these networks”
   - the “Enable” checkbox is checked
   - the textbox  contains a valid GREEN network and netmask using the CIDR notation (in my case it was “172.16.41.0/24″)
5. Press the “Save and restart” button in the  ”Global push options” section

ESXi 4.1 configuration change

Enable “Promiscuous Mode” for the vSwitch Port Group where the GREEN NIC of the Endian resides on.

1. In the ESXi configuration,
   - Select your ESXi server in the tree view on the left
   - Select the “Configuration” tab
   - Find the “Virtual Switch” where the GREEN NIC of your Endian connects to
   - Click on the “Properties” link for that Virtual Switch
   - Select the “Virtual Machine Port Group”
   - Click “Edit”
   - Go to the “Security” tab
   - Put a checkmark after the “Promiscuous Mode”, then set the value in the combobox to “Accept”
   - Press the “OK” button in the “Virtual Machine Port Group” dialog
   - Press the “Close” button in the “Virtual Switch” dialog

Why enable Promiscuous Mode?
A router or bridge does more with traffic than a normal NIC.
So the router needs to see more packets.
Promiscuous mode enables that.

After knowing all this, it was easy to find someone else who did similar things:

User sheastr used ESXi to install untangle and blogged about it and posted a link to it in the untangle forum.

Note there seem to have been people having difficulties getting promiscuous mode to work on ESXi 4.0; see the above “easy to find” link for some examples.
Here it works fine in ESXi 4.1.

VMware background information

• VMware KB: How promiscuous mode works at the virtual switch and portgroup levels.
  
• VMware KB: Configuring promiscuous mode on a virtual switch or portgroup.

–jeroen

via: ENDIAN Firewall – Connected client can access EFW but no other hosts.

I did the upgrade using Using the vMA virtual appliance, the statements are these:

After bringing the ESXi 4.0 box into maintenance mode, I performed these steps on an SSH connection to the vMA virtual appliance:

[vi-admin@localhost ~]$ cd /tmp
[vi-admin@localhost tmp]$ wget -m -np ftp://192.168.71.190/esxi41/upgrade-from-ESXi4.0-to-4.1.0-0.0.260247-release.zip
[vi-admin@localhost tmp]$ vihostupdate -url https://192.168.71.193/sdk/webservice -i -bundle 192.168.71.190/esxi41/upgrade-from-ESXi4.0-to-4.1.0-0.0.260247-release.zip
Enter username: root
Enter password:
Please wait patch installation is in progress ...
The update completed successfully, but the system needs to be rebooted for the changes to be effective.
[vi-admin@localhost tmp]$ rm -rf 192.168.71.190/

This literally took less than 5 minutes to complete, including rebooting the ESXi box.

The whole process of taking backups took about a day :-)

When you read this, that update has been about 2 months ago, and it has been running fine ever since.

–jeroen

via: Jargon Technology » How to Perform an ESXi 4.0 to 4.1 Upgrade.

In ESX / ESXi 3 and 3.5, it took a while for people to recognize the ‘unsupported’ trick and enable SSH.
In ESXi 4.0, /sbin/services.sh was fixed, so SSH was easier to enable (note: only delete the # in front of the first ssh).
Since ESXi version 4.1, SSH is called “Remote Tech Support (SSH)”, and it very easy to enable from the console.
Thomas Maurer described how easy it is to activate SSH in ESXi 4.1. He provides clear screen shots, whereas the VMware knowledge base article just lists the textual steps.

But contrary to ESX/ESXi 3.5 and lower, and *nix habits, enabling SSH on ESXi 4.x will enable this for the root user.
This has to do with the switch between ESX/ESXi 3.5 and 4.0 from to the dropbear ssh daemon (in the /sbin/dropbearmulti binary).
Dropbear is a very lightweight implementation of the SSH 2 protocol; ideal for ESXi which – as a hypervisor – needs to have a really low footprint.

In addition to the dropbear change, SSH is disabled for non-root users (which has nothing to do with dropbear, see below).

This post is about how to fix not only the SSH (as above) but also how to allow specific users to use SSH.The fact that SSH is disabled for non-root users is very confusing, especially because there is no difference in what you see upon a login through a bad username/password combination, or a user that is not allowed SSH access.
You will see this in under both circumstances:

C:\Users\username>ssh -l username 192.168.71.158
username@192.168.71.158's password:
Permission denied, please try again.

Fixing SSH access for the user is a two step process.

Both steps involve editing the /etc/passwd file.
So you will need to SSH to your ESXi 4.x box as root user to fix this.

This is what the /etc/passwd file looks like (note I made a copy into /etc/passw.original before doing the edits; always have a backup ):

~ # cat /etc/passwd.original
root:x:0:0:Administrator:/:/bin/ash
nobody:x:99:99:Nobody:/:/sbin/nologin
nfsnobody:x:65534:65534:Anonymous NFS User:/:/sbin/nologin
dcui:x:100:100:DCUI User:/:/sbin/nologin
daemon:x:2:2:daemon:/:/sbin/nologin
vimuser:x:12:20:vimuser:/sbin:/sbin/nologin
username:x:501:0:Linux User,,,:/home/username:/sbin/nologin

The first step is to change the default shell for username from /sbin/nologin (ESXi 4.0 has /bin/false) /into /bin/ash (the same shell that user root uses).
Since ESXi is *nix based, but has very few tools installed, you will have to use vi with that, so a list if VI keyboard shortcuts come in handy.
When you have done that, you might think you are ready.
You are not.
This is what you will see:

C:\Users\username>ssh -l username 192.168.71.158
username@192.168.71.158's password:
You have activated Tech Support Mode.
The time and date of this activation have been sent to the system logs.

VMware offers supported, powerful system administration tools.  Please
see www.vmware.com/go/sysadmintools for details.

Tech Support Mode may be disabled by an administrative user.
Please consult the ESXi Configuration Guide for additional
important information.

Connection to 192.168.71.158 closed.

In other words: SSH login works, but the connection is immediately closed.
I have seen this behaviour on other *nix machines as well, so I recognized that the login directory for the user was wrong.

Indeed it is: when VMware ESXi 4.x adds a user, it adds the home directory in the /etc/passwd file.
But it does not create that home directory.
There are basically 2 solutions for this:

1. create the /home/username directory
2. replace the /home/username directory in /etc/passwd with the / root directory

I did the last step, see this diff:

/etc # diff passwd passwd.original
--- passwd      Wed Aug  4 19:34:14 2010
+++ passwd.original     Wed Aug  4 19:27:53 2010
@@ -4,4 +4,4 @@
 dcui:x:100:100:DCUI User:/:/sbin/nologin
 daemon:x:2:2:daemon:/:/sbin/nologin
 vimuser:x:12:20:vimuser:/sbin:/sbin/nologin
-username:x:501:0:Linux User,,,:/:/bin/ash
+username:x:501:0:Linux User,,,:/home/username:/sbin/nologin

And now the login works:

C:\Users\username>ssh -l username 192.168.71.158
username@192.168.71.158's password:
You have activated Tech Support Mode.
The time and date of this activation have been sent to the system logs.

VMware offers supported, powerful system administration tools.  Please
see www.vmware.com/go/sysadmintools for details.

Tech Support Mode may be disabled by an administrative user.
Please consult the ESXi Configuration Guide for additional
important information.

~ $ su
Password:
~ # pwd
/

Now that I you have enabled SSH for a non-root account, you can start disabling it for the root account.
Knowing that the SSH server is in fact dropbear makes that easy: just look up the dropbear man page.

Here you see that adding the -w option to the dropbear commandline will “Disallow root logins”.
The solution is the same for all ESXi 4.x installations:

1. login to the console or through SSH
2. change this /etc/inetd.conf line by adding -w after the -i

From:

ssh     stream  tcp     nowait  root    /sbin/dropbearmulti     dropbear  ++min=0,swap,group=shell -i -K60

Into:

ssh     stream  tcp     nowait  root    /sbin/dropbearmulti     dropbear  ++min=0,swap,group=shell -i -w -K60

Finally you will need to restart the inetd service by calling services.sh restart

Now that you can only login as non-root using SSH, you still need a means to become root.
Here you can use the su command.

I hope this helps a few people getting this to work sooner than I did.

Edit:

Daniel Barnes posted the comment below, but since source code font in comments is to be really big, and I did not yet find out how to successfully change the WordPress CSS to alliviate it.
So here is the comment in full:

It is possible to make it permanent. I wrote a script which allows members of a “localadmin” group to remotely login via ssh. Create the group via vSphere and add users to it as desired.

In the “Local Technical Support Mode” shell, execute:

mkdir -p /tmp/oem/etc/vmware/init/init.d
vi /tmp/oem/etc/vmware/init/init.d/120.config-inetd

Then enter the code below:

#!/bin/sh

# Enable SSH
sed '/tcp[^6]/s/^#ssh/ssh/' -i /etc/inetd.conf

# Disable root login
sed '/ssh/s/-i -K60/-i -w -K60/' -i /etc/inetd.conf

# Grant access to localadmin group
sed '/localadmin/d;1s/$/\n+:localadmin:ALL/' -i /etc/security/access.conf

# Configure shell for localadmin users
for u in $(grep ^localadmin /etc/group|cut -d: -f4|sed 's/,/\n/g'|grep -v root); do
sed '/^'$u':/s:/sbin/nologin:/bin/ash:' -i /etc/passwd

# Create home directories for localadmin users
home=$(grep $u /etc/passwd|cut -d: -f6)
mkdir -p $home/.ssh
chown -R $u:users $home
chmod 700 $home/.ssh
done

# Configure crontab to restore settings
CRONTAB=/var/spool/cron/crontabs/root
mkdir -p $(dirname $CRONTAB)
sed /120.config-inetd/d -i $CRONTAB
echo '* * * * * sh /etc/vmware/init/init.d/120.config-inetd' >> $CRONTAB

# Remove syslog clutter
sed '/120.config-inetd/d' -i /var/log/messages

Do this step if you already have an oem.tgz:

tar xzf /bootbank/oem.tgz -C /tmp/oem

Create a new oem.tgz:

tar czf /bootbank/oem.tgz etc -C /tmp/oem

–jeroen

1. Have a test scenario for all your VMs so you can prove they work.
   (for instance, when using an Endian Firewall appliance VM (their community edition is free), your scenario could include that people can remotely connect as they did before, and the proxy server still works).
2. Note the “startup order” of your VMs
3. Note the full datastore path GUID(s) of your source ESX machine
   (GUID = number formatted like “########-########-####-############”)
4. Note the full datastore path  GUID(s) of your target ESXi machine
5. License your target machine
   (on second thought: you might want to do all of this in your 60-day evaluation period, as the evaluation license can do more than some of the other licenses)
6. Create the same network config (virtual switches, etc) on your target box as your source box (make sure you name them exactly the same way)
7. Create the same pools (high, low, etc) on your target as your source
8. Shutdown all your VMs
9. (you might get by this and suspend your VMs in stead of shutting them down, but this is a high risk, and will only work if the target hardware and source hardware matches).
10. Transfer all your datastore files from your source to your target, and keep the data structure.
    (having a gigabit connection between source and target is a real benefit here;
    observed speeds:
    - gigabit: 30 – 50 megabyte/s – limit is HDD speed
    - 100mbit: 5-13 megabyte/s – limit is LAN speed)
    (Use Veeam Backup and FastSCP 3.0.3 or better, or Veeam Backup and Replication 4.1.2 or better to do the transfer)
11. Copy all your .vmx files to a place where you can edit them
12. In each .VMX file, perform these actions:
    1. Remove all lines containing ‘sched.swap.derivedName’ (if needed, ESXi 4.1 will regenerate those values)
    2. Replace the datastore path GUID numbers of your source by the equivalent in your target
    3. Copy the .VMX file over the one in your target (using Veeam or the data store browser).
13. Check for each VM if the connected networks are working OK (they should be the same as your original ESX box)
14. Test all the VMs
    For each VM, mark it as “I have moved it”  when a
15. If everything works OK, fix the “startup order” of the VMs
16. Perform a test reboot of your ESXi server

Notes:

1. Replacing the GUID(s) for me resulted in replacing this:

   /vmfs/volumes/48e5fa96-2aff1e07-3623-001517777c91/
   

   with this:

/vmfs/volumes/4c595d79-4bba1b16-c2d7-001f29011276/"

2. If none of your .vmx files contain spaces, you can find the ones containing “sched.swap.derivedName” using this command-line on your ESXi console (or ssh connection):

   grep -l "sched.swap.derivedName" `find /vmfs/volumes | grep "vmx$"`

3. To find the GUID of your datastore(s), perform this command:

   ls -ld `find /vmfs/volumes | grep datastore`

   which will reveal entries like this:

   lrwxr-xr-x    1 root     root                 35 Aug 10 09:24 /vmfs/volumes/datastore1 -> 4c595d79-4bba1b16-c2d7-001f29011276
   

   As an alternative, you can use

   ls -l /vmfs/volumes/

   Then look for directories with:

   • names formatted like “########-########-####-############”
   • that datastores named like “datastore#” points to,
   • with dates other than “Jan 1 1970″

   like the “4c595d79-4bba1b16-c2d7-001f29011276″ sample from the directory listing below.

/vmfs # ls -l /vmfs/volumes/
drwxr-xr-x    1 root     root                  8 Jan  1  1970 3c3693e8-f77a642a-1910-5c6bdcb26d3a
drwxr-xr-x    1 root     root                  8 Jan  1  1970 4c595d77-759e73a4-1c06-001f29011276
drwxr-xr-t    1 root     root               1960 Aug  6 21:10 4c595d79-4bba1b16-c2d7-001f29011276
lrwxr-xr-x    1 root     root                 35 Aug 10 08:47 Hypervisor1 -> b7322b70-626659ce-c9cb-256d7ec6a809
lrwxr-xr-x    1 root     root                 35 Aug 10 08:47 Hypervisor2 -> d01e7671-215df396-e8f8-e0f990b59662
lrwxr-xr-x    1 root     root                 35 Aug 10 08:47 Hypervisor3 -> 3c3693e8-f77a642a-1910-5c6bdcb26d3a
drwxr-xr-x    1 root     root                  8 Jan  1  1970 b7322b70-626659ce-c9cb-256d7ec6a809
drwxr-xr-x    1 root     root                  8 Jan  1  1970 d01e7671-215df396-e8f8-e0f990b59662
lrwxr-xr-x    1 root     root                 35 Aug 10 08:47 datastore1 -> 4c595d79-4bba1b16-c2d7-001f29011276

–jeroen

The VMware KB has more information on this: you will need at least a vSphere Essentials license for your ESXi box to use it..

If you have a free ESXi license, you will often get messages like these:

SOAP Fault:

Fault string: fault.RestrictedVersion.summary
Fault detail: RestrictedVersionFault

You will find this when doing backup/restore purposes, and re-regisestering .vmx files on the same machine. You can work around this by browsing your datastore (Browse datastore, find .vmx, right-click and “Add to Inventory”).

mstfysn1981 worked around this for remote shutdown by using ssh.

Some other things can be solved by using the esxicontrol.pl script.

But depending in your budget you might want to buy a non-free liceense.

VMware has a comparison of features for each license type online.
It doesn’t contain prices (so far for transparency),  but the shop contains the cheapest non-free license; as the time of writing, they are these:

1. VMware vSphere Essentials Kit (of you have 1 ESXi box; current prices is USD 495)
2. VMware vSphere Essentials Kit for 3 hosts (of you have 2 or 3 ESXi boxes; current price is USD 611)

You can always upgrade a cheaper vSphere license to a more expensive license.

–jeroen

via: VMware vSphere Web Services SDK Documentation.

[Window Title]
Virtual Machine Message
[Main Instruction]
Virtual Machine Message
msg.cpuid.noLongmodeQuestionFmt: This virtual machine is configured for 64-bit guest
operating systems. However, 64-bit operation is not possible.
This host is VT-capable, but VT is disabled.
VT might be disabled if it has been disabled in the BIOS settings or the host has not been
power-cycled since changing this setting.
(1) Verify that the BIOS settings enable VT and disable ‘trusted execution.’
(2) Power-cycle the host if either of these BIOS settings have been changed.
(3) Power-cycle the host if you have not done so since installing VMware ESX.
(4) Update the hosts’s BIOS to the latest version.
For more detailed information, see http://vmware.com/info?id=152
Continue without 64-bit support?
[Yes] [No] [OK]

Following the link, you will see the page on the right.
In large friendly letters, it shows (even when you are logged on in your VMware account):

You are not authorized to access this Document.

A few points:

1. Why can’t it warn me upon installation?
   It helps x86 as well as x64, so an early warning would be very nice.
   Now you have to power down the machine (which might already be running a few x86 VMs), change the BIOS settings, then reboot.
   Inconvenient when the machine is not near (like: in a data center)…
2. Why the error message in stead of more details?
   People not knowing about VT certainly need some extra explanation.

In the mean time, I found out that one of my two HP XW6600 boxes had different BIOS settings than the other.
That was no problem for running Windows 7 Ultimate x64 on it, but ESXi requires the VT to be enabled.

Note the HP XW6600 have been on the market long enough to use as a white box.
It is not on the unofficual ESXi whitebox list yet, but I’ve been running it a while with ESXi 4 now, and just installed ESXi 4.1 on it, so I’ll blog about it in more detail later.

–jeroen

via VMware Communities: vCenter 4.1 in ESXi4.1 in Fusion 3.1? ….

I was partially wrong in that Veam Backup FastSCP 3.0.2.270 did not work: that the alternative is Veeam Backup and Replication 4.1.2.
Well not completely: Veeam Backup and Replication 4.1.2 works, but a day after they released that 4.1.2 version, they also released Veeam Backup and FastSCP 3.0.3, which works too.
And of course they released it about half a day after I wrote the above post :-)

Since the Veeam mass mail to their existing FastSCP clients has not been sent, the only place to find that version 3.0.3 exists is on their forums.

Version numbers and dates

Version 3.0.2

Version 3.0.3

Fixed

For ESXi 4.1 users, the most important thing solved in 3.0.3. is this error message when copying subdirectories to an ESXi 4.1 machine:

—————————
Veeam Backup and FastSCP
—————————
API version on the server does not allow CreateDirectory operation
—————————
OK
—————————

So now you have two choices: the free Veeam Backup and FastSCP 3.0.3, or the paid Veeam Backup and Replication 4.1.2.
The last one allows you to schedule backups, but only if your ESXi box is a non-free license.

–jeroen

Create User:  User name or password has an invalid format

Until now, only a few russian pages described the cause:
Without console login (or SSH  - see my blog tomorrow), you cannot see the obvious reason for this message:

Your password does not adhere to the ESXi 4.x password policy, which is more strict than the ESX/ESXi 3.x policy.

vm-help.com has a nice page describing the ESXi 4.x password policy, and how to alter it.

–jeroen

—————————
Veeam Backup and FastSCP
—————————
API version on the server does not allow CreateDirectory operation
—————————
OK
—————————

The free FastSCP works on a file by file base, but that won’t cut it.
Hoping the licensed product would work better, I registered for a trial of Veeam Backup and Replication (it is version 4.x in stead of FastSCP which is still 3.x).

The registration process went swift, but I was just a tad bit too early trying to run it against VMware ESXi 4.x:
When I downloaded the Veeam Backup and Replication yesterday, I got 4.1.1.
Just a few hours later, 4.1.2 was released and I obviously missed that.

That miss took me a few extra hours extra to get everything working, because I ran in to two issues:

1. On my first test-box, version Veeam Backup and Replication 4.1 did not install: it rolled back almost at the end.
   That might have to do with the fact that FastSCP used to be on that box. I uninstalled it, but found out later that the uninstall removed only parts (including the entry in the control panel), but not everything.
2. On my second test-box, Veeam Backup and Replication 4.1 did install, and could successfully connect to my ESX 3.5 and ESXi 4.0 machines. But not to my ESXi 4.1 machine. I got this error:

—————————
Veeam Backup and FastSCP
—————————
Failed to login to “192.168.71.158″ by SOAP, port 443, user “root”, proxy srv: port:0

Input string was not in a correct format.
—————————
OK
—————————

I googled around and nothing on the internet would help.
Not even modifying the apiVersion element in /usr/lib/vmware/hostd/docroot/client/clients.xml from v4.1 to 4.1 (as suggested by this translated Russian message).

All this fiddling required me to do some SSH (and since SSH by default on *nix is not available for the root user, also add non-root users).
Getting that right took me a while as well, so expect a few more VMware ESXi 4.x related blog posts soon.

Installing Veeam Backup and Replication 4.1.2 (build 4.1.2.125) solves the error messaage completely.

–jeroen (now going to sleep because he drained a couple of hours on this problem).

via: Community Forums • View topic – [LATEST RELEASE] Version 4.1.2 (Aug 4, 2010).

At that time I decided to ignore it. It didn’t interfere with the normal functioning of the ESXs and since I never got again to the console of the ESX, I just fired up the VM in Workstation and then started to work from the vSphere Client, for a long time the error fall into the oblivion.

This week I decided to install a new ESX4 and couple of ESXi4 VMs in my home lab and the error appeared again and this time the geek inside me couldn’t resist and after doing some research I found this VMware Knowledge Base article which also pointed to a Dell document, both of them said that the error could be ignored because there is no real loss of service, something that I already knew x-). I finally found the solution in a VMTN post.

From the vSphere Client go to Configuration -> Software -> Adavanced Settings and in the VMkernel area disable the VMkernel.Boot.userNUMAInfo setting.

After that reboot your ESX and will see that the error has disappear.

I also noticed that the error is present on the virtualized ESXi but to see it from the ESXi console press Alt-F11 and you will get to a screen almost identical as the one from the first screenshot.

Juanma.

This happens at least with VMware Converter 4.01 and converting x64 VM’s like “Windows 7″ and “Windows Server 2008 R2″ from ESXi 4 U1.
Others found out it also happens with some Linux VMs, I have not tried those yet.

A the VMware communitie, user wildblue posted a workaround:

Similar problem here – Windows 7 VM, converter gives the “Unable to obtain hardware information for the selected machine”

Log shows (I’m assuming this is the important part)

error ‘ManagedMachineDataConnectionLogger’] Cannot query source HW info: vmodl.fault.SystemError

Export Wizard through VI Client gives ‘Unable to determine Guest Operating System’

Changing the VM’s settings and making the Operating System something other than Win 7 seems to work. Export to OVF works too. Guess those are your work arounds until the next verion of converter.

So the trick is these steps:

1. Write down the Guest Operating System type
   (You can perform step 1, 2 and 4 by pressing “Edit Settings” in the VM, in the dialog then go to the “Options” tab. )
2. Change your VM configuration Guest Operating System type to a similar processor type (keep 64-bit or 32-bit) for a lower release of the OS (Windows 7 -> Vista -> XP, etc)
3. Convert your VM; if it fails, go back to step 2
4. Restore the VM configuration Guest Operating System type to the original saved in step 1

Piece of cake when you know it :-)

–jeroen

via VMware Communities: Unable to obtain hardware information ….

Step One: Create a volume.

Lets suppose we already have a configured storage appliance, I showed how to create a cluster in my previous post so I will not repeat that part here. Open the Centralized Management Console and go to the Management group -> Cluster ->Volumes and Snapshots.

Click on Tasks and choose New Volume.

Enter the volume name, a small description and the size. The volume can also be assigned to any server already connected to the cluster, as we don’t have any server assigned this option can be ignored, for now.

In the Advanced tab the volume can be assigned to an existing cluster and the RAID level, the volume type and the provisioning type can be set.

When everything is configured click OK and the volume will be created. After the creation process, the new volume will be showed up in the CMC.

At this point we have a new volume with some RAID protection level, none in this particular case since it’s a single node cluster. Next step is to assign the volume to a server.

Step Two: ESXi iSCSI configuration.

Connect to the chosen ESXi4 Server through vSphere Client and from the Configuration tab in the right pane go to the Networking area and click the Add Networking link

In the Add Networking Wizard select VMkernel as Connection Type.

Create a new virtual switch.

Enter the Port Group Properties, in my case the label as no other properties where relevant for me.

Set the IP settings, go to Summary screen and click Finish.

The newly created virtual switch will appear in the Networking area.

With the new virtual switch created go to Storage Adapters there you will see an iSCSI software adapter.

Click on properties and on the General tab click the Configure button and check the Enabled status box.

Once iSCSI is enabled its properties window will be populated.

Click close, the server will ask for rescan of the adapter but at this point it is not necessary so it can be skipped.

Step Three:  Add the volume to the ESXi server.

Now, that we have our volume created and the iSCSI adapter of our ESXi server activated, the next logical step is to add the storage to server.

On the HP Lefthand CMC go to the servers area add a new server.

Add a name for the server, a small description, check the Allow access via iSCSI box and select the authentication. In the example I choose CHAP not required. With this option you only have to enter the Initiator Node Name, you can grab it from the details of the ESXi iSCSI adapter.

To finish the process click OK and you will see the newly added server. Go to the tab Volume and Snapshots tab on the server configuration and from the Tasks menu assign a volume to the server.

Select the volume created at the beginning,

Now go back to  the vSphere client and launch again the properties of the iSCSI adapter. On the Dynamic Discovery tab add the virtual IP address of the VSA cluster.

Click Close and the server will ask again to rescan the adapter, now say yes and after the rescanning process the iSCSI LUN will show up.

Now in the ESXi a new Datastore can be created with the newly configured storage. Of course the same LUN can also be used to provide shared storage for more ESXi servers and used for VMotion, HA or any other interesting VMware vSphere features. May be in another post ;-)

Juanma.

http://www.petri.co.il/vmware-esxi4-console-secret-commands.htm?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Petri+%28Petri+IT+Knowledgebase%29

How to access the local console on ESXi 4.0

http://www.help4it.co.uk/home-mainmenu-1/inside-track/How-to-access-the-local-console-on-ESXi-4.0.html

1. Login to the server via the Console.
2. Type: Alt + F1
3. Type: unsupported
4. Type: (your root password)
5. Edit /etc/inetd.conf: vi /etc/inetd.conf
6. Remove # sign in front of ssh, by moving down to the SSH line and type 1x, and then :wq
7. Run: /sbin/services.sh restart

You should now be able to login via SSH as below using my favorite Putty.

Si bien la instalación es muy sencilla y no presenta ninguna dificultad, en este tutorial vamos a ver cómo realizarla paso a paso con el único fin de que no temas instalarlo. Además se incluyen los pasos para instalar el cliente y añadir el código de licencia.

Pero mejor nos dejamos de palabrería y vamos al lío ¿no?

Los pasos para instalar VMware ESXi 4 son los siguientes:

1. Primero verificamos en la guía de compatibilidad de hardware de VMware ESXi (HCL) que el hardware de nuestro servidor está soportado por VMware ESXi 4. Si bien es un paso importante, no hay que olvidar que es posible instalar VMware ESXi 4 en más servidores de los que se indican en esta guía. Hasta se puede instalar en VirtualBox. Eso sí, necesitaremos inevitablemente un procesador de 64 bits y 2 GB de RAM como mínimo.
2. Descargamos la imagen ISO de VMware ESXi Hypervisor desde aquí y la grabamos en un CD. Para hacer esto primero tendremos que estar registrados en la web de VMware.
3. Arrancamos el servidor en el que vayamos a instalar el ESXi con el CD grabado en el paso anterior y nos aparecerá el menú de arranque:
   

   Menú de arranque de VMware ESXi 4

4. De forma automática comienza el arranque del instalador.
5. A continuación se nos pregunta por la operación que queremos realizar: cancelar (ESC), reparar (R) o instalar (Enter). Pulsando la tecla Introseleccionamos instalar.
   

   Pulsamos Intro para instalar el ESXi 4

6. El siguiente paso consiste en aceptar el EULA (End User License Agreement) después de leerlo detenidamente. Para aceptarlo pulsamos la tecla F11.
   

   Presionamos la tecla F11 para aceptar el EULA

7. Después tenemos que seleccionar el disco duro donde se instalará el sistema. Como en mi caso sólo dispongo de uno, no tengo que elegir. Así que pulsamos Intropara continuar.
   

   Seleccionamos el disco duro y pulsamos Intro

8. Como en el disco duro que voy a utilizar tenía instalado otro sistema, me pide confirmación porque se eliminará todo el contenido del disco. Si tu disco duro no tiene nada instalado, no te aparecerá este mensaje. Pulsamos Intropara continuar.
   

   Confirmamos la elección del disco duro presionando Intro

9. Y ahora confirmamos que vamos a instalar VMware ESXi 4 en el disco que habíamos seleccionado. Lo hacemos pulsando F11.
   

   Confirmamos la instalación de ESXi 4 pulsando F11

10. La instalación se hace en muy poco tiempo y antes de darnos cuenta nos encontraremos con el mensaje de que se ha instalado correctamente y tenemos que reiniciar. Extraemos el CD y pulsamos Intropara reiniciar.
    

    Pulsamos Intro para reiniciar

11. Al reiniciar el sistema nos encontramos con la pantalla de inicio de VMware ESXi y, antes de empezar a trabajar con él, deberemos configurarlo pulsando la tecla F2.
    

    Pulsamos la tecla F2 para configurar el servidor

12. La pantalla de configuración llama la atención porque es bastante simple y tiene pocas opciones.
    Lo primero que debemos hacer es establecer una contraseña para el usuario root que, por defecto, no la tiene. Para esto nos situamos sobre Configure Root Password y pulsamos Intro.
    

    Configuramos la contraseña de root

13. Escribimos la nueva contraseña para el usuario root y pulsamos Intro.
    

    Escribimos la contraseña de root

14. Aparecemos en la pantalla de configuración de nuevo y ahora podemos pasar a cambiar la configuración de red. En principio, como en mi red hay un servidor DHCP, el ESXi tiene asignada ya una IP. Sin embargo, es conveniente que la IP del VMware ESXi sea fija (como debe ocurrir con cualquier servidor).
    Por lo tanto, nos situamos sobre Configure Management Network y pulsamos Intro.
    

    Accedemos a Configure Management Network

15. En la siguiente pantalla bajamos hasta la opción IP Configuration y pulsamos Intro.
    

    Bajamos hasta IP Configuration

16. A continuación seleccionamos Set static IP address and network configuration con la barra espaciadora y escribimos la dirección IP, la máscara y la puerta de enlace. Para terminar pulsamos Intro.
    

    Establecemos la nueva configuración

    Ya tenemos configurado nuestro VMware ESXi, apagamos el monitor de este equipo y nos situamos en cualquier otro equipo de la red con Windows (lamentablemente todavía no existe el cliente de vSphere para Linux).

17. Abrimos un navegador en el equipo con Windows y escribimos la dirección IP que hemos configurado en el servidor VMware ESXi. Con Firefox nos encontraremos con el siguiente fallo de seguridad y tendremos que hacer clic en O puede añadir una excepción…
    

    Fallo de seguridad al acceder a la IP del ESXi 4

18. Ahora hacemos clic en el botón Añadir excepción…
    

    Añadimos una excepción de seguridad

19. Por último, hacemos clic sobre el botón Obtener certificado y, a continuación, sobre Confirmar excepción de seguridad.
    

    Obtenemos el certificado y confirmamos la excepción

20. Así llegamos a la página de bienvenida del servidor VMware ESXi 4. Desde esta página vamos a obtener el programa que nos va a permitir la administración completa del servidor de forma remota. Hacemos clic en Download vSphere Client.
    

    Página de bienvenida del ESXi 4

21. El siguiente paso consiste en guardar el archivo.
    

    Guardamos el archivo

    Y lo ejecutamos una vez descargado.

22. Para instalar VMware vSphere Client sólo tenemos que seleccionar el idioma. Como no está disponible el español, he elegido inglés.
    

    Elegimos el idioma de la instalación

    Después bastará con ir haciendo clic sobre Next.

23. Una vez instalado ejecutamos VMware vSphere Client y nos aparece la ventana para establecer la conexión y en la que deberemos introducir la IP del servidor ESXi, el nombre de usuario y la contraseña. En principio, sólo existe el usuario root con la contraseña que establecimos anteriormente.
    

    Introducimos los datos de conexión en el vSphere Client

24. Al intentar conectar nos aparece un aviso de seguridad por culpa, otra vez, del certificado SSL. Para salir del paso hacemos clic sobre el botón Ignore. Si queremos solucionar el problema, deberemos hacer clic en View Certificate e instalar el certificado.
    

    Ignoramos la advertencia de seguridad

25. Lo primero que veremos al entrar al vSphere Client será un mensaje recordándonos el número de días del periodo de prueba que nos quedan. Sí, VMware ESXi 4 es gratis pero necesita de un número de licencia.
    

    Número de días de prueba que nos quedan

26. Por fin, ya nos encontramos con el VMware vSphere Client que nos va a permitir administrar nuestro servidor de forma muy sencilla. Pero antes de que nos pongamos a trastear con el servidor vamos a introducir el código de licencia y así nos desperocupamos el período de prueba. Con este fin en mente hacemos clic sobre Inventory.
    

    Hacemos clic en Inventory

27. En el panel de la izquierda de Inventory veremos la IP de nuestro servidor y a la derecha un conjunto bastante amplio de pestañas. Hacemos clic sobre la pestaña Configuration.
    

    Hacemos clic sobre la pestaña Configuration

28. Después hacemos clic sobre Licensed Features en la sección de Software y, a continuación, hacemos clic en el Edit…(arriba a la derecha) que  está a la altura de License Source.
    

    Hacemos clic en Licensed Features

29. Nos aparecerá la siguiente ventana en la que seleccionamos Assign a new license key to this host y hacemos clic sobre Enter Key…
    

    Hacemos clic sobre Enter Key

30. Escribimos el código de licencia que nos ha proporcionado VMware y hacemos clic en OK.
    

    Escribimos el código de licencia

31. Vemos características de la licencia introducida y hacemos clic sobre OK.
    

    Vemos las características de la licencia

32. Y podemos ver en la imagen como se ha añadido correctamente la licencia.
    

    Comprobamos que hemos introducido la licencia correctamente

Si has seguido estos pasos, ya puedes empezar a crear máquinas virtuales a través del VMware vSphere Client o importar máquinas que ya tuvieses creadas o virtualizar máquinas físicas con el VMware vCenter Converter Standalone 4.0.

¡A disfrutar!

También te puede interesar:

• VMware ESXi 4 en VirtualBox paso a paso
• Arrancar automáticamente máquinas virtuales en ESXi
• ¿Qué es la virtualización?
• Instalar Citrix XenServer 5.0
• Instalar VMware ESXi 3.5 Hypervisor