So everyone is going nuts for free VMware Workstation

I haven’t had a moment to really look into it, but Mathew Duggan‘s take on the whole experience: The Worst Website In The Entire World pretty much sums it up the whole thing.

On the plus side this makes things like adding VMnetworks and configuring them all possible for lowly end user people like me, and makes stuff like SNA networking a bit more easier.

But what is the catch?

There is always a catch!

I have a feeling this is just like when Java became ‘free’. And then followed the audits and lawsuits. Most of this legal strong arming is all under NDAs so don’t expect to find much but ask anyone who’d used Oracle, and balked at some terms, and found themselves under a JDK download audit.

The free version is available for non-commercial, personal and home use. We also encourage students and non-profit organizations to benefit from this offering.

Commercial organizations require commercial licenses to use Workstation Player.

And there is the trap.

Download at home, and away from work.

You’ve been warned.

Looking at UnixWare 7.1.1 on VMware & Qemu yet again!

Same old OS, same old problems.

My UnixWare 7.1.1 box

The UnixWare 7.1.1 install program has a date & time Y2k problem. And this always ends in whatever licensing you give it to install will expire and be nullified. Luckily this time while re-installing on VMware I saw if you defer the license on install, It’ll grant you a temporary eval license. It’s not going to matter as it’ll immediately expire, but it get’s us past the install.

Qemu however let’s you rev up the time machine and specify a starting time

-rtc base=1999-09-29T15:00:00

As simple as that. I found for installing with Qemu 8.0 (Latest win32) binary it worked well enough like this:

"c:\Program Files\qemu\qemu-system-x86_64.exe" ^
-m 1024 ^
-hda UnixWare711.vmdk ^
-cdrom SCO_UnixWare711.iso ^
-net nic,model=pcnet ^
-rtc base=2010-09-29T15:00:00

Installation in a stock boring VM goes fine, there is built in support for the AMD PCnet driver, so things ‘just work’. And then on the VMware reboot it never launches X11.

Starting Desktop works fine on Qemu

Under Qemu, I’m greeted by CDE and the login page. On VMware however…

Starting Desktop never starts

I know t his used to work on VMware, but there is some regression in the VESA video driver. The fix was to use scoadmin and knock the video settings down to stock VGA. Luckily I have an X server running on Windows, so I could just export the display and set it up.

Video Configuration on Qemu

Whereas I had to set VMware to VGA:

Video Configuration on VMware

And one more reboot, and I was at least given a graphical console:

Now able to login to VMware graphically

Inputting the licenses

Being a commercial Unix from back in the day, it relies on License Numbers, and activation codes to actually use the software. I have the box, so I have codes so yay me. Post install, I could remove the expired licenses, and then input the ones that were in the box.

These are 5 user licenses, just enough to show off the system, I suppose: The advanced features of the day are nothing special these days, but it’s nice to have the PCC derived compiler, if not to compile GCC but more so for SYSV code from back in the day.

Networking

Networking for VMware is straightforward, I use the NAT interface VMnet8 that is installed by default, selecting a valid Tcp/IP address on the interface range gives me not only full internet access, but also allows me to easily telnet into the VM.

Qemu however…

"c:\Program Files\qemu\qemu-system-x86_64.exe" ^
-m 1024 ^
-hda UnixWare711.vmdk ^
-net nic,model=pcnet ^
-net user,hostfwd=tcp::42323-:23

I had been using the user mode SLiRP code for ages, but after all the MIT PC/IP fun, I was thinking I bet modern Qemu supports UDP transport for network traffic, and that it’d just integrate with HecnetNT just fine. And it does!

"c:\Program Files\qemu\qemu-system-x86_64.exe" ^
-m 1024 ^
-hda UnixWare711.vmdk ^
-net nic,model=pcnet,netdev=hecnet ^
-netdev socket,id=hecnet,udp=127.0.0.1:5001,localaddr=127.0.0.1:5000

Configuring the HetnetNT bridge was simple, as always make sure you have Wireshark/pcapng installed and simply run ethlist to get the list of interfaces:

