Part of our bussiness (Progress and Cobol software) still ran on a Compaq Proliant PII server (a piece of hardware running very long after its expected lifetime). The server was a SCO Open Server Release 5.0.4 of 1997 and there was no feasible upgrade path to any current OS. This meant any hardware replacement would have to be compatible with 1997 era Unix drivers. This was a big problem, since it's almost impossible to find a decent and suitable hardware replacement.
We decided to convert it to an ESX VM - (ESXi 4.1.0 server in our case).
Unfortunately SCO OSR5 isn't on the list of ESX compatible operating systems, and besides that, our aim was to convert the whole existing installation, not starting from scratch (avoiding software installation, creating users, printers, etc)
Research on websites and forums gave us some clues, but only after some trial and error configurations, we successfully solved the problem. This document's intention is to give advice and hope to IT people out there in similar situations.
The first problem was to transfer the disk image onto the ESX server.
We first tried Acronis for disk imaging but in this case it didn't work. Instead we used g4u, a handy free utility that copies the exact disk geometry (a slow but worthy operation) and uploaded the image to a ftp server on your LAN.
Then, we created a VM on the ESXi server.
We selected SCO Openserver 5 as the operating system, thin IDE disks (here we selected bigger disks to fit future space requirements) and the proposed flexible network adapter.
We booted the VM with the g4u bootcd, and deployed the image(s).
Booting in normal mode leads to kernel panic warnings. Instead, at the boot prompt, we entered unix.safe. Then when it asked for CTR D, or our password, we entered our password to enter maintenance mode. We established an ansi TERM environment.
Then we selected scoadmin and removed all the Compaq drivers for the Proliant hardware:
Scoadmin----software manager---compaq extended feature supplement--- remove software
and relinked the kernel.
Once done, we booted up fine.
The network config had to be updated but this was easily done from the SCOadmin menu:
First, we removed the old LAN adapter (if present) and rebooted. The SCO's VM recognised the ESX AMD virtual NIC without needing a new driver.
We added that adapter and set up our suitable network environment, relinked kernel and rebooted.
Then, if we had created bigger virtual disks than the physical ones, we created new divisions/partitions for the unused disk space, through normal Unix commands (divvy and/or scoadmin), and set up mounting parameters.
From here on, normal backup procedures as with the now decomissioned physical server. Also from the ESXi server vsphere client, we chose to export the entire VM as OVF periodically, for disaster recovery purposes.
All the users accessed the applications via a telnet based terminal client so nothing had changed as far as they were concerned.
Pedro De Carlo, Ch.E., IT.
Thanks to my colleague Roberto Capacio, a Unix self-made-man, for help and encouragement.
Thanks to Nicolás Cambria, of KIT Ingenieria Electronica, http://http://www.kit.com.ar/
Walter, posting at Tony Lawrence's useful website: http://aplawrence.com/SCO_OSR5/vmware_504.html
Tom Finnis (posting a similar case, giving me accurate words with his post):
http://www.help4it.co.uk/home-mainmenu-1/inside-track/SCO-Unix-on-VMware-ESX-virtualisation-solves-a-clients-problem.html
g4u: http://www.feyrer.de/g4u/ (free and very useful tool)
