The new Community X86 VMDK - thoughts on future ease

[mjvms27]

I'm relieved to report that after receiving my vmdk access, setting up a Virtual Machine in VMware workstation went smoothly. I was able to copy the serial port bits from the previous vmx file to the new VM's vmx file by text editor, in particular, the following in my case:

Code: Select all

serial0.present = "TRUE"
serial0.fileType = "network"
serial0.fileName = "telnet://127.0.0.1:1025"

I had, fortunately, used a 2nd Virtual Disk dka100: for all the compiling and hobby porting work that I had been doing under the prior Community approach. I was able to just make a copy of that Virtual Disk and add it to the new virtual machine, again just by editing the vmx file prior to starting up the Virtual Machine. I just had to do the IP configuration after that.

Here's some random thoughts on making the process as simple as possible for myself going forward...

Do continue to use a separate Virtual Disk for my own hobby/community work. You can just attach it, or a copy of it to a new Virtual Machine in the future.

Instead of putting my sylogin.com entries directly in sys$login:sylogin.com, I've decided to put in a single line:
@dka100:[startup]sylogin.com
and I keep the meat of my customization in dka100:[startup]sylogin.com, just to save a few minutes of editing and the need to keep copies of the sy$login file someplace else. The same could be done for systartup_vms.com, I suppose, although that is only a couple of lines in my case, and I do save a reference copy of that on my second (dka100:) disk that floats to the new VM.

With the hypervisors and Virtual Machines for hobby work, I'm finding it sufficient to just back the entire Virtual Machine up occasionally at the host-level, and I can take snapshots of the VM before making any potentially risky changes. That's so much nicer than bare metal approaches in the event that you want or need to back out a change after an unintended result! I'm not doing any OpenVMS-level backups for hobby work anymore.

At this point

Some potential concerns that I have:

Will I really have to wait up to a full year for a new VMDK if I encounter a show-stopping bug, and by show-stopping, I mean something that is preventing my hobby work from continuing, such as a compiler glitch or something?

[mjvms27]

Something I forgot to do: with the replacement vmdk approach, account quotas (and accounts) are back to the baseline, so having a dump of the accounts and their quotas from the original machine onto the secondary disk is a good idea too.

Is there a utility that will dump those into a format that can be used to automatically/easily recreate them on the new vmdk system disk?

[craigberry]

Something I forgot to do: with the replacement vmdk approach, account quotas (and accounts) are back to the baseline, so having a dump of the accounts and their quotas from the original machine onto the secondary disk is a good idea too.

Is there a utility that will dump those into a format that can be used to automatically/easily recreate them on the new vmdk system disk?

There is no built-in way of doing that. Everyone has their own method based on knowledge of where the relevant data live. There was a discussion of some of the options here: viewtopic.php?f=37&t=8958&p=20373.