D:\qemu>ethlist.exe
Network devices:
  Number       NAME                                     (Description)
  0  \Device\NPF_{E79F6278-3E7E-4547-955A-2080A0473AD6} (Local Area Connection* 8)
  1  \Device\NPF_{1D960E08-2A3A-43F7-BAD6-21FCB466717B} (Local Area Connection* 7)
  2  \Device\NPF_{98053A85-B049-45A0-AC33-961E2C136FCA} (Local Area Connection* 6)
  3  \Device\NPF_{BFA868ED-E508-4436-B085-EC815C4C544C} (LoopBack)
  4  \Device\NPF_{C75EAF23-0FA3-433B-B271-9CB0F5EB92D0} (VMware Network Adapter VMnet8)
  5  \Device\NPF_{B615DE21-AEC3-4347-916C-332AC4A4DA70} (VMware Network Adapter VMnet1)
  6  \Device\NPF_{82E5A370-6D3D-40AD-A9D5-C4E0E0C50F0D} (Ethernet)

And then create a simple bridge.conf file with the VMnet8 adapter and the UDP pariing to talk to Qemu:

[bridge]
update 127.0.0.1:5000
vmnet8 \Device\NPF_{C75EAF23-0FA3-433B-B271-9CB0F5EB92D0}


[tcpip]
update
vmnet8

Then launch the bridge program listening on port 5001:

D:\qemu>hecnet.exe 5001
Config filename: bridge.conf
Adding router ''update''. 0100007f:5000
Opening pcap \Device\NPF_{C75EAF23-0FA3-433B-B271-9CB0F5EB92D0}
Adding router ''vmnet8''. 00000000:0
Host table:
0: update 127.0.0.1:5000 (Rx: 0 Tx: 0 (Drop rx: 0)) Active: 1 Throttle: 0(000)
1: vmnet8 0.0.0.0:0 (Rx: 0 Tx: 0 (Drop rx: 0)) Active: 1 Throttle: 0(000)
Hash of known destinations:
Adding new hash entry [52:54:00:12:34:56]. Port is 0
Adding new hash entry [00:50:56:c0:00:08]. Port is 1
Adding new hash entry [00:50:56:f1:dd:d0]. Port is 1
Adding new hash entry [00:0c:29:9a:2b:fb]. Port is 1

It’s a little bit more involved to setup as we have to link the 2 programs via UDP, but I can say it’s totally worth it.

“It just works!” – Sydney

I can now easily FTP files into Qemu, and of course telnet as much as I want to. I don’t see why NFS wouldn’t work either.

Which brings us to the bigger elephant in the room, which one is ‘worth the squeeze’?!

I thought it’d be fun to do a totally unfair CPU intensive thing like building GCC. I would do a quick stage 3 compile blindly running this:

./configure --host=i386-sysv4 --target=i386-sysv4 --prefix=/usr/local/gcc-2.5.8
make
make stage1
make CC="stage1/xgcc -Bstage1/" CFLAGS="-g -O"
make stage2
make CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O"
make stage3
make CC="stage3/xgcc -Bstage3/" CFLAGS="-g -O"

This way we can just look at the timestamps between completed releases. It does build C++ & ObjectiveC as well, and compared to machines from 1999 this is amazing!

-rwxr-xr-x 1 neozeed other 3495688 Mar 29 12:42 ./cc1
-rwxr-xr-x 1 neozeed other 2646888 Mar 29 12:37 ./stage1/cc1
-rwxr-xr-x 1 neozeed other 3495720 Mar 29 12:39 ./stage2/cc1
-rwxr-xr-x 1 neozeed other 3495688 Mar 29 12:40 ./stage3/cc1

Qemu timing

-rwxr-xr-x 1 neozeed other 3884076 Mar 28 20:12 ./cc1
-rwxr-xr-x 1 neozeed other 2647116 Mar 28 20:11 ./stage1/cc1
-rwxr-xr-x 1 neozeed other 3884124 Mar 28 20:11 ./stage2/cc1
-rwxr-xr-x 1 neozeed other 3884076 Mar 28 20:12 ./stage3/cc1

VMware timing

As you can see VMware is substantially faster when it comes to computation. This shouldn’t come to anyone as any surprise. And this isn’t a fair competition, but it does show that you can stage GCC on Qemu just fine, so that’s actually great!

