Log in

Alas, a blog! Live life, like you give a damn!

Rescuing a SCO OpenServer 5.0.5 machine to run in a VM on RHEL5.4

Rescuing a SCO OpenServer 5.0.5 machine to run in a VM on RHEL5.4

Previous Entry Share Next Entry
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 powersupply that failed not the harddisk. WIth the powersupply 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:
< domain type='qemu'>
  < name>sco-openserver-5.0.5</name>
  < uuid>447d29e3-7891-bb76-385c-82d38e43e739</uuid>
  < memory>524288</memory>
  < currentMemory>524288</currentmemory>
  < vcpu>1</vcpu>
  < os>
    < type arch='i686' machine='pc'>hvm</type>
    < boot dev='hd'/>
  < /os>
  < features>
    < acpi/>
    < apic/>
    < pae/>
  < /features>
  < clock offset='utc'/>
  < on_poweroff>destroy</on_poweroff>
  < on_reboot>restart</on_reboot>
  < on_crash>restart</on_crash>
  < devices>
    < emulator>/usr/bin/qemu</emulator>
    < disk type='file' device='disk'>
      < source file='/var/lib/libvirt/images/sco-openserver-5.0.5.img'/>
      < target dev='hda' bus='ide'/>
    < /disk>
    < disk type='file' device='cdrom'>
      < target dev='hdc' bus='ide'/>
      < readonly/>
    < /disk>
    < interface type='network'>
      < mac address='54:52:00:3c:a2:67'/>
      < source network='default'/>
      < model type='pcnet'/>
    < /interface>
    < serial type='pty'>
      < source path='/dev/pts/3'/>
      < target port='0'/>
    < /serial>
< console type='pty' tty='/dev/pts/3'>
      < source path='/dev/pts/3'/>
      < target port='0'/>
    < /console>
    < input type='mouse' bus='ps2'/>
    < graphics type='vnc' port='-1' autoport='yes' keymap='en-us'/>
  < /devices>
< /domain>

[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 virualization. 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.
  • Re: Virtualization

    David -

    Hi. Good to hear from you.

    Load balancing is not the same as server virtualization. Load balancing is about having same systems share a load. For example, you can have 4 systems running an exact copy of the webserver and have another system in front of these 4 machines which will direct incoming web requests evenly. This is called round-robin load balancing. Load balancing has many other deployments as well (databases, etc).

    Server virtualization could be the building block of what could be deployed in a load balancing situation.

    Consider the following:
    a) You have 4 physical machines all installed with Linux and running Apache as the web server.
    b) With a 5th machine sitting in front of those 4, you can implement a form of round robin load balancing.
    c) Now consider instead of 4 physical machines, you have 4 virtual machines all running on one physical machine. Let's say you have a 5th VM running the round-robin load balancing tool. With this setup you are using VM techniques below a load balancing solution.

    I hope this was a clear enough explanation.

Powered by LiveJournal.com