On 25 Jun, 08:48, "Steve M. Fabac, Jr." wrote:
> I have not touched VMWare and don't know where to
> start to investigate this issue. So I thought I'd
> post it here where several users have implemented various
> systems for their own use or client's to solicit recommendations
> on suitable system configurations to replace the client's
> current servers.
>
> The client running SCO 5.0.5 Enterprise on two
> servers, one is the live production and the other is
> a "hot spare."

Gack. Can you get the clients upgraded to 5.0.7? There are real
problems installing older versions of OpenServer under VMware, due to
issues with older drivres for the emulated BusLogic SCSI controller.

> These are identical SuperMicro PIII 1.4Ghz machines with
> 512M RAM and a DPT 3754U2 RAID controller with 16M cache RAM,
> and two 36G SCA 10K disks in RAID1.

Time to upgrade: you're going to take a serious performance hit from
virtualization. I like Dell 2950's and 2970's, which are what a number
of Xen consultants use, and give decent performance for VMware
Workstation.

> Both machines are backed up each night to their own Sony
> SDT-9000 DAT drive. And the application data directories and
> user home directories are copied from the live server to the
> backup server before the tape backup runs.

You need to think hard about your server technology. VMware ESX is
RHEL 3, stripped down to a nerarly useless micro-installation. As
such, you're nearly compelled to use VMware's backup tools or install
expensive backup tools directly on your SCO virtual instances. But
such backup services are pretty inefficient, and prone to all sorts of
problems, and the ability to do bare metal restorations on OpenServer
is.... awkward.

I've switched to using rsnapshot on my OpenServer boxes, and
downloading nightly images to a centralized backup server with tape
drives on it, or with a Backup Exec or other network client. The
backup server can then provide NFS or otherwise authorized access to
the snapshots, to the server that got backed up, for users to have
file recovery from snapshots. It can save one heck of a lot of work
mounting tapes.

> Charged with upgrading this hardware, it makes sense to plan
> to migrate to a single CPU system board hosting a 2-3 GHz dual
> or quad core Xeon CPU. I would then replace the full length
> DPT RAID controllers with a current technology RAID controller
> either SATA or SAS with suitable 76G to 146G hard drives in RAID1

Think about speed. SAS can go up to 15K RPM's but have smaller sizes,
SATA is typicall 7200 RPM at the 500 GB or larger sizes.

> Clearly, moving both live and backup systems to modern hardware
> will require upgrading the SCO 5.0.5 OS to either 5.0.7 or
> SCO Openserver 6.0 on both machines.

I've heard bad reports of 6, but I'm not sure I trust them and don't
have time to pursue it. If you find a source for cheap 5.0.7 licenses,
post it! I'd love to upgrade the 5.0.6 that I'm working with.

> What's the current opinion on a solid system that will run either
> 5.0.7 or 6.0 and have drivers for a RAID controller?
>
> An alternative strategy I'd like to offer the client is a configuration
> using VMWare to Virtualize both the primary and backup 5.0.5
> servers.

Xen won't do it, it doesn't support SCO OpenServer (and shows no signs
of ever doing so). VMware ESX is expensive and will buy you,
personally, nothing. Get the VMware Workstation, spend a bit of time
integrating it to your needs, and you can install various SCO
OpenServers with emulated IDE controllers that require nothing in
terms of SCSI driver wackiness to get installed.

> I've checked the VMWare web site and I see VMW products ranging
> in price from $3624 to $21824 and I have no clue on how to
> specify the product the client needs.

Unless you need a lot of GUI's and live migration, stick with VMware
Workstation 6. The ability to use IDE emulation will save you hours of
work installing and managing SCO OpenServer.

> Please comment on the following:
>
> 1) One or two hardware platforms? The client desires to maintain
> * * hardware redundancy so that if the primary box goes down, we can
> * * switch operations to the secondary box.

You've just answered your own question.