Now let’s mix in some more nonsense, I have a Merge license so let’s try it! First off it really wants Windows 95 from CD-ROM. It will not accept anything else. I have a hacked-up copy of the floppy version of Windows 95 on CD-ROM, and it accepted that just fine, it appears to search through.CAB files looking for files to setup it’s preferred environment. I’m not all that familiar with the whole thing as PC’s are cheap, and virtual machines are even cheaper!

Merge setup on VMware

After the setup completed, I thought I’d try my Sarien 286/386 ports.

no DPMI for Merge

Sadly, neither worked. Maybe it’d have better luck with Windows 95 actually installed. I wanted some high colours so I went over to Qemu and found out that it cannot run Merge.

No Merge!

The error lies in a missing opcode 000000FF. Maybe it’s invalid to trigger an exception to call between DOS and the supervisor?

unknown opcode 000000FF

Either way it doesn’t matter, it doesn’t work. I did get feedback that it does run under KVM.

I don’t know why I didn’t think about doing the HecnetNT bridge earlier as it gives things far more flexibility for tapping into networks, or even being transported. I guess I should look at other transport mechanisms besides UDP since it’s 1:1. Also, it might be worth dropping the protocol restrictive filters to allow everything on the wire to flow.

Re-visiting an install of 386BSD 0.0

    I shall be telling this with a sigh
    Somewhere ages and ages hence:
    Two roads diverged in a wood,
            and I ---
    I took the one less traveled by,
    And that has made all the difference.
       "The Road Not Taken" [1916] -- Robert Frost

I didn’t want to make my last post exclusively focusing on 386BSD 0.0, but I thought the least I could do to honor Bill’s passing was to re-install 0.0 in 2022. As I mentioned his liberating Net/2 and giving it away for free for lowly 386/486 based users ushered in a massive shift in computer software where so called minicomputer software was now available for micro computer users. Granted 32bit micro computers, even in 1992 were very expensive, but they were not out of the reach of mere mortals. No longer did you have to share a VAX, you could run Emacs all by yourself! As with every great leap, the 0.0 is a bit rough around the edges, but with a bit of work it can be brought up to a running state, even in 2022.

But talking with my muse about legacies, and the impact of this release I thought I should at least go thru the motions, and re-do an installation, a documented one at that!

Stealing fire from the gods:

Although I had done this years ago, I was insanely light on details. From what I remember I did this on VMware, and I think it was fusion on OS X, then switching over to Bochs. To be fair it was over 11 years ago.

Anyways I’m going to use the VMware player (because I’m cheap), and just create a simple VM for MS-DOS that has 16MB of RAM, and a 100MB disk. Also because of weird issues I added 2 floppy drives, and a serial & parallel port opened up to named pipe servers so I can move data in & out during the install. This was really needed as the installation guide is ON the floppy, and not provided externally.

VMware disk geometry

One of the things about 386BSD 0.0 is that it’s more VAX than PC OS, so it doesn’t use partition tables. This also means geometry matters. So hitting F2 when the VM tries to boot, I found that VMware has given me the interesting geometry of 207 cylinders, 16 heads, and a density of 63 sectors/track. If you multiply 207*16*63 you get 208656 usable sectors, which will be important. Multiply that by 512 for bytes per sector you get a capacity of 106,831,872. Isn’t formatting disks like it’s the 1970s fun? Obviously if you attempt to follow along, obviously yours could be different.

Booting off install diskette

Throwing the install disk in the VM will boot it up to the prompt very quickly. So that’s nice. The bootloader is either not interactive at all, or modern machines are so fast, any timeout mechanism just doesn’t work.

As we are unceremonially dumped to a root prompt, it’s time to start the install! From the guide we first remount the floppy drive as read-write with the following:

mount -u /dev/fd0a /

Now for the fun part, we need to create an entry in the /etc/disktab to describe our disk, so we can label it. You can either type all this in, use the serial port, or just edit the Conner 3100 disk and turn it into this:

vmware100|VMWare Virtual 100MB IDE:\
:dt=ST506:ty=winchester:se#512:nt#16:ns#63:nc#207:sf: \
:pa#12144:oa#0:ta=4.2BSD:ba#4096:fa#512: \
:pb#12144:ob#12144:tb=swap: \
:pc#208656:oc#0: \
:ph#184368:oh#24288:th=4.2BSD:bh#4096:fh#512:

