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.

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.