> 2) Then should I use one platform to host the primary (live) 5.0.5
> * * instance and a second VMWare platform hosting a running instance
> * * of the current backup server? This continues to require we take
> * * the time to copy the application data from the primary instance
> * * to the backup instance so that the backup instance is ready to
> * * go should the primary box fail.

Yup. Welcome to rsnapshot. Depending on the data, you can fold up
hourly or daily copies of entire OS's to take much less space than
you'd expect, by hardlinking duplicate files.

> 3) Or, not bother to keep a backup 5.0.5 server running on the redundant
> * * VMWare host but just migrate the live 5.0.5 image from the primary
> * * VMWare host to the backup VMWare host as needed? Can that even be
> * * done?

It requires storage of the 5.0.5 image somewhere reliable. That image
has to be on a centralized block device, such as an iscsi server or
fiber channel array. Expensive, and unnecessary for such a small
instance, and you're still vulnerable to failures of that storage
array.

> 4) How do we back up the live 5.0.5 server? Continue to use a dedicated
> * * SONY tape drive and BackupEdge running in the live 5.0.5 instance?
> * * Or is backup performed at the VMWare level? Is that reliable?

VMware can make snapshots of live instances, but if you're running
databases, this is begging for corruption when you try to start a new
instance from that snapshot. The VMware 'tools' normally available for
backing up clients *will not work* in SCO OpenServer. You need to have
a system, besides the VMware images, that can talk to your backup
media. This is why I like VMware Workstation, running on a nice stable
OS like RHEL or CentOS, that can support backup solutions, monitoring
solutions, etc., incidental to their use as VMware servers.

> 5) where is the UPS communication and monitoring software installed?
> * * under 5.0.5 or VMWare? Do we shutdown the 5.0.5 instance and then
> * * shutdown VMWare and power off the UPS to preserve the UPS battery?

There are theoretically ways to get VMware instances to talk to UPS
devices directly. VMware has no official support for SCO OpenServer,
and it's much easier to do from the VMware server. The underlying RHEL
3 used for VMware ESX is an antique 2.4 Linux kernel, it's a wildly
out of date OS, and it's deliberately stripped down. You cannot expect
anything to operate with it other than VMware and VMware sold tools.

There's also a fascinationg problem with VMware and SCO Openserver
systems and clocks, which I've written about before, which you can see
at http://unix.derkeiler.com/Newsgroups...msg00041..html

> I'm sure that there are other questions that I have not thought of that
> will have to be answered to design the optimal strategy for the client.
> If you can answer any of the above questions or offer insights into
> other important considerations, please post them.
> --
> * * * * * * * * * * * * * * * * * * * Steve Fabac
> * * * * * * * * * * * * * * * * * * * *S.M. Fabac & Associates
> * * * * * * * * * * * * * * * * * * * * 816/765-1670

I'm a consultant, in the UK and pretty busy right now, or I'd offer to
take it up as a project. Can you find a VMware guru near you?

On Wed, Jun 25, 2008, Nico Kadel-Garcia wrote:
>On 25 Jun, 08:48, "Steve M. Fabac, Jr." wrote:
>> I have not touched VMWare and don't know where to
>> start to investigate this issue. So I thought I'd
>> post it here where several users have implemented various
>> systems for their own use or client's to solicit recommendations
>> on suitable system configurations to replace the client's
>> current servers.
>>
>> The client running SCO 5.0.5 Enterprise on two
>> servers, one is the live production and the other is
>> a "hot spare."
>
>Gack. Can you get the clients upgraded to 5.0.7? There are real
>problems installing older versions of OpenServer under VMware, due to
>issues with older drivres for the emulated BusLogic SCSI controller.

Bela and others have recommended using IDE emulation rather than SCI on
VMWare server or workstation for OpenServer installations.

>> These are identical SuperMicro PIII 1.4Ghz machines with
>> 512M RAM and a DPT 3754U2 RAID controller with 16M cache RAM,
>> and two 36G SCA 10K disks in RAID1.
>
>Time to upgrade: you're going to take a serious performance hit from
>virtualization. I like Dell 2950's and 2970's, which are what a number
>of Xen consultants use, and give decent performance for VMware
>Workstation.