As you can see the big changes are the ‘dt’ or disk type line nt,ns and nc, which describe heads, density and cylinders. And how 16,63,207 came from the disk geometry from above. The ‘pa’,’pb’… entries describe partitions, and since they are at the start of the disk, nothing changes there since partitions are described in sectors. Partition C refrences the entire disk, so it’s set to the calculated 208656 sectors. Partition A+B is 24288, so 208,656-24,288 is 184,368 which then gives us the size of partition H. I can’t imagine what a stumbling block this would have been in 1992, as you really have to know your disks geometry. And of course you cannot share your disk with anything else, just like the VAX BSD installs.

With the disklabel defined, it’s now time to write it to the disk:

disklabel -r -w wd0 vmware100

And as suggested you should read it back to make sure it’s correct:

disklabel -r wd0
wd0 labeled as a custom VMware 100

Now we can format the partitions, and get ready to transfer the floppy disk to the hard disk. Basically it boils down to this:

newfs wd0a
newfs wd0h
bad144 wd0 -f
mount /dev/wd0a /mnt
mkdir /mnt/usr
mount /dev/wd0h /mnt/usr
(cd /;tar -cf - .)|(cd /mnt;tar -xvf -)
umount /mnt/usr
umount /mnt
fsck -y /dev/rwd0a
fsck -y /dev/rwd0h

Oddly enough the restore set also has files for the root, *however* it’s not complete, so you need to make sure to get files from the floppy, and again from the restore set.

One of the annoying things about this install is that VMware crashes trying to boot from the hard disk, so this is why we added 2 floppy drives to the install so we can transfer the install to the disk. Also it appears that there is some bug, or some other weird thing as the restore program wants to put everything into the ‘bin’ directory just adding all kinds of confusion, along with it not picking up end of volume correctly. So we have to do some creative work arounds.

So we mount the ‘h’ partition next as it’s the largest one and will have enough scratch space for our use:

mkdir /mnt/bin
mount /dev/wd0a /mnt/bin
mount /dev/wd0h /mnt/bin/usr
cd /mnt/bin/usr

Now is when we insert the 1st binary disk into the second floppy drive, and we are going to dump into a file called binset:

cat /dev/fd1 > binset

Once it’s done, you can insert the second disk, and now we are going to append the second disk to binset:

cat /dev/fd1 >> binset

You need to do this with disks 2-6.

I ran the ‘sync’ command a few times to make sure that binset is fully written out to the hard disk. Now we are going to use the temperamental ‘mr’ program to extract the binary install:

cd /mnt
mr 1440 /mnt/bin/usr/binset | tar -zxvf -

This will only take a few seconds, but I’d imagine even on a 486 with an IDE disk back then, this would take forever.

The system is now extracted! I just ran the following ‘house cleaning’ to make sure everything is fine:

cd /
umount /mnt/bin/usr
umount /mnt/bin
fsck -y /dev/rwd0a
fsck -y /dev/rwd0h

And there we go!

Now for actually booting up and using this, as I mentioned above, VMware will crash attempting to boot 386BSD. Maybe it’s the bootloader? Maybe it’s BIOS? I don’t know. However old versions of Qemu (I tested 0.9 & 0.10.5) will work.

With the system booted you should run the following to mount up all the disks:

fsck -p
mount -a
update
/etc/netstart

I just put this in a file called /start so I don’t have to type all that much over and over and over:

Booting from Hard Disk, under Qemu

On first boot there seems to be a lot of missing and broken stuff. The ‘which’ command doesn’t work, and I noticed all the accounting stuff is missing as well:

mkdir /var/run
mkdir /var/log
touch /var/run/utmp
touch /var/log/wtmp

Will at least get that back in action.

The source code is extracted in a similar fashion, it expects everything to be under a ‘src’ directory, so pretty much the same thing as the binary extract, just change ‘bin’ to ‘src’, and it’s pretty much done.

End thoughts

I think this wraps up the goal of getting this installed and booting. I didn’t want to update or change as little as possible to have that authentic 1992 experience, limitations and all. It’s not a perfect BSD distribution, but this had the impact of being not only free, but being available to the common person, no SPARC/MIPS workstations, or other obscure or specialized 68000 based machine, just the massively copied and commodity AT386. For a while when Linux was considered immature, BSD’s led the networking charge, and I don’t doubt that many got to that position because of that initial push made by Bill & Lynne with 386BSD.

