I received a frantic SMS from an old classmate running a travel agency business saying that his SCO machine cannot now boot. He is running an application written to a 3-GL/4-GL product called Thoroughbred. He has had the system running since about 1999. And since it does not connect to the Internet, and only has internal LAN users coming in via a telnet connection, he never needed to keep it updated.
So, what was the problem? His 10-year old IBM tower machine failed to boot. Got some help from a local vendor and found that it was the power supply that failed not the harddisk. WIth the power supply replaced, he is now back in business. The proposal given to him from the vendor who fixed the hardware was to “upgrade to a new machine, but we cannot guarantee that the OS and applications you have running will work”.
Enter, the lunch meeting. After hearing his story, I thought his situation would make for an interesting case study for virtualization. So, with his permission, I got hold of the “still in original shrink-warp” SCO manuals and CDs along with the Thoroughbred software and installed the SCO OpenServer 5.0.5 in a RHEL 5.4 VM.
Here is what I had to do:
a) dd’ed the SCO OpenServer 5.0.5 CD (“you can now boot from the CD if your BIOS supports it”) into an iso. It came up to about 280M only!
b) From virtual-machine-manager, choose a new maching with full virtualization
c) Specified 800MB as the drive size (imagine that!)
d) Kept the defaults for the rest.
e) Proceeded with the boot up and installation.
f) All went well. It is hilarious to see the setting up of the harddisk with the sector numbers and heads being cycled through – the “drive” is virtual, and kudos to the virtualization engineers, the SCO installation program was sufficiently convinced that it was all real.
g) Boot up.
The boot up went well (user: root and password: fedora). But the network was not working. Had to start “scoadmin” to get into a curses based setup to configure the network device. I had to go back to virtual-machine-manager and set this VM to have a “pcnet” network. The default “hypervisor” network did not seem to work. The “pcnet” is apparently a ISA device which the SCO has drivers for. It was in the AMD section of the hardware network hardware setup section of the scoadmin command.
So here’s the /etc/libvirt/qemu/sco-openserver-5.0.5.xml:
sco-openserver-5.0.5 447d29e3-7891-bb76-385c-82d38e43e739 524288 524288 1 hvm destroy restart restart /usr/bin/qemu
[BTW, in the xml file above, I have to add a space after the < above so that it will not be interpereted by lj. Edit out the extra space if you want to use the xml file.]
The SCO OpenServer 5.0.5 does not have DHCP default and needs an IP to be specified. So, an IP, netmask and default gw has to be specified manually. Interestingly, the network device is “net3”.
It could ping out of the box, telnet to external machines etc so the NAT setup of the VM is working fine.
Looks like I have solved the problem from my friend by using virtualization. Now can get go get a new machine and run RHEL 5.4 on it have his ancient SCO OpenServer 5.0.5 + applications run in perpetuity.