I'm partial to the Supermicro main boards and chassis.

....
>> Charged with upgrading this hardware, it makes sense to plan
>> to migrate to a single CPU system board hosting a 2-3 GHz dual
>> or quad core Xeon CPU. I would then replace the full length
>> DPT RAID controllers with a current technology RAID controller
>> either SATA or SAS with suitable 76G to 146G hard drives in RAID1
>
>Think about speed. SAS can go up to 15K RPM's but have smaller sizes,
>SATA is typicall 7200 RPM at the 500 GB or larger sizes.

There are 10,000 RPM SATA drives, essentially identical to similar server-
grade SCSI drives including having similar sizes and prices. We have been
using the WD Raptors with good results.

>> Clearly, moving both live and backup systems to modern hardware
>> will require upgrading the SCO 5.0.5 OS to either 5.0.7 or
>> SCO Openserver 6.0 on both machines.
>
>I've heard bad reports of 6, but I'm not sure I trust them and don't
>have time to pursue it. If you find a source for cheap 5.0.7 licenses,
>post it! I'd love to upgrade the 5.0.6 that I'm working with.

I don't have problems with 5.0.6a, restricted though it may be, as we don't
do anything other than run in-house accounting applications and associated
development on the SCO boxes. Everything that requires serious networking
or other tools is done on Linux or FreeBSD boxen.

Consider that much of the software running on OpenServer was designed years
ago to work with dumb terminals on hardware that's probably comparable to
commodity router appliances today.

Bill
--
INTERNET: bill@celestial.com Bill Campbell; Celestial Software LLC
URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way
Voice: (206) 236-1676 Mercer Island, WA 98040-0820
Fax: (206) 232-9186

The only logical reason to take guns away from responsible people is to
give irresponsible people an edge in the perpetration of their crimes
against us. -- The Idaho Observer, Vol. 1, No. 2 February 1997

On 26 Jun, 01:01, Bill Campbell wrote:
> On Wed, Jun 25, 2008, Nico Kadel-Garcia wrote:
> >On 25 Jun, 08:48, "Steve M. Fabac, Jr." wrote:
> >> I have not touched VMWare and don't know where to
> >> start to investigate this issue. So I thought I'd
> >> post it here where several users have implemented various
> >> systems for their own use or client's to solicit recommendations
> >> on suitable system configurations to replace the client's
> >> current servers.
>
> >> The client running SCO 5.0.5 Enterprise on two
> >> servers, one is the live production and the other is
> >> a "hot spare."
>
> >Gack. Can you get the clients upgraded to 5.0.7? There are real
> >problems installing older versions of OpenServer under VMware, due to
> >issues with older drivres for the emulated BusLogic SCSI controller.
>
> Bela and others have recommended using IDE emulation rather than SCI on
> VMWare server or workstation for OpenServer installations.

VMware ESX does not support IDE emulation, only SCSI. I don't like
VMware ESX, I think it's an excuse to sell a lot of expensive,
specialized hardware and software that's unnecessary for small
installations. Don't get me started on that excuse for a Windows GUI
they use to manage it.

Nico Kadel-Garcia wrote:
> On 26 Jun, 01:01, Bill Campbell wrote:
>
>>On Wed, Jun 25, 2008, Nico Kadel-Garcia wrote:
>>
>>>On 25 Jun, 08:48, "Steve M. Fabac, Jr." wrote:
>>>
>>>>I have not touched VMWare and don't know where to
>>>>start to investigate this issue. So I thought I'd
>>>>post it here where several users have implemented various
>>>>systems for their own use or client's to solicit recommendations
>>>>on suitable system configurations to replace the client's
>>>>current servers.
>>
>>>>The client running SCO 5.0.5 Enterprise on two
>>>>servers, one is the live production and the other is
>>>>a "hot spare."
>>
>>>Gack. Can you get the clients upgraded to 5.0.7? There are real
>>>problems installing older versions of OpenServer under VMware, due to
>>>issues with older drivres for the emulated BusLogic SCSI controller.
>>
>>Bela and others have recommended using IDE emulation rather than SCI on
>>VMWare server or workstation for OpenServer installations.
>
>
> VMware ESX does not support IDE emulation, only SCSI. I don't like
> VMware ESX, I think it's an excuse to sell a lot of expensive,
> specialized hardware and software that's unnecessary for small
> installations. Don't get me started on that excuse for a Windows GUI
> they use to manage it.

