Seamless OpenVMS Migration to Oracle Cloud

A European company managing a large-scale insurance processing application, used by millions of customers, had only one remaining on-premises server: an x86 OpenVMS node. Their system was migrated to OCI in parallel with the on-prem node, switching to a royalty-free hypervisor as part of the process.

One of our customers was transitioning from a cloud-first to a cloud-only organization, making the migration of their on-premise x86 OpenVMS processing system essential to fulfill their CIO’s vision. With VSI’s support, their OpenVMS system was duplicated in the cloud using provided backup sets. During this process, we also switched from ESXi to KVM to eliminate licensing costs. KVM was deployed in Oracle Linux 9 to ensure long-term OpenVMS support for the host.

VSI planned, implemented, and documented the solution, covering everything from host setup to guest backup restoration and iterative performance and cost optimizations. As this was our first cloud migration project, much of the work involved designing a theoretical solution and adapting it based on bottlenecks and challenges encountered during deployment. Additionally, although not required by the customer, VSI developed a comprehensive set of scripts and tools for both the Linux host and the OpenVMS guest. These scripts were designed not only to automate and simplify system installation and maintenance but also to minimize human errors and to audit all changes made during the installation process. The project began under a Partial Management model but evolved into a Basic Control approach as we tailored engagement to the customer’s needs and transferred knowledge to their technical team.

What technical problems did that raise?

Network configuration issues – The small size of the system, driven by the need to minimize recurring costs, limited the number of available Virtual Network Interface Cards (VNICs) to 2. The primary VNIC was exclusive for host connections, while the secondary was reserved for the guest. Although both VNICs had private and public fixed IP addresses, cloud restrictions allowed only the primary VNIC to obtain an IP lease via DHCP, requiring manual configuration for the secondary. Other constraints in cloud network packet filtering meant that DECNET phase IV routing addressing for routing must be always disabled at all times in the guest.
Hard disk transfer performance – Hard disk transfer performance was initially set to default values. Since the selected cloud instance had fewer than 16 CPU cores, non-bootable storage block devices were severely limited in speed (under 40MBps). As a result, the host’s boot device had to be used for guest virtualized disk storage because that could be significantly optimized for throughput and I/O operations. We took full advantage of this, manually tuning performance at each stage of the project to balance cost efficiency with disk transfer speed.
Thick provisioning issues – Following VSI’s recommendations, OpenVMS was configured to use thick-provisioned (pre-allocated) storage for both system and application disks from the start. During the project, an increase in the guest's thick-provisioned disk size was required. This was achieved by increasing the size of the boot disk on the host, allowing both disks to be resized without reinstallation or reformatting (expansion on-the-fly). However, an unexpected issue arose: due to the tool used for disk expansion, each manual resize inadvertently converted guest disks from thick to thin provisioning, without any explicit request for this demotion. This issue only became apparent when the disks ran out of space as the customer benchmarked the storage system. Upon investigation, we identified the cause and resolved it by explicitly converting thin-provisioned disks back to thick provisioning after each expansion.
Host unprivileged but guest-privileged console access – Initially, the system was set up with a host user capable of privilege escalation (root/superuser). However, after further discussions and hands-on evaluation with the customer, maintaining a privileged sudoer account on the host was deemed unnecessary, while ensuring such privileges for the guest was essential — particularly full access to the guest’s boot console. To achieve this, we modified file and directory permissions on the host, allowing an unprivileged host user to interact with the guest’s boot console. While a full guest reinstallation could have been a simpler alternative, we opted for an on-the-fly reconfiguration to explore a solution that might be applicable in future scenarios where reinstallation would not be an option.

What are the benefits

At the handover date, the customer had a fully operational, cloud-based, verbatim copy of their on-prem OpenVMS system. This environment was designed for performance testing and benchmarking ahead of the official shutdown of the on-prem original, all while maintaining a monthly recurring cost of under three digits (USD).