Compressed with 7zip, along with my altered boot floppy with my VMware disk entry it’s 8.5MB compressed. Talk about tiny! For anyone interested here is my boot floppy and vmdk, which I run on early Qemu.

And there we go!

Manually migrating NT 4.0 on VMware ESX to Hyper-V or what is a ‘flat’ vmdk anyways?

So due to recent economic events I’m having to consolidate all my VM’s back to the office I’m currently renting. I had a fancy 1gig internet connection installed and I’m still under contract for a year. Before the c00f it made sense as I did a lot out of that office and was getting ready to do something fun and big. I had planned on making a cloud service, I’d bought a bunch of Xeon boards, and started the initial build of my cloud to shop around but then the world ended the following weekend. As they say, bad timing.

So as a fan of old junk I still have some NT 4.0 stuff, and it’d been running on VMware for years, no issues everything being great. But I need to do double+ duty at the moment and to make it easier than trying to get GPU passthru working, I’m just going with Hyper-V on the Windows 10 desktops that I have running. May as well make people doubly useful!

In some idea of ‘performance’ I had converted all the virtual disks to ‘flat’ VMDK’s and never thought twice about it as it worked, and all was well.

Naturally to start with I uninstall VMware Tools while running under ESXi and shut down the VMs.

Well after rsync‘ing my disks back, I converted them with qemu-img and got this weird error that my VMDK’s were not VMDK’s. They are infact FLAT disk images. With really screwed up geometry that prevented both qemu and Hyper-V from mounting the raw converted disk images.

So first let’s verify the data:

root@NT15:/mnt/d/virtual/USENET-AltaVista# sfdisk -d USENET-AltaVista-flat.vmdk
label: dos
label-id: 0x8058e639
device: USENET-AltaVista-flat.vmdk
unit: sectors

USENET-AltaVista-flat.vmdk1 : start=          63, size=     4096512, type=7, bootable

And sure enough yeah it’s like a typical DOS disk with the start 63 sectors in. So to mount this under Linux (WSLv2 too!) we need to tell the loop driver the offsets, which is the start and size * 512 or:

# mount -o loop,offset=32256,sizelimit=2097414144 USENET-AltaVista-flat.vmdk /mnt

And all is good. Yes even a type 7 for HPFS/NTFS it mounted find and the data is there.

Now the ‘fix’ was an old one from back in the day, when moving stuff around and things get goofed you can try to xcopy and permissions always get messed up or cheat, and just use another NT installation and format a floppy disk and copy the following system files to it:

  • ntldr
  • ntdetect.com
  • boot.ini

In my case that’s all I needed to do, I re-ran qemu-img to convert from raw to vpc disk images:

qemu-img convert -f raw -O vpc USENET-AltaVista-flat.vmdk USENET-AltaVista-flat.vhd

And setup Hyper-V to boot my virtual diskette first, and in no time my NT was back up and running.

Naturally be sure to install the legacy network adapter for the VM, and re-configure NT for the DECchip 21140 adapter.

DECchip 21140

Dont’ forget to re-run service pack 6, and the update. Since these disks & VMs were pre-installed I didn’t have to mess with the “CompatibilityForOlderOperatingSystemsEnabled” flag. Although that was quite the fun adventure at the time.

In my case there was some IP addresses to change, but it’s back online with minimal effort which is always fine. Hyper-V doesn’t have any real integration stuff for old Windows so it’s pretty much a set it an forget it thing, or use Terminal Server for remote access.

So yes, many of the hosted things I have are down. I know. Yes it sucks. And yes I think the disk I put this on at the moment kind of sucks too. It’s been super cold here lately and I didn’t want to be exposed out there riding around getting soaked in the high winds so I’ll keep shuffling stuff later. But for now I got to save some hosting fees. And things like the gopher are dead. for the moment.

Running VMWare ESXi on Raspberry PI

(This is a guest post by Antoni Sawicki aka Tenox)

Just for fun with virtualization I wanted to try out VMWare ESXi for ARM64, most specifically Raspberry PI. ESXi for ARM has been around for a couple of years now. Since PI4 packs 8GB of RAM and has a reasonably fast CPU it can be a worthwhile experience. Also more OSes for Raspberry PI are now available in UEFI boot mode.

