And of course you’ll need your Broadcom ID. I did convert mine over in the migration as I had been buying Fusion for MacOS, well until they stopped supporting the 2013 Mac Pro.
And, as to be expected everything is gone. I am pretty sure I’d also registered all the freebie ESXi in there as well. So yeah, all gone.
Well not to fear, as when they had announced that they were going to give Pro away, I downloaded a copy to save the name, VMware-workstation-17.5.2-23775571.exe, and a quick search on that gave me this fun tree:
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.
Commercial organizations require commercial licenses to use Workstation Player.
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:
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.
Under Qemu, I’m greeted by CDE and the login page. On VMware however…
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.
Whereas I had to set VMware to VGA:
And one more reboot, and I was at least given a graphical console:
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.
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!
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:
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.
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!
After the setup completed, I thought I’d try my Sarien 286/386 ports.
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.
The error lies in a missing opcode 000000FF. Maybe it’s invalid to trigger an exception to call between DOS and the supervisor?
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.
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.
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.
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:
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
Now we can format the partitions, and get ready to transfer the floppy disk to the hard disk. Basically it boils down to this:
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:
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:
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:
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.
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.
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.
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.
(This is a guest post by Antoni Sawicki aka Tenox)
Just for fun with virtualization I wanted to try out VMWare ESXiforARM64, 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:
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.
NIC driver obviously did not work by default, but there is a VMXNET3 ARM64 driver in the wild:
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.
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:
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!)
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.
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.
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:
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!
And there we go! Now the latest version of NT can run the first public pre-release of Windows NT. YAY.
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.
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.
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.
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..
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 bizarre errors about the debugger not finding itself and crashing out the installer.
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.