VMware ESX provides High-Availability (with the proper license option)
so Steve could solve the problem he has wanting to have a machine as a
"hot spare": build a two-node ESX Virtual Infrastructure, and put its
shared storage on some iSCSI (cheap) place (that would be a third server
with the disks and with a software iSCSI target daemon, instead of
buying and expensive SAN solution). But ESX is expensive for small shops.

Another solution would be to build two independent "VMware Server for
Linux" machines (free as beer, except for the hardware) (server A and
server B). Then Steve could put the production OpenServer 5.0.5 into a
virtual machine in server A (no need to buy new upgraded Openserver
licenses to support newer hardware), and replicate the virtual machine
virtual disk's files to the server B "VMware Server" installation. That
replication could be done: (a) stopping the Openserver virtual machine
at night, and copying the files via ethernet from server A to NFS in
server B, and then restarting the virtual machine (I think "VMware
Server" is scriptable via perl, anyone?); or (b) alternatively, using a
real-time open-file aware solution like Double-Take for Linux, which is
able to replicate via ethernet database files (which is what VMware
Server virtual disks are in essence) while they are in use and with
great network efficiency (it installs a driver into the Linux kernel
which intercepts disk block write operations and replicates them in
almost real-time to the target server via network). This solution (b)
would cost the price of two Double-Take for Linux licenses (source and
target server), which is something near 3,000 US$, so perhaps solution
(a) is in order if you can afford a one hour down-time at night to stop
the Openserver virtual machine and copy it over to server B the standard
way (with rsync or some such).

I would go for the ESX setup plus iSCSI as it is the most straight
forward and probably cheaper than using Double-Take plus the free
"VMware server for Linux". Unless you can totally shutdown OpenServer at
night for one hour, in which case you can build a totally free (as in
beer) solution (except for the hardware price).

Pepe wrote:
> (a) stopping the Openserver virtual machine
> at night, and copying the files via ethernet from server A to NFS in
> server B, and then restarting the virtual machine (I think "VMware
> Server" is scriptable via perl, anyone?)

Well, it seem that not only the virtual machines on the expensive VMware
ESX host can be scripted, but also the startup/shutdown of virtual
machines in the free VMware Server host can be scripted:

http://www.petri.co.il/virtual_scrip...re_servers.htm

Pepe wrote:
> Pepe wrote:
>> (a) stopping the Openserver virtual machine at night, and copying the
>> files via ethernet from server A to NFS in server B, and then
>> restarting the virtual machine (I think "VMware Server" is scriptable
>> via perl, anyone?)
>
> Well, it seem that not only the virtual machines on the expensive VMware
> ESX host can be scripted, but also the startup/shutdown of virtual
> machines in the free VMware Server host can be scripted:
>
> http://www.petri.co.il/virtual_scrip...re_servers.htm

That's a Windows specific set of commands. Under Linix or UNIX VMware, the
clients are not as gracefully managed if you run more than one client. The
'vmware' tool itself won't run without an X session, and the individual
clients need the use of the 'vmrun' command to happen form the command line,
and specific configurations of the vmware sessions themselves.

It really looks like somebody tried to port the Windows model of a GUI into an
X based world, and didn't really do the transfer cleanly. That's probably
because VMware is not oriented around the command line: it's oriented around
the Windows GUI client.

Pepe wrote:
> Pepe wrote:
>> (a) stopping the Openserver virtual machine at night, and copying the
>> files via ethernet from server A to NFS in server B, and then
>> restarting the virtual machine (I think "VMware Server" is scriptable
>> via perl, anyone?)
>
> Well, it seem that not only the virtual machines on the expensive VMware
> ESX host can be scripted, but also the startup/shutdown of virtual
> machines in the free VMware Server host can be scripted:
>
> http://www.petri.co.il/virtual_scrip...re_servers.htm

Oh, my. Look more closely at that page, particularly where it says:

> Notice what happened here. I was able to successfully stop second virtual
machine (see the stop = 1 code) but could not stop the first machine. This is
because the VMware Tools have not been installed on the first virtual
machine. You must install these tools to make the vmware-cmd work. Thus, this
first machine is still running.

There are no VMware tools for SCO operating systems: it's not a supported OS.

Nico Kadel-Garcia wrote:
> Pepe wrote:
>
>> Pepe wrote:
>>
>>> (a) stopping the Openserver virtual machine at night, and copying the
>>> files via ethernet from server A to NFS in server B, and then
>>> restarting the virtual machine (I think "VMware Server" is scriptable
>>> via perl, anyone?)
>>
>>
>> Well, it seem that not only the virtual machines on the expensive
>> VMware ESX host can be scripted, but also the startup/shutdown of
>> virtual machines in the free VMware Server host can be scripted:
>>
>> http://www.petri.co.il/virtual_scrip...re_servers.htm
>
>
> Oh, my. Look more closely at that page, particularly where it says:
>
> > Notice what happened here. I was able to successfully stop second
> virtual machine (see the stop = 1 code) but could not stop the first
> machine. This is because the VMware Tools have not been installed on
> the first virtual machine. You must install these tools to make the
> vmware-cmd work. Thus, this first machine is still running.
>
> There are no VMware tools for SCO operating systems: it's not a
> supported OS.

Too true. But no worries. You can build an "expect" script to remotely
shutdown (via telnet or ssh) the OpenServer guest running on the "VMware
Server for Linux" server A, and then use the "vmware-cmd" also from
server A to "physically" shutdown the virtual machine itself. Then you
can copy the *.vmdk, etc., files form server A to NFS in server B, and
then you can use again "vmware-cmd" in server A to start the OpenServer
guest virtual machine.

It can all be done quite easily with scripts from Linux (I didn't know
you needed X-Window to be able to run the "vmware-cmd" commmand in
Linux, but anyway it is probably a non issue in this case, as I don't
think Steve would mind installing X-Window into the Linux "VMware
Server" to make it just work - in fact, given the state of Linux today,
it would be much harder to manage a Linux installation without X than
with them).

As for the "expect" script, it goes something like this:

#!/usr/bin/expect -b
log_user 0
spawn telnet 192.168.0.10
expect login:
send root\r
expect password:
send PasswordOfRoot\r
sleep 5
send "shutdown -y now and whatever Openserver needs here\r"
sleep 3
send exit
close

Then you wait 5 minutes with some "sleep" command, for OpenServer to
display the ** Safe to poweroff ** legend (or more, or less, Steve
should know how long it takes to shutdown his OpenServer application
software), and then you issue the "vmware-cmd VMname stop" commmand from
server A.

You could do the "expect" thing against ssh instead of telnet if you
please. Yes, you need to put the root password in there somewhere, or
you could give some "sudo" permissions to shutdown for some other user,
YMMV... (yes, I know OpenServer does not have sudo but it has something
to the same effect with another name which I don't remember now).

Regards,

Pepe.

Pepe wrote:
> Then you wait 5 minutes with some "sleep" command, for OpenServer to
> display the ** Safe to poweroff ** legend (or more, or less, Steve
> should know how long it takes to shutdown his OpenServer application
> software), and then you issue the "vmware-cmd VMname stop" commmand from
> server A.

Actually, that would be "vmware-cmd VMname.vmx stop hard". Just make
sure the "expect" script managed to first shut down the the guest
OpenServer.