Not going to go through exact installation steps as these are all around the web and youtube. Just to summary you will need to download an image from VMWare website as well as bunch of UEFI firmware files from github and combine it all together on to a SD card. When you boot it you will go through an install process which is straightforward. You can overwrite install media and use it as the target so no need for multiple SD cards. Once it boots you will see familiar ESXi boot screen:

ESXi booting on Raspberry PI 4

In order to get it going you will obviously need to add some storage. You can use NFS, iSCSI or locally attached USB drive. For the latest you need to disable USB arbitrator.

# /etc/init.d/usbarbitrator stop
# chkconfig usbarbitrator off

What can it run?

ESXi ARM only officially supports only UEFI boot based OSes. Fortunately this is a default option for Ubuntu PI, Free/Net/OpenBSD also work and so does Windows. But what about OSes that use U-Boot? Since ESXi-ARM Fling 1.1 you can boot oses in a “direct” mode with no UEFI! This is a huge step, but unfortunately as of today it doesn’t support UEFI-less VGA, only a serial port. Hopefully this can be fixed in future. I would love to have a RISC OS and/or Plan 9 VM. On the other hand Plan 9 supports EFI boot so an image could be made.

Windows guest install was also much easier than I expected. Thanks to UUP dump you basically roll your own bootable ISO. I think it’s actually easier to get it going on ESXi than natively on RPI hardware or QEMU.

Windows 10 Guest VM on ESXi Fling Raspberry PI

NIC driver obviously did not work by default, but there is a VMXNET3 ARM64 driver in the wild:

VMXNET3 for Windows 10 ARM64 on ESXi Fling on Raspberry PI

What is it good for?

Right now probably just for fun. But I can easily see datacenters filled in with ARM servers running ESXi. Future is bright and free of Intel! Personally I will keep it around for development purposes if I need to make builds for ARM on various OSes.

Interestingly enough you can even run VMWare ESXi ARM on QEMU with nested virtualization!

Also this is the official VMWare ESXi ARM Blog worth checking for future updates.

Upgrading to WSL2

I finally got the update to version 2004 of Windows 10 (OS Build 19041.329) which now includes support for running a Linux kernel inside a VM, using paravirtual drivers letting it hook into Windows 10. It reminds me of WinOS/2 where, OS/2 would run Windows 3.1 in a virtual machine, but using special drivers it could redirect it on the native filesystem, and paint the windows on the OS/2 desktop.

So the first thing is make sure you have 2004, winver should look like this:

You will need to go to the old control panel, and enable the Virtual Machine Platform. For those of you using VMware, you’ll need at least version 15.5.5 (15.5.6 is current as of the time of me writing this). I’d suggest you do that before turning on this, but some people like to live dangerously. Also fully shut down all your VM’s otherwise things will end up giving you errors (as you’ll see later).

After the Virtual Machine Platform is installed, your machine will need to reboot. After a reboot, you’ll need to download the Linux Update to the system, available at:

https://aka.ms/wsl2-install

It’s a simple install, and only takes a few seconds. I didn’t have to reboot.

now for the fun parts, you’ll need to list and shut down (terminate) your running WSL’s if you have any running.

C:\Users\neozeed>wsl --list --verbose
NAME STATE VERSION
Debian Running 1

As you can see I only have one, and it’s called Debian, and it is currently running something. Let’s kill it!

C:\Users\neozeed>wsl -t Debian
C:\Users\neozeed>wsl --list --verbose
NAME STATE VERSION
Debian Stopped 1

And now it’s stopped. The command to upgrade is pretty simple:

C:\Users\neozeed>wsl --set-version Debian 2
Conversion in progress, this may take a few minutes…
For information on key differences with WSL 2 please visit https://aka.ms/wsl2

And yes, you can also stop the WSL instance, and move it back to version 1, if you find 2 not doing what you want. However on first impressions, WSL2 is significantly faster.

If you are running VMware, and you didn’t shut down your VM’s you’ll get this lovely message when you try to resume:

The save state will be deleted, but rest assured it’ll launch okay (at least mine did!)

10.6 the last great OS X

