VIRTUALIZATION MYTHS for Oracle: Migrating Physical to VM and Why Your Licensing Math is Broken

A system (this is for Oracle Products, Oracle Database especially) running happily on a dedicated physical machine needs to be migrated to a virtual environment. Simple, right? The technical migration is the easy part. The licensing, the support, the certification? That’s where the confusion, and the cost, begins.  

The Migration Team's Optimism is usually on the having the same licensing cost in the target VM environments. So at first glance; they say the licensing (related with the Oracle Licenses) cost should remain the same. The flexibility will increase, the cost stays flat. This is also the goal, actually.

But what I say is ; you are optimizing for flexibility while ignoring the fine print. Oracle’s licensing is not based on what the VM is limited to, but on what the VM is capable of accessing.

If you are using VMware, Microsoft Hyper-V, or any non-Oracle virtualization platform that does not employ "hard partitioning" (and they typically do not by default, or lets say Oracle doesn't accept their partitioning capability as hard partitioning), your licensing burden is likely to increase dramatically. You are forced to license the entire underlying physical capacity of the host cluster that the VM can potentially migrate to.

Think about it: Your small, 8-vCPU VM is sitting on a cluster with four physical hosts, each having 32 cores. The total physical core count is 4 X 32 = 128 cores. Apply the standard Oracle core factor (say, 0.5 for Intel/AMD). You might suddenly be on the hook for 128 X 0.5 = 64 licenses, not the 8 you planned for.

The cost savings you anticipated from virtualization are instantly wiped out. Isolation is the key, and non-Oracle VM solutions struggle to provide the licensing-level isolation we need.

The Oracle Solution

This is where Oracle developed solutions come into play. Oracle VM (OVM) or Oracle Linux /KVM. These platforms are explicitly designed to support hard partitioning. With KVM's CPU pinning, for example, you can logically and technically restrict a VM to a subset of the physical cores, and Oracle accepts this as the boundary for licensing.

You may say: we already invested heavily in VMware infrastructure! We can't switch now.

I Say; that is a classic case of operational convenience trumping financial risk. 

Is the cost of maintaining the VMware environment worth the exponential risk of an Oracle audit that demands licensing for the entire cluster?  This is a question that you have to ask to yourselves.

For large environments, the license cost penalty of non-Oracle virtualization can easily justify the expense of migrating to an Oracle-sanctioned hard-partitioned platform. 

The technical solution is easy; the financial one requires difficult choices.

Respect the licensing rulebook. It is often more complex, and more expensive, than the technical architecture.

That’s enough for today. Check your contracts before you virtualize.

EBS / CPU PATCHES STRIKE AGAIN: The Forms FRM-92101 Error and the Hidden URL Rewriting Trick - disabled URL rewriting

You care about system security/ You apply the Critical Patch Updates (CPU), you run the adop cycles, and the logs all shout "Success." Then you try to open a standard Oracle E-Business Suite (EBS) form, and BAM: FRM-92101. The system is shouting at you, and your users are waiting.

A recent case on my forum perfectly illustrates this predictable chaos. The user did all the right things—applied multiple AD/TXK updates, patched the database tier, and rolled through the full stack of CPU and other CVEs. Yet, the system broke.

Forms session <12> aborted: runtime process failed during startup with errors Unable to switch to Working Directory: <path>/fs1/FMW_Home/Oracle_EBS-app1/forms

The DBA's Initial Reflex in these situation is "I applied patches. Now I get FRM-92101: Unable to switch to Working Directory." This is usually a fundamental filesystem or configuration issue. Wrong path, wrong permissions, or the active FS is missing files. I ran adadmin, I checked the basic Oracle Docs. 

But! We weren't here to guess. If the Forms Server fails, we needed check the foundation. I needed the necessary outputs, I needed confirmation the pre- and post-patching actions were actually successful (not just that the adop phase finished).  In EBS 12.2, we neededed to check both filesystems (FS1 and FS2). 

1) So don't you have <FMW_HOME>/Oracle_EBS-app1 directory and <FMW_HOME>/Oracle_EBS-app1/forms directory on PROD?

2)What about TEST, do you have "<FMW_HOME>/Oracle_EBS-app1/forms" ?

3)both on PROD and TEST do the following and send me the following command outputs;

cd to <FMW_HOME>/Oracle_EBS-app1;
run pwd command
run ls -al command
then cd to forms
run pwd command
run ls -al command

4)Did you successfully applied the patches? Successfully executed the pre and post actions of the patches? Are you checked and sure for that? What document you follow / and actions you take? any missing thing there?

5)* Also check you have that forms directory on both of the fs(s) - fs1 and fs2. Maybe your active filesystem doesn't have that directory, but it is available in patch directory. Check that as well.. If so, we may take actions accordingly.
what is your run fs , and what is your patch fs ? state that as well and check accordingly. 

While going forward with this issue, my follower performed a rollback and re-applied the patch(es), and then the error disappeared. But! this time, a new error appeared. "FRM-92101". Although followed the MOS Doc: "Getting FRM-92102 Errors when Accessing a Forms Module on a Cloned Environment (Doc ID 2237225.1)", nothing changed, the issue persisted.

->
So, as far as I see, you reapply the patch(es), got errors, and fixed them and made the patching process /or scripts made continue from where they left off. You say you applied the patches successfully then..
So your final error is FRM-92101, but this time it is for failure in forms server during startup.

Check ->

E-Business Suite 12.2 Forms Error 'FRM-92101' Connection from new browser window not supported if using custom jars not added in userjarfile (Doc ID 2142147.1)
R12.2 FRM-92101 Error When Opening Multiple Forms in Separate IE11 Browser (Doc ID 2109411.1)
FRM-92101 There Was A Failure In The Forms Server During Startup (Doc ID 2594880.1)
FRM-92101:There Was A Failure In The Forms Server During Startup.This Could Happen Due To Invalid Configuration When Opening Forms (Doc ID 1931394.1

Check the following notes carefully, consider implementing the appropriate one(s) and update me with the outcome.

Anyways; the real root cause wasn't the Forms Server configuration. It wasn't the filesystem.
It was the very security patch intended to help:  the CPU (and subsequent patches).

The issue was the patch introduced code that disabled URL rewriting. This is a subtle, almost silent change, but it breaks the fundamental way the application handles Forms sessions, especially when using Remote Desktop Protocol (RDP).

The solution was a single workaround from Oracle: Re-enable URL rewriting. 

This critical piece of information was buried in an appendix of the CPU Availability Document (Doc ID 3090429.1). 

The Oracle E-Business Suite Release 12.2 April 2025 CPU introduced code that disabled URL rewriting which may result in FRM-92102 or FRM-92101 errors if you are using remote desktop protocol (RDP). Use the following steps to enable URL rewriting as a workaround until a more permanent solution is available. -> You must dig to find the actual fix.

The Lesson: When security updates are applied, the side effects are often more brutal than the initial vulnerability. You fix one hole and create two new compliance/functional nightmares. Respect the process, check the full stack, and know that sometimes the root cause is a single, seemingly minor change introduced by the very patch you thought was the solution.

That’s enough for today. The details matter.