Beginnning to think about VMware and SCO 5.0.5 - SCO

This is a discussion on Beginnning to think about VMware and SCO 5.0.5 - SCO ; 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 ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: Beginnning to think about VMware and SCO 5.0.5

  1. Beginnning to think about VMware and SCO 5.0.5

    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."

    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.

    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.

    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

    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.

    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.

    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.

    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.

    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.

    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?

    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?

    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?


    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

  2. Re: Beginnning to think about VMware and SCO 5.0.5

    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?

  3. Re: Beginnning to think about VMware and SCO 5.0.5

    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

  4. Re: Beginnning to think about VMware and SCO 5.0.5

    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.

  5. Re: Beginnning to think about VMware and SCO 5.0.5

    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).

  6. Re: Beginnning to think about VMware and SCO 5.0.5

    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

  7. Re: Beginnning to think about VMware and SCO 5.0.5

    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.

  8. Re: Beginnning to think about VMware and SCO 5.0.5

    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.

  9. Re: Beginnning to think about VMware and SCO 5.0.5

    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.

  10. Re: Beginnning to think about VMware and SCO 5.0.5

    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.

+ Reply to Thread