One sad consequence of using the Microsoft Virtual Machine framework is that nesting is no longer available.

which is kind of a bummer, as that was the killer feature.

VMware 12.5.9 on Windows 10 build 1903 / version 18362

So while I’m in Japan, I bought this tiny and borderline useless Fujitsu Esprimo B532, powered by an i5, and not very much else. I upped it to 8GB of RAM, and put in a SSD and upgraded to Windows 10 to make it slightly tolerable.

i5-3470T

The i5-3470T is ancient! And so old that newer versions of VMware and Hyper-V won’t run on it. The old solution was simply to use an older version of VMware. In my case the highest version that’ll run is 12.5.9, however when trying to launch it I got this fun message:

VMware Workstation Pro can’t run on Windows!

Well wasn’t that a big bust.

I guess there is something hidden somewhere, but I just renamed the executable, and set it to Windows 8.0 compatibility mode, and wow it works!

Windows NT 3.1 October 1991 pre-release

And there we go! Now the latest version of NT can run the first public pre-release of Windows NT. YAY.

Running VMware ESX Server 2.5

One of my favorite things about VMware is that it can run itself.  This allows me to test & stage new setups, test API stuff on my desktop, allowing me to build a “micro data center” that I don’t need to ask & beg for permission to take down, or if I do something stupid, I’m just a quick revert away from putting it back, and more importantly not making other people mad.

This also let’s me step back in time, in this case to the dark & ancient world of 2005, where I’d first deployed VMware ESX 2.5.2 along with vCenter 1.3.1 .  I figured that I could use my ancient Dell P490, as I’d been using it as a desktop at home for casual use, but this seemed like a good thing to stress the system on.  Also handy to have is the installation guide, which VMware still has online.

I installed Windows 10 Pro, and VMware Player 12.5.9, The box has a single physical processor that is dual core, 8GB of RAM and a 1TB disk.  Not exactly a high end machine, but it’ll suffice.

The first thing to do was install ESX 2.5.2, I’d set it up as a Linux VM, with 1 CPU, 2GB of RAM, and 3 disks, one for the OS, another for SWAP, and a Data store / Data disk.

After the nice GUI setup is completed we are dumped to a console on reboot.  ESX is meant to be managed remotely.

Once the OS installed, edit the VMX file, and make the following changes, to allow VMware to setup the passthrough capabilities so the VM can run other VMs.

guestOS = “vmkernel”
monitor_control.vt32 = “TRUE”
monitor_control.restrict_backdoor = “TRUE”

Now the Version will report that it’s VMware ESX.  The other thing you’ll find out quickly is that you need a browser to manage the server (funny how things went back to this direction, later versions relied entirely on the ‘fat’ .NET client), and I found that FireFox 1.5 works the best.

The .NET client requires .NET 1.1 to operate correctly.  It will not install on Windows 10 by default, as the .NET 3.5 (which includes .NET 2.0 runtime) is not acceptable, it has to be the 1.1 runtime, along with the J# runtime, which it’ll install if needed.  I went through the installation steps in the aptly name ‘Installing .NET 1.1 on Windows 10‘. post.

Of course you’ll need a place to run the vCenter server, I just setup a Windows 2000 server, installed SQL 2000, .NET v1.0 & v1.1 and then the Virtual Center component.  VirtualCenter relies on a database backend, and I thought it’d be interesting to look at the tables through MSSQL, although Oracle, Access and some generic ODBC are also options for this ancient version of VirtualCenter.

For those who don’t know, VirtualCenter is the application that lets you build a ‘virtual datacenter’ join multiple ESX servers together, and more importantly orchestrate them together into a cluster, allowing you to vMotion VMs between servers,  which of course is the ‘killer feature’ of VMware ESX.  If you don’t have vCenter / VirtualCenter then you are missing out on so much of the products capabilities, which is sadly hidden away.

I setup a tiny Windows NT 4.0 domain, with a domain controller, and a terminal server.  My host machine is a bit weak to setup more ESX hosts, as there just isn’t enough punch in the box.  Although any modern machine will probably exhaust RAM before CPU running a mid 90’s workload.

