SCO's 5.0.7V on vmware server 2.0?
OregonBob
boast will run on vmware, but the getting-started docs don't mention
using vmware server 2.0 (the free version). Has anyone got this to
work and if so how did you do it?
It seems silly they don't document using it with the most popular
versions of vmware. But it is SCO. And that yearly subscription? What
were they thinking? That sure gives a lot of confidence--buying
something that will quit on a yearly basis from a company that is
going through bankruptcy.
I am still using a 5.0.6 virtual machine I built three years ago for
an old but required app, but it would be nice to go with something
newer and better.
Bela Lubkin
> I see SCO has a downloadable 5.0.7 virtual machine in ISO form they
> boast will run on vmware, but the getting-started docs don't mention
> using vmware server 2.0 (the free version). Has anyone got this to
> work and if so how did you do it?
>
> It seems silly they don't document using it with the most popular
> versions of vmware. But it is SCO.
(I worked at SCO for 15 years, and now VMware for 5 years; not speaking
for either of them, of course...)
As it turned out, VMware Server was never the most popular of VMware's
products. It is now "end of life" (see small comment "*VMware Server
was declared End Of Availability on January 2010. Support will be
limited to Technical Guidance for the duration of the support term." at
<http://www.vmware.com/support/policies/lifecycle/general/index.html>).
In detail, it shows that general support for VMware Server 1.x ended on
2010-03-23, and 2.x ends on 2011-06-30.
VMware ESXi (current official name is "VMware vSphere Hypervisor(TM)")
is far more popular than Server ever was. This is the free version of
vSphere (nee ESX), VMware's bare-metal full hypervisor. One of the FAQs
at <http://www.vmware.com/products/vsphere-hypervisor/faq.html>
discusses Server vs. ESXi. That URL also leads to the rest of the
materials about ESXi.
The "OpenServer 5.0.7V version 2.0.0" downloads, conveniently hidden at
<http://www.sco.com/support/update/download/product.php?pfid=16&prid=25>,
do document the product as supported under ESXi 4.x as well as ESX 4.x
(and 3.5 of both, but I would definitely recommend 4.0 or 4.1).
========================================================================
> And that yearly subscription? What
> were they thinking? That sure gives a lot of confidence--buying
> something that will quit on a yearly basis from a company that is
> going through bankruptcy.
I've been telling them this ever since I first heard of the 507V project
(somewhat before 1.0 shipped). They can't hear due to fingers-in-ears-
LALALALALALA -- part of SCO's general world view, as you know...
Apparently they intend to promise that if they ever go all the way
under, they'll post instructions on freeing up these licenses. How
that's supposed to work when it'll all be tied up 37 ways with legal
nonsense, and after they're already dead, and why anyone should believe
it when it isn't even posted anywhere as a "promise", I have no idea.
> I am still using a 5.0.6 virtual machine I built three years ago for
> an old but required app, but it would be nice to go with something
> newer and better.
OSR507V includes VMware Tools, which is a good benefit; unfortunately
not available without the subscription model :-(
OSR507V 2.0.0 adds one very significant benefit: you are no longer
restricted to the "virtual appliance" model. It is also available as a
supplement to be installed onto your existing virtualized OSR507
systems, thus adding VMware Tools and whatever else SCO has done. But
still, of course, under the subscription licensing model.
========================================================================
If you plan to use *any* SCO System V OS under virtualization (including
OSR5, OSR6, UW7), I *STRONGLY* recommend you get a system with support
for hardware virtualization, including nested page tables. This makes a
tremendous difference in SCO-on-V performance (much more so than for any
other guest OS except maybe OS/2 and non-Linux-based versions of
Netware).
It is *not* enough to get a chip with HV support, it must be HV + nested
page tables.
For AMD this means: any quad core or higher server (Opteron) processor;
any Phenom, Phenom II, or later processor; basically anything that is
based on a "K10" family core. For practical purposes this more or less
means any *currently on the market* AMD CPU. 2-core Opterons and older
Athlons do not support RVI ("Rapid Virtualization Indexing", AMD's name
for nested page tables). Some chips with "Athlon" in their name do
actually support RVI, due to AMD's habit of carrying old product names
forward into the low end of new product lines. But I would just get
either Opteron (4+core) for multi-CPU big server applications, or Phenom
for smaller projects.
For Intel this means: anything based on Nehalem or later (Westmere,
Sandy Bridge) cores. Nothing earlier. Intel calls the feature
"Enhanced Page Tables" (EPT).
<http://cpu-world.com> is a pretty good resource for CPU info.
Unfortunately it doesn't seem to cover EPT for Intel CPUs. Its CPUID
data does cover RVI (as "nested page tables") for AMD. For Intel you
need to look at the core code name and determine whether it's a member
of the Nehalem, Westmere or Sandy Bridge design generations.
>Bela<
OregonBob
have a client that is very dependent on Foxpro Unix that only runs on
SCO, so I will have to get into ESXi real fast or get the client into
a replacement platform. They don't want to switch since I did 10 years
of custom work on the app to make it do exactly what they wanted.
Time flies. I am probably 3 years or more behind on everything. Still
running 5.0.6 is an indicator, but hey it has been running with zero
maintenance for a very long time.
Thanks again for info.
Stephen M. Dunn
$Time flies. I am probably 3 years or more behind on everything. Still
$running 5.0.6 is an indicator, but hey it has been running with zero
$maintenance for a very long time.
I still manage two SCO boxes. One is my home PC, which dual-boots 5.0.7
and Windows. 5.0.7 works just fine, even though I'm now running it on
hardware significantly newer than the last MP for 5.0.7 and each hardware
upgrade has involved merely a reconfiguration of the existing installation
rather than a fresh installation (i.e. this may be a bit of a Frankenstein
configuration but it's still perfectly reliable).
The other is at a client site, running 5.0.4 (yup) on decade-old
hardware. I've been trying to get them to upgrade this for ages, and
they're finally considering it, but not because 5.0.4 isn't working; it
does the job for them just fine. The main thing that's convinced them to
look into upgrading is that the *hardware* is getting flaky.
So I can't really complain about the reliability of OSR5.
(The remainder of my former SCO clients have all moved to other
platforms over the years, either because they migrated or upgraded
applications to versions which no longer support SCO or because Linux works
perfectly well and doesn't have licensing costs.)
--
Stephen M. Dunn <ste...@stevedunn.ca>
>>>----------------> http://www.stevedunn.ca/ <----------------<<<
------------------------------------------------------------------
Say hi to my cat -- http://www.stevedunn.ca/photos/toby/
John DuBois
Bela Lubkin <fi...@armory.com> wrote:
>The "OpenServer 5.0.7V version 2.0.0" downloads, conveniently hidden at
><http://www.sco.com/support/update/download/product.php?pfid=16&prid=25>,
>do document the product as supported under ESXi 4.x as well as ESX 4.x
>(and 3.5 of both, but I would definitely recommend 4.0 or 4.1).
>OSR507V 2.0.0 adds one very significant benefit: you are no longer
>restricted to the "virtual appliance" model. It is also available as a
>supplement to be installed onto your existing virtualized OSR507
>systems, thus adding VMware Tools and whatever else SCO has done. But
>still, of course, under the subscription licensing model.
A couple of other 507v2 enhancements that are worth noting:
- It now include an implementation of the memory (balloon) driver,
useful if you run more than one VM on a system.
- init 0 now actually "powers down" the VM, instead of leaving it in a CPU spin
loop at "Press any key to reboot".
fwiw, I would expect 507v to run under Server; my very-early development work
was done under that. I've also run 507v2 in VMware Player.
John
--
John DuBois spc...@armory.com KC6QKZ/AE http://www.armory.com/~spcecdt/
DAW
> In article <5cd10a1f-bbb0-4203-acb8-10948566f...@37g2000prx.googlegroups.com> OregonBob <oregon...@gmail.com> writes:
> $Time flies. I am probably 3 years or more behind on everything. Still
> $running 5.0.6 is an indicator, but hey it has been running with zero
> $maintenance for a very long time.
>
> I still manage two SCO boxes. One is my home PC, which dual-boots 5.0.7
> and Windows. 5.0.7 works just fine, even though I'm now running it on
> hardware significantly newer than the last MP for 5.0.7 and each hardware
> upgrade has involved merely a reconfiguration of the existing installation
> rather than a fresh installation (i.e. this may be a bit of a Frankenstein
> configuration but it's still perfectly reliable).
>
> The other is at a client site, running 5.0.4 (yup) on decade-old
> hardware. I've been trying to get them to upgrade this for ages, and
> they're finally considering it, but not because 5.0.4 isn't working; it
> does the job for them just fine. The main thing that's convinced them to
> look into upgrading is that the *hardware* is getting flaky.
>
> So I can't really complain about the reliability of OSR5.
>
> (The remainder of my former SCO clients have all moved to other
> platforms over the years, either because they migrated or upgraded
> applications to versions which no longer support SCO or because Linux works
> perfectly well and doesn't have licensing costs.)
> --
>
> ------------------------------------------------------------------
> Say hi to my cat --http://www.stevedunn.ca/photos/toby/
How are you running Windows and OSR 5.0.7 on the same box? I did run
both operating systems UP UNTIL THE BLOATED Windows XP Pro came
along. Then there was just not enough room above Windows to allow SCO
to boot within the first 1024 cylinders. It's still on the box, being
saved on a couple of SCSI drives for some future solution but it isn't
set to boot.
Prior to Win XP I used an old boot diskette with a nice fdisk to
change the desired boot OS. Or, I left it booting to OSR 5.0.6 and
used the command line bootos to boot windows. Also, when working
mostly in Windows I used the SCO fdisk to make the windows system
boot.
Thanks,
DAW
Stephen M. Dunn
$How are you running Windows and OSR 5.0.7 on the same box? I did run
$both operating systems UP UNTIL THE BLOATED Windows XP Pro came
$along. Then there was just not enough room above Windows to allow SCO
$to boot within the first 1024 cylinders.
The first partition on my drive is a 7.5 GB Windows partition,
followed by the Unix partition. Only the boot filesystem needs to
fit within the first 8 GB, and that's only a few tens of megabytes,
so I could have left a few hundred megs more space for Windows if I
wanted to try to cut it as close as possible. After the Unix partition,
there's another Windows partition, so that I can install programs and
data outside of C:. There are also plenty of things that default to
being on C: but that provide a UI to move them elsewhere, including
temp files, the Windows swap file, browser caches, and My Documents,
so none of those reside on C:.
There are a lot of Windows programs with rude installers that
assume you want them on C: and don't offer you the option of installing
them elsewhere. There's also tons of crap that gets thrown into
C:\Documents and Settings and C:\Program Files\Common Files even if
the program offers to let you install it elsewhere. As a result, I've
had to use junction points to move a bunch of stuff out of C: over the
years, and also compressed a bunch of things that get put on C: but
rarely used, in order to keep C: from running out of space (in addition
to the usual cleanup things like deleting the uninstall directories for
old Windows updates).
--
Stephen M. Dunn <ste...@stevedunn.ca>
Bela Lubkin
> How are you running Windows and OSR 5.0.7 on the same box? I did run
> both operating systems UP UNTIL THE BLOATED Windows XP Pro came
> along. Then there was just not enough room above Windows to allow SCO
> to boot within the first 1024 cylinders. It's still on the box, being
> saved on a couple of SCSI drives for some future solution but it isn't
> set to boot.
What Stephen Dunn said, plus...
OSR507 shouldn't need any part of its boot chain written below 8GiB. If
the later "wd" supplements are installed (I believe part of MP5), it
shouldn't even need any part below 128GiB. *If* the OSR5 masterboot is
in place and OSR5's idea of disk geometry is stamped to the disk (things
that should happen automatically during install, but may not due to a
variety of bugs and mishaps that have been discussed here many times).
> Prior to Win XP I used an old boot diskette with a nice fdisk to
> change the desired boot OS. Or, I left it booting to OSR 5.0.6 and
> used the command line bootos to boot windows. Also, when working
> mostly in Windows I used the SCO fdisk to make the windows system
> boot.
OSR5's fdisk should be happy to make Win XP bootable, and I would think
Win XP's fdisk would return the favor, so no floppy needed.
Besides that, if you leave OSR5 bootable in masterboot and set
"DEFBOOTSTR=dos" or something like that in /etc/default/boot, it should
autoboot into Windows. You might want to reduce TIMEOUT to maybe 3-4
seconds. I would also recommend moving the original DEFBOOTSTR to a
name like "OSR5", so that just typing "osr5" at the boot prompt
overrides the default of booting into Windows.
I forget if OSR507 (or any of the MPs) finally shipped the standalone
"cat" program /stand/cat. If so, you should be able to create a
/stand/.bootrc that says something like "cat hello", and a /stand/hello
with a message like "Press Enter for Windows or type osr5<Enter> for
Unix"...
>Bela<
DAW
>
> - Show quoted text -
Thanks Stephen and Bela-
Somehow I had the notion that OSR 5.x.x had to boot within the first
1024 cylinders. I'm pretty sure that's the text in the last couple of
user manuals I have. All the installation manuals I have actually
refer to co-existence with DOS but they go to great lengths to specify
the difference between cylindars and tracks. I do have some good
windows-based drive management software that I can use to re-arrange
the partitions on the first drive but I am confused about the prior
references (2 messages above) about 8Gb.
I see that I have 5.0.6A (supplement) sitting in front of me and also
have, somewhere 5.0.7 and 6.x.x. I don't plan to install release 6
because I understand it doesn't recognize release 5 file systems.
So, if anyone can clarify the boot requirements for 5.0.6 or 5.0.7 I
will be sure Windows is below that number and put the SCO stuff just
above it, as I did in the long ago.
Thanks,
DAW
Stephen M. Dunn
$Somehow I had the notion that OSR 5.x.x had to boot within the first
$1024 cylinders.
These limits stem from BIOS calls which specify cylinders, heads,
and sectors (CHS). The interface to these calls has had to be changed
several times over the years, first when hard drives were added (the
same BIOS call was initially designed for floppy disk access in the
original IBM PC), and subsequently due to the ongoing growth of hard
drives.
A reference text I have from the 1990s says that the BIOS calls (as they
existed back then) used 8 bits for the head number, 10 bits for the
cylinder number, and 6 bits for the sector number. The 10-bit cylinder
number is the origin of the 1024-cylinder limit.
Here's my primary drive as recognized by the kernel's boot-time
hardware listing:
name=disk base=0x1F0 offset=0x7 vec=14 dma=- type=W0/0 unit=0 cyls=24321 hds=255 secs=63
You can see that this still uses an 8-bit head number and a 6-bit
sector number. A sector is 512 bytes, and if you multiply it all out,
1024 cylinders works out to 8 GB.
(As a side note, any remotely modern hard drive, including ATA and
SCSI and everything descended from them, hides its internal geometry
and exposes itself as a linear array of blocks. So really, the CHS
value you specify in the BIOS call ends up being interpreted not as
coordinates in a three-dimensional array but as an index into a
one-dimensional array.)
The boot code is broken into a variety of chunks, which lie at the
very start of the entire hard drive, the start of the Unix partition,
and in the boot filesystem*. All of this must be within the limits of
the BIOS interface used by the boot code. Once the kernel is loaded,
it uses its own drivers to access your hard drive(s), and so the
1024-cylinder limit goes away.
*: One of the benefits of having a separate boot filesystem,
introduced as a standard feature in OSR5.0.0, is that you no longer
need to keep your entire root filesystem within the bootable area of
your hard drive, as you did in previous releases to ensure that
(say) relinking the kernel didn't result in some parts of the file
ending up outside the bootable area. The other is that the initial bits
of the boot code have to understand enough of the filesystem layout
to find everything they need, and the new filesystem types (HTFS and
DTFS) in OSR5 add too much complexity given that the boot code must
be quite compact. Separating the boot code into its own filesystem allows
the boot filesystem to remain as a simpler EAFS filesystem while allowing
you to use the more advanced features of HTFS or DTFS on your root
filesystem.