The new Community X86 VMDK - thoughts on future ease
Posted: Wed Apr 03, 2024 10:37 am
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:
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?
Code: Select all
serial0.present = "TRUE"
serial0.fileType = "network"
serial0.fileName = "telnet://127.0.0.1:1025"
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?