Back in the day, I had moved our entire DC onto 4 ‘killer’ machines with fiber channel storage and had consolidated the entire DC to a single cabinet.  It was incredible that we were initially able to almost meet existing performance.  Of course the killer feature again is vMotion so a year later, I only needed 4 new servers which was an easy budget ask, and in the middle of the day I vmotioned from the old servers into the new servers, and things across the board were now faster.  Finally the bean counters saw the light that we didn’t have to buy faster gear for a single group, or that we no longer had the issues where we had ‘important enough’ to be in the data center but with no hardware maintenance, or proper backups.  Now everyone is on equal footing and all the boats raised with the tide so to speak.

In this quick re-visitation it would be fun to setup shared storage, multiple hosts and vMotion, but back in the days of ESX 2.5 there was no support for having VMFS over NFS or iSCSI.  As much as I’d love to use the Dr Dobbs iSCSI Target Emulator, it just sadly isn’t an option.  The ability to move beyond Fiber Channel shared storage (or other supported dedicated host bus adapters) was added in version 3, greatly expanding the capabilities of ESX.

 Obviously the career mistake here was to be a happy Admin, and concentrate on other things as now the infrastructure ‘just worked’ and it freed up an extraordinary amount of time.  The smarter people were either taking these types of experiences and turning it into a consultation gig (low effort) , or taking lessons learned in VMware space, and focusing them onto QEMU/KVM and building libre infrastructure (high effort).

Such is life, be careful riding those trendy waves, eventually you have to either lead, follow or just get out of the way.

Installing .NET 1.1 on Windows 10

VirtualCenter client 1.3 needs .NET v1.1!

Yes, I know this is crazy but… I don’t know if anyone else would care.  Windows 10 (7 & 8 as well, I guess…) include a .NET 2.0 option or a 3.5 which includes 2.0 install but if you need the first real ‘release’ version of .NET v1.1 you cannot install it.  And some applications were pretty much hard coded to 1.1, even though the whole point of .NET was to avoid this kind of version/DLL hell.

.NET 1.1 setup  From here it’s all failure.

Well I had come across this great post here on techjourney.net.  And yes it sounds crazy but it works!

All you need to do is download the version 1.1 framework + SP 1, and slipstream the SP 1 patch into the directory and run the setup..

  • dotnetfx.exe /c:”msiexec.exe /a netfx.msi TARGETDIR=C:\DotNet”
  • dotnetfxsp1.exe /Xp:C:\DotNet\netfxsp.msp
  • Run netfx.msi that was created in C:\DotNet\

I’ve gone ahead and combined the .NET v1.1 framework + SP1 into this zip file: dotnet1.1-withsp1.zip, so you can bypass those steps, and just go.  No more bizare errors about the debugger not finding itself and crashing out the installer.

VMware VirtualCenter on Windows 10

And now I can manage my nested VMware ESX 2.5.2 cluster on Windows 10 natively as managing from a VM just wasn’t the great experience I’d been hoping for.

VMware Player and Device/Credential Guard are not compatible!

What is this?!

Well it turns out that by turning on all the SDK stuff for Windows 10, including the mobile dev, which includes the Windows phone emulator it naturally uses Hyper-V.

Hyper-V Hypervisor enabled

And obviously the two hypervisor’s wont play nice with each-other.  You could just disable it, and go back and forth re-enabling it when needed, or make a new boot selection without it!

I found this post here: Switch Easily Between VirtualBox And Hyper-V WithA BCD Edit Boot Entry In Windows 8.1

C:\> bcdedit /copy {current} /d "No Hyper-V" 
The entry was successfully copied to {ff-23-113-824e-5c5144ea}. 

C:\> bcdedit /set {ff-23-113-824e-5c5144ea} hypervisorlaunchtype off 
The operation completed successfully.

note: The ID generated from the first command is what you use in the second one. Don’t just run it verbatim.

When you restart, you’ll then just see a menu with two options…

  • Windows 10
  • No Hyper-V

Sounds easy enough, doesn’t it?

BCD Boot menu

And just like that on power up, I can switch between Hyper-v and no Hyper-V.

Oh yeah with the latest version of Windows 10 (October 2018) I had to list the BCD table with:

bcdedit /enum ACTIVE /v

As after the upgrade it had tagged both of my boot selections to enable Hyper-V everywhere. I had to delete the #2 entry and re-create the no hyperv dance. {current} doesn’t work anymore.