You get an OVF package with a ready to use WAS profile running on Linux. The OVF package can be deployed on VMWare ESX/ESXi and IBM’s cludeburst appliance.
Websphere also say that they carried out WAS best-practice tuning for the OS. Not sure how mattering this tuning is considering the generic nature of WAS (different application=different tuning), and the generic drivers that a VM uses.

Joys of installation

I wonder how enterprise IT administrators would accept an OS different from what they usually roll with.

important to mention that similar zero-install pre-configured WAS environment are available on the IBM test cloud (in Beta).

The real important message made here by IBM is that the WAS hypervisor edition is only a first bird. Although naked manual WAS installation is not a biggy, IBM products running on WAS are. As the OVF standard matures and virtualization becomes the default production hosting environment, we will be seeing complex WAS based products (say Portal, and Process Server) shipped as ultra consumable OVF packages. Even a complete topology consisting of many servers can be delivered as a single OVF package.
This delivery mode is quite similar to VMWare’s software appliances, only applicable to more than one Hypervisor when packaged as OVF (theoretically).

Bad news to professional services people and install manager software developers.

The SIP protocol is not NAT oblivious. To traverse NAT our application has to replace the DNS in the SIP message contact header to the external FQDN that the message receiver will be sending responses to (A NAT with static routing configured).
Therefore I needed to test our software in a NAT topology.

In the past, when we used VMWare player/workstation, it had a build-in NAT network. But, unfortunately, the ESX hypervisor does not provide a NATed network option.
Seeking alternatives at VMWare’s appliance marketplace, I found and downloaded the Vyatta’s community edition (VC5) router appliance (also downladble from sourceforge), and comes under the GPL license.
After 3-4 hours – guided by the official quick start guide -  I had a working NAT configuration in the ESX. Hurray!
Overall, not a hard nut to crack , though I wish VMWare will wise up and just add an build-in NAT option to vSphere.

Left to do:
Obtain some static IPs, so the config won’t break each time the vm reboots and the DHCP lease expires.
Tip #1:
If you want want to access your NATed VM by RDP/VNC, without setting up extra NAT routing rules, consider adding the VM an additional un-NATed NIC, but when doing so, make sure that the OS routing tables are set to route through the NIC that is NATed.
Tip #2:
This short vyatta user installation report also helped me a bit.

Here’s the complete configuration script I ended up feeding to the appliance console (network topology is similar to the one presented in the Vyatta’s getting stated guide):
Where:
1.2.3.4 is your department’s DNS server
192.168.1.199 is the VMs NATed private IP address (provided by the DHCP).
The script contains a NAT forward rule for VNC (port 5900)

configure
set system host-name vyatta-nat
set interfaces ethernet eth0 address dhcp
set service ssh
set service https
commit;
save;
# restart the appliance to switch from console remote desktop to SSH:

#login with user and password
configure
show interfaces

set interfaces ethernet eth1 address 192.168.1.254/24

commit;

delete service dhcp-server
set service dhcp-server shared-network-name ETH1_POOL subnet 192.168.1.0/24 start 192.168.1.100 stop 192.168.1.199
set service dhcp-server shared-network-name ETH1_POOL subnet 192.168.1.0/24 default-router 192.168.1.254
set service dhcp-server shared-network-name ETH1_POOL subnet 192.168.1.0/24 dns-server 1.2.3.4
commit;
show service dhcp-server

set service nat rule 1 source address 192.168.1.0/24
set service nat rule 1 outbound-interface eth0
set service nat rule 1 type masquerade
commit;
show service nat
save;
exit
show nat rules
configure
set service nat rule 20 type destination
set service nat rule 20 inbound-interface eth0
# use a negative fake address to so that all incoming communication will be nated
#set service nat rule 20 destination address !192.168.50.0
#Forward traffic to address 192.168.1.199
set service nat rule 20 inside-address address 192.168.1.199
set service nat rule 20 protocol tcp
set service nat rule 20 destination port 5900
commit;
save;
exit

esx

Our VMWare ESX server does us a great job.
Running on an IBM X3650 HW, with 24GB RAM and 2×4 cores, it can simultaneously run up to 25 virtual machines, each VM is configured with around ~1.5 GB of RAM.

After reaching  the 25 running VMs mark, we started noticing increasing sluggishness when additional VMs were turned on.

Of course, we did the trivial stuff of making sure that all screen savers are disabled, antivirus agents are not correlated to run at the same point in time, and making sure that all of the VMs are running the latest VMWare tools agent.
It was time to dig in deeper to find out where is the bottleneck we came across.

Someone told me that the stats that the reliability of the performance indicators that the graphic VI console shows is questionable and it’s recommended using the terminal utilities.So, I SHHed to the service console VM and ran the top utility. Immediately, I understood that what I’m actually doing is surveying the service console VM processes, rather than the overall ESX hypervisor activity. A quick dig up made me realize that the hypervisor is visible through the esxtop command, which is also executed from within the service console VM.

even for those of you that knows your way through the output of top and linux’s sysstat package, the data shown by esxtop is rather cryptic.
This great esxtop tutorial did me a great service with understanding the esxtop output.

I started more than 30 machines to reproduce the problem, and quickly went through the list of usual suspects: CPU, memory and IO:

• CPU
  I’ve verified that it’s not a CPU problem since the “CPU load average” was around 0.2. and PCPU was much the same.
• Memory
  Then I’ve switched to the memory display and verified that it’s not a physical memory issue. I saw the “high state” marker which was a good sign + there were almost 17GB ursvd (unreserved memory) in the VMKMEM/MB line.
  SWAP (~3GB) seemed OK.
  VMWare’s ballooning and memory sharing does miracles in broad day light.
• I/O
  I didn’t see any queues forming. read/write rates seemed pretty low.

So, the 25 VMs performance limit will remain a mystery until I’ll have proper time to analyze it more throughly, or even better, I’ll find someone from IT to do that for me.

I found a couple of resources about the problem but none fully worked for me, here is my special recipe:
The configuration I used was: RHEL 5.1 VM, and ESX 3.x server.

1. Use the converter to load the image to the ESX
2. If you will start the converted image on the ESX you will see a kernel panic message
3. Go to VMWare infrastructure client -> ESX server -> vm props -> hardware -> SCSI controller -> change from buslogic to LSI Logic
4. Load the vm CD-ROM drive with RHEL5 install disk (also serves as a rescue disk)
5. Boot the VM from the CD -> when prompted, enter: linux rescue
6. The rescue disk should identify the linux partition and mounts it on /mnt/sysimage
7. After getting a prompt enter: chroot /mnt/sysimage
8. Backup, and then edit /etc/modules.conf, add this line: alias scsi_hostadapter BusLogic
9. Backup the current ramdisk file: cp /boot/init-[version].img /boot/init-[version].img.bak
10. Rebuild with new module and overwrite existing:  mkinitrd -f -v /boot/initrd-[version]-img [version]
11. Reboot the OS.
12. Boot from the hard drive – The system will start normally

Weird that VMWare do not bother with their official proper documentation.
Kudos to the vmware user community!

Some of the reasons for changing a machine’s hostname might be:
(1) You want to clone a new server from a, best practiced already installed, server template, each cloned copy should have a unique computer name (very useful in test environments, especially handy when making a vm duplicate of a template virtual machine).
(2) You have an existing server which changed its business role – you plan to install a  new application module (EAR), but want to keep the existing middleware infrastructure (JEE AS).
(3) You no longer want the server to be reachable by it’s original name (without making use of DNS administration, and aliases tricks).
(4) You want to implement a new server naming convention in your production environment.

Now Programmers, how hard can it be to live in peace with a dynamic hostname?
(1) If you are sure that the target network resource is the local machine then just use the localhost loopback interface instead of a hostname, when addressing it.
(2) Query the OS when retrieving the machine’s hostname, instead of relying on static, sometimes binary, stale, configuration files.
(3) Keep all application network resources is a centralized configuration repository. Provide an offline API for the admin to access it.

As a side note:
IBM WAS ND 6.X now has, a long awaited, offline API for updating the hostname of a machine.
If you know and care about other products that support or don’t support hostname updates, please place your comment.