Oracle Licensing for Virtualized Environments

Oracle Licensing for Virtualized Environments

Oracle Licensing in Virtual Environments

• Oracle licensing in virtualized environments carries hidden financial risks for CIOs.
• “Soft partitioning” (e.g., VMware/Hyper‑V) requires licensing entire physical servers or clusters.
• “Hard partitioning” (e.g., Oracle VM, IBM LPAR) allows for licensing a subset of cores, thereby reducing costs.
• Audits often reveal compliance gaps in VMware, making proactive strategies vital.
• Actionable steps (isolation, proper configs, contracts) can mitigate multi-million-dollar exposures.

Oracle’s Partitioning Policy: Soft vs. Hard Partitioning

Oracle’s partitioning policy defines how different virtualization methods impact licensing. Soft partitioning refers to flexible, software-based virtualization setups that Oracle does not accept as a means of limiting license scope.

In these cases, you must license the entire physical server or cluster where Oracle software runs, regardless of how many virtual CPUs you assign to Oracle.

By contrast, hard partitioning utilizes fixed hardware or Oracle-approved configurations to restrict Oracle to specific cores or partitions, enabling you to license only the designated resources.

To illustrate the difference:

In practice, soft partitioning is more flexible for IT operations, but it can be costly for licensing.

Oracle considers every CPU core that could potentially run Oracle as requiring a license. Hard partitioning is more rigid (resources are intentionally constrained), but it’s an approved way to pay only for what you use.

Oracle’s Stance on Popular Virtualization Platforms

Oracle’s licensing stance varies across virtualization platforms. Below is a summary of how key platforms are treated:

• VMware vSphere (ESXi): Oracle classifies VMware as a soft partitioning solution. If any Oracle software runs on a VMware cluster, Oracle’s policy is that all physical cores in all hosts of that cluster must be fully licensed, even if the Oracle workload runs on just one VM. In newer vSphere versions, Oracle auditors have taken it a step further, sometimes asserting that all clusters under the same vCenter (where VM migration is possible) should be licensed. This aggressive stance means that a single Oracle VM in a large VMware farm can trigger licensing requirements for dozens or hundreds of cores—a massive financial risk.
• Microsoft Hyper-V: Hyper-V is also referred to as soft partitioning. Oracle requires licensing every physical core of each host (or cluster) where an Oracle VM resides. Similar to VMware, using Hyper-V for Oracle can eliminate any licensing savings from virtualization unless the Oracle VMs are kept on a dedicated, isolated Hyper-V server or cluster.
• Oracle VM (OVM): Oracle’s hypervisor is treated as hard partitioning if configured properly. By using OVM’s CPU pinning or “capping” features, you can restrict an Oracle VM to a fixed number of physical cores. Oracle recognizes this and allows licensing only those pinned cores. For example, on a server with 16 cores, if an Oracle VM is hard-pinned to 4 cores, you only need licenses for those 4 cores, not all 16. (If OVM is used without such hard partitioning settings, it would default to a soft partition scenario, so proper configuration is crucial.)
• IBM LPAR (PowerVM on IBM Power Systems): IBM’s Logical Partitioning (LPAR) technology is considered hard partitioning when using capped partitions. Oracle permits sub-capacity licensing on IBM Power servers if the LPAR is defined with a fixed number of CPU cores for Oracle. For instance, an IBM Power server might have 16 cores, but if an Oracle database is confined to an LPAR with four cores, you can license just those 4. The LPAR mustn’t be an “uncapped” or elastic partition; dynamic resource sharing could invalidate the sub-capacity allowance in Oracle’s view.
• Kernel-based Virtual Machine (KVM): Oracle treats KVM (and similar open-source hypervisors, such as Xen or Red Hat Virtualization), as soft partitioning. This means an Oracle deployment on a KVM host requires licensing all cores of that host (or cluster, if KVM hosts are pooled for live migration). The flexibility of moving VMs or dynamically allocating CPU in KVM does not limit license obligations in Oracle’s eyes.
• Other Virtual Platforms: Generally, any virtualization that does not physically segregate hardware is treated as soft partitioning. For example, Oracle does not recognize Docker containers or Linux cgroups as boundaries – the underlying server must be fully licensed if Oracle runs in a container. On the other hand, certain vendor-specific hard partitioning technologies are accepted. Oracle Solaris Zones can be challenging to partition if you use “capped zones” (which limit Oracle to specific cores). Legacy UNIX partitioning, like HP nPar/vPar and Fujitsu PPAR, is also recognized as a hard partition. Always consult Oracle’s official partitioning policy for the definitive list of approved methods, and assume anything not explicitly listed is not a valid way to reduce license counts.

Common Audit and Compliance Risks by Platform

Each virtualization platform carries unique audit risks when running Oracle software. CIOs should be aware of the typical pitfalls:

• VMware vSphere: Oracle audits frequently find VMware environments out of compliance. A common scenario: an Oracle database was set up on a VM in a VMware cluster, perhaps as a test or small workload, but Oracle later claims the entire cluster (all hosts) needed licensing. If vMotion or DRS (dynamic scheduling) was enabled, Oracle will argue that any host the VM could run on must be licensed – even if it never actually moved. Some audits have even stretched this to all clusters managed by the same vCenter Server, due to VMware’s enhanced VM mobility features. This can turn a single instance deployment into an unexpected licensing of potentially hundreds of CPU cores. The financial exposure can be millions of dollars if not proactively contained.
• Microsoft Hyper-V: Similar to VMware, if Oracle is installed on any VM in a Hyper-V cluster, Oracle’s position is to license all physical cores in that cluster. Many organizations mistakenly assume that a small VM (e.g., four vCPUs) on a big Hyper-V host only needs a few licenses. In an audit, Oracle will insist that the entire host’s capacity is what counts. A Hyper-V deployment can lead to compliance issues and large back-license fees without careful isolation (such as dedicating specific hosts to Oracle workloads).
• Oracle VM (OVM): While OVM offers a path to legitimate sub-capacity licensing, it also requires careful compliance management. The risk here is misconfiguration – if an Oracle VM is not properly pinned to a set number of cores, Oracle may treat it as if it could use all server cores. Documenting OVM configurations (OVM server pools, CPU pinning settings) is critical to demonstrate that Oracle workloads were constrained. During audits, Oracle LMS (License Management Services) might request logs or configs to verify that only the intended cores were ever used by Oracle. If using OVM, also be aware of any potential changes – for example, an administrator increasing a VM’s vCPU count without adjusting the licensing could create a shortfall.
• IBM LPAR: Oracle on IBM Power systems is often in banking and large enterprise environments. Oracle will allow sub-capacity licensing on Power LPARs only if they are static. The audit risk arises if an LPAR is set to uncapped mode (allowing it to consume extra CPU from a pool) or if capacity settings change over time. Oracle auditors will typically request IBM system reports that display LPAR configurations and any changes. Non-compliant setups (such as an Oracle LPAR that wasn’t strictly limited) could lead Oracle to demand licenses for the maximum cores of the entire frame. Another risk is forgetting that backup or standby LPARs (e.g., for HA/DR) also require licensing, unless they are idle cold standby – Oracle has specific rules for this.
• KVM and Other Linux Virtualization: Running Oracle on KVM (or Oracle Linux KVM, etc.) carries the same risk profile as VMware/Hyper-V. Oracle will not accept cgroups, virsh CPU pinning, or other software controls as limiting unless they match an approved hard partition method. In audits, Oracle typically requests evidence of the physical host specifications for any KVM servers running Oracle. If an Oracle instance could move among multiple KVM hosts (e.g., via OpenStack or oVirt management), expect Oracle to insist that all those hosts be licensed. Misjudging this can lead to significant compliance gaps.
• Public Cloud (AWS, Azure, OCI): While not traditional on-premises virtualization, cloud deployments also appear in audits. Oracle has published rules for authorized cloud environments. For example, on AWS or Azure, Oracle requires that you count two vCPUs as equivalent to 1 Oracle processor license (because of hyperthreaded vCPUs). If an organization isn’t aware of this and counts one cloud vCPU as one license, they’ll be under-licensed by 50%. Oracle’s cloud (OCI) tends to be more straightforward: Oracle offers customers the ability to Bring Your License (BYOL) with cloud-specific calculators for cores, and OCI even provides licensing options that can cover two OCI virtual cores with one license in some cases. The main risk in cloud is misconfiguration (deploying more cores than you have licenses for) or misunderstanding Oracle’s cloud policy. On the plus side, Oracle cannot as easily “sweep” your cloud environment without your help, but they can still audit your records and usage reports, so diligence is needed.

Oracle Licensing Models: Processor vs. Named User Plus in Virtual Environments

Oracle Database licenses are sold under two primary metrics: Processor licenses and Named User Plus (NUP) licenses.

Virtualization affects how each of these is applied, and choosing the wrong model (or mismanaging it) can be costly.

• Processor Licensing: A Processor license allows unlimited users based on the computing power available to the Oracle software. For Oracle Database Enterprise Edition, the list price is about $47,500 per processor core, and Oracle charges 22% of the license cost annually for support. (Oracle also uses a core factor table – for instance, most Intel x86 cores have a 0.5 factor, meaning you need one license per two physical cores.) In virtual environments, the processor metric is usually straightforward in concept: you must license every physical core that an Oracle VM can run on. With soft partitioning (like VMware or Hyper-V), this typically means all cores of all hosts in the cluster. With hard partitioning, it means all cores are allocated to the Oracle partition. Processor licensing in large virtual infrastructures can become extremely expensive, but it saves you from tracking individual user counts and covers any number of database users or connections.
• Named User Plus (NUP) Licensing: NUP licenses are based on counting distinct users (including non-human operated devices or batch jobs) that access the Oracle database. Each NUP is approximately $800–$950 at list price. Oracle imposes a minimum number of NUPs per processor to ensure a minimum revenue floor. For Enterprise Edition, the rule is a minimum of 25 Named Users per processor (core). For example, imagine a server effectively requires two processor licenses (after core factoring); Oracle would mandate at least 50 NUP licenses for that server, even if you have only 10 named users. In that case, 50 NUPs at approximately $950 each would cost about $47,500, which interestingly equals the cost of one processor license. This is by design: the minimums ensure that NUP pricing isn’t too much lower than processor licensing for a given hardware size. NUP licensing can be cost-effective in small, controlled environments (say a dev/test server with 10 developers, or a departmental app with 20 users). However, in virtual environments, NUP becomes tricky. If Oracle says you must license an entire VMware cluster of 20 cores, that implies a minimum of 20 * 25 = 500 NUPs, no matter if you have far fewer actual users. 500 NUP licenses at ~$950 each would be roughly $475,000, often negating savings. Moreover, tracking every named user across a dynamic virtual environment is challenging; any uncounted user (or a system account that has not been licensed) is an audit exposure. In summary, most enterprises running Oracle on large virtual platforms opt for processor licensing due to the complexity of user counting. NUP is typically seen in smaller or non-production instances, kept separate from big clusters.

Ensuring Compliance: Key Data Points to Review

To manage Oracle licensing in virtual environments, CIOs must continuously gather and review certain data points.

These help in self-auditing and in defending your licensing position if Oracle comes knocking:

• Hardware Inventory & Topology: Document all physical hosts on which Oracle software is installed or could potentially run. This includes CPU specifications (number of cores, CPU model, and the Oracle core factor for that processor type), as well as how these hosts are networked or clustered (e.g., which VMware cluster or Hyper-V host group). Essentially, be aware of the scope of infrastructure that may be involved in licensing.
• Virtualization Configuration: Keep detailed info on how your virtualization is set up. Key factors include cluster sizes, virtualization platform versions, and any VM mobility settings (such as VMware vMotion/DRS rules or Hyper-V live migration settings). For instance, if you have a VMware cluster dedicated to Oracle and configured with no connectivity to other clusters, document that isolation – it can be crucial evidence that Oracle VMs couldn’t run elsewhere. If using something like Oracle VM or IBM LPAR, maintain the configuration files or screenshots that show CPU pinning or capped settings.
• vCPU Allocation and Mapping: Track the number of virtual CPUs allocated to each Oracle virtual machine and whether those vCPUs are tied to specific physical cores. This is important because, in an audit, Oracle might question whether an Oracle VM could use more resources than claimed. For hard partitioning scenarios, you need proof (such as OVM configurations or LPAR definitions) of the exact CPU allocation. Even in soft partitioning (such as VMware), showing that an Oracle VM is set to use only a small number of cores (via affinity rules) can be part of a defense (though not foolproof without Oracle’s contractual agreement).
• Historical VM Movement and Usage: It’s vital to have logs or records of where Oracle VMs have run over time. Oracle auditors often request VMware vCenter history or similar information. You’ll need evidence to assert that an Oracle VM stayed on Host A and never moved to Hosts B or C in the cluster. Likewise, if you had a disaster recovery failover or a test clone of an Oracle VM on another host, those events must be accounted for in licensing. Regularly review VMware vMotion histories, cloud instance metrics, or any auto-scaling records in case Oracle instances spun up in unplanned places.
• License Entitlements vs. Deployments: Maintain an updated list of your Oracle licenses (processor licenses, NUP counts, and any Unlimited License Agreements) and map them against where Oracle software is deployed. This helps to quickly spot if you’re over-deployed. For example, if you have 10 processor licenses purchased but your VMware cluster calculation shows you need 12, you have a problem to address before an audit. Include all environments – production, development, testing, backup – because Oracle’s audit will, and even non-production use, can require licensing in many cases.
• Oracle Feature Usage & Options: Beyond CPUs and users, note which Oracle options or packs are enabled (e.g., Real Application Clusters, Partitioning option, Diagnostics/Tuning packs) because these have separate licenses. In virtual environments, a DBA may enable an option on one instance as a trial, not realizing it triggers a license requirement. Knowing this is part of being compliance-ready, though it’s beyond just virtualization – it’s a general Oracle compliance point.

By regularly collecting and reviewing these data points, CIOs can gauge their compliance position at any time and avoid nasty surprises.

Effective software asset management tools can automate much of this data gathering (for example, VMware’s vCenter reports or Oracle’s LMS scripts). Still, it’s essential to interpret the data in accordance with Oracle’s rules.

Oracle Licensing Cost Examples: VMware vs. LPAR vs. OCI

The cost implications of Oracle’s licensing rules can be dramatic. Let’s compare three scenarios to illustrate how virtualization choices affect licensing costs.

Assume in each case we need to run an Oracle Database Enterprise Edition workload equivalent to 4 CPU cores of capacity:

• Scenario 1: Oracle on VMware (Soft Partitioning). Imagine a VMware cluster with four hosts, each with two 10-core CPUs (total 20 cores per host, 80 cores across the cluster). Under Oracle’s soft partitioning stance, if an Oracle VM runs on this cluster, you must license all 80 physical cores. With Oracle’s core factor of 0.5 for x86 chips, those 80 cores count as 40 processor licenses. At ~$47,500 per license, that’s approximately $1.9 million in license fees, plus about $418,000 per year in support (22% of license cost). This holds even if the Oracle VM itself only uses 4 vCPUs – Oracle doesn’t care in a soft partition environment. The cost multiplies because you’re licensing an entire cluster for a single application. Many companies have been caught off guard by this “license multiplier” effect in VMware. (If instead that cluster were smaller – say two hosts – the cost would be less, but the principle remains: all potential cores must be licensed.)
• Scenario 2: Oracle on IBM LPAR (Hard Partitioning). Now consider an IBM Power server with 16 physical cores, which also hosts other workloads. You create a dedicated LPAR for Oracle and cap it at four cores. Oracle accepts this hard partition, so you only need to license those four cores. IBM Power CPUs have a core factor of 1.0 in Oracle’s schedule, so four cores = 4 licenses. At $47,500 each, that’s $190,000 in licenses, and about $41,800 per year in support. Compared to the VMware scenario, the Oracle workload here is similar (4 cores of processing power). Still, through hard partitioning, the organization saves millions by not having to license all 16 cores or an entire cluster. This demonstrates why using approved partitioning or dedicated hardware for Oracle can be a financially prudent approach.
• Scenario 3: Oracle in Oracle’s Cloud (OCI). Suppose you deploy the same Oracle database in Oracle Cloud Infrastructure and give it 4 OCPUs (Oracle’s term for CPU cores in the cloud). Oracle’s cloud services have an advantage: if you bring your licenses (BYOL), Oracle lets you apply them at a favorable rate. In OCI, 1 Oracle license can cover 2 OCPUs in many cases (because OCI’s definition of OCPU corresponds to one physical core with two hardware threads). So those 4 OCPUs could require as few as 2 processor licenses. That equates to roughly $95,000 in licenses (with support $20,900/year) if using BYOL. Alternatively, you could choose a “license included” model in OCI, where you pay for the database hourly as part of the cloud bill – in that case, you’re essentially renting the licenses. The cost for 4 OCPUs would be baked into the OCI service pricing. Either way, OCI ensures you’re only paying for the capacity you use. There’s no risk of a data center’s worth of cores suddenly needing licensing. One reason some CIOs consider moving Oracle workloads to OCI or other clouds is that it can better cap and predict license costs than on-premises VMs that might sprawl.

Cost Summary:

The above examples demonstrate that an Oracle Enterprise Edition deployment, which requires approximately four cores of power, can incur costs ranging from approximately $95,000 (in OCI with BYOL) to $190,000 (with on-premises hardware partition) to nearly $2 million (on a large VMware cluster) in license fees.

Annual support fees will then compound these costs. Such stark differences underscore the importance of architecting Oracle deployments with licensing in mind – a technical decision in virtualization can have significant budget implications of several million dollars.

Licensing Strategies to Reduce Audit Exposure

CIOs can adopt several strategies to lower the risk of an Oracle license violation in virtual environments.

Here are key approaches to consider:

• Dedicated Oracle Environments (Physical Segregation): The simplest way to avoid the sprawl problem is to keep Oracle on its turf. This means isolating Oracle workloads to specific servers or clusters that are dedicated solely to Oracle. For example, if you are using VMware, you might create a dedicated Oracle cluster separate from other workloads. By doing so, you contain the licensing requirement to just those hosts. Ensure that Oracle VMs cannot vMotion to other clusters by disabling DRS or keeping the Oracle cluster on a separate vCenter if necessary. Physical segregation may slightly reduce infrastructure flexibility, but it provides clarity: you know exactly which machines require licensing for Oracle. This approach significantly reduces the blast radius of an Oracle audit – they can’t claim your entire virtualized farm, only the isolated part where Oracle resides.
• “Caging” Oracle Workloads with Hard Partitioning: In scenarios where dedicating hardware isn’t feasible, the next best thing is to cage Oracle with technology. Use hard partitioning techniques to confine Oracle to a fixed set of resources. For example, if you run Oracle on Oracle VM, leverage CPU pinning so the VM never uses more cores than you’ve licensed. On IBM Power, use capped LPARs. Even in VMware, although not officially recognized by Oracle, you can use VM-Host affinity rules to lock an Oracle VM to a particular host or group of hosts; some organizations do this as a best-effort containment measure (though Oracle will insist on licensing all hosts unless you have a contractual agreement – see below). The goal is to prevent Oracle from wandering onto unlicensed CPUs. Think of it like creating a virtual cage around the Oracle instances. This strategy should be combined with strict change control: administrators must know not to add CPUs or move VMs without evaluating the license impact.
• Contractual Amendments or Clarifications: Oracle’s standard contracts don’t explicitly mention names like “VMware,” but they also don’t grant any rights for soft partitioning. Some companies negotiate written agreements with Oracle that clarify the use of virtualization to gain certainty and ensure compliance. One example is a Network Partitioning or Storage Isolation clause for VMware. In this addendum, Oracle agrees that if Oracle VMs are kept on specific, isolated clusters (often with no shared storage or network with others), only those clusters require licensing. Getting Oracle to sign such amendments can be challenging (and often requires showing a strong compliance case), but it’s not impossible, especially for major customers or those renewing contracts. Another contractual approach is to move to an Unlimited License Agreement (ULA) for a specified period, which can temporarily allow unlimited deployment (including in virtual environments) without compliance concerns. However, ULAs come with their costs and complexities (and expiration true-ups), so they should be entered with caution and a clear exit plan. The main idea is to have any special virtualization arrangement in writing with Oracle to avoid “he said, she said” scenarios during audits.
• Regular Internal Audits and Monitoring: Proactivity is a strategy. Conduct periodic Oracle license compliance reviews. For virtual environments, that means reviewing the data points mentioned earlier (hosts, clusters, VM locations, user counts, etc.) every quarter or whenever significant changes occur. By catching a rogue Oracle VM deployment or a configuration drift early, you can correct it (or license it properly) before Oracle’s auditors do. Some organizations even simulate an Oracle audit by using Oracle’s LMS data collection tools on themselves to see what a formal audit might find. Investing in internal Software Asset Management (SAM) tools or services can pay off by ensuring you have an accurate picture of your Oracle footprint across virtual platforms.
• Leverage Oracle-Friendly Platforms or Services: Consider if any Oracle workload can be moved to more license-efficient platforms. For instance, if you have an application that doesn’t use Enterprise Edition features, Oracle Standard Edition 2 (SE2) might be an option – SE2 is licensed per socket (with a lower cost ~$17,500 per socket) and allows up to 2-socket servers (or 2-socket clusters up to 4 sockets total). SE2 can run on a small, dedicated VMware cluster without the per-core tax (although it’s limited in scale, it suffices for some workloads). Another angle is Oracle Cloud: as discussed, OCI can eliminate a lot of compliance ambiguity by tying licensing to exact cloud usage or offering license-included subscriptions. If a particular Oracle system is a headache in VMware, moving it to OCI or a managed cloud service (such as Oracle on Azure or AWS RDS) could reduce audit exposure, as those environments have clearer licensing parameters. The trade-off is ensuring performance, feature parity, and cost of cloud, but it’s worth evaluating as a strategy for troublesome cases.

In summary, mitigating Oracle license risk in virtualization primarily involves containment, documentation, and effective communication.

Contain Oracle within known boundaries, document everything about those boundaries and their usage, and communicate (both internally with your teams and externally with Oracle) to ensure no surprises.

Recommendations

For CIOs looking to avoid costly Oracle licensing surprises in virtual environments, here are practical steps to take:

1. Inventory Your Oracle Footprint: Identify all instances of Oracle databases and middleware in your organization and map out exactly where they run (which VMs, hosts, clusters, or cloud instances). This inventory is the foundation for any compliance effort.
2. Isolate and Contain Oracle Workloads: Wherever possible, run Oracle on dedicated servers or segregated clusters. Prevent Oracle VMs from freely moving across your entire virtual infrastructure. This might involve creating Oracle-only clusters or disabling auto-migration features for those VMs. The goal is to limit the scope of required licenses.
3. Use Hard Partitioning or Fixed Caps: Utilize Oracle-approved partitioning methods. On supported systems, configure hard partitions or capped CPU allocations for Oracle. If you’re on VMware or another unapproved hypervisor, consider static affinity rules or other controls to effectively “pin” Oracle, and document these measures. While not officially recognized without agreement, such internal discipline will at least maintain predictable usage.
4. Track License Metrics Continuously: Implement a process (and utilize available tools) to monitor your compliance. This includes tracking physical core counts vs. licenses owned, monitoring named user counts if using NUP licensing, and watching for any changes (like additional cores given to a VM). Set up alerts or periodic reports on these metrics for transparency.
5. Educate Your IT Teams: Ensure system administrators, DBAs, and architects understand Oracle’s licensing pitfalls. A well-meaning VMware administrator might vMotion an Oracle VM to a new cluster to improve performance, unaware that it could cost the company millions in licensing. Regular training and clear internal policies can prevent such costly mistakes.
6. Engage Oracle (or Experts) Proactively: Don’t wait for an audit to sort things out. If your organization is making a big virtualization change or cloud move involving Oracle, consult with Oracle License Management Services (LMS) or third-party licensing experts beforehand. Negotiate contract terms (such as a virtualization clause or a ULA) to legally solidify your understanding. It’s better to have an awkward conversation with Oracle about licensing upfront than a punitive one later during an audit.
7. Plan for Audits: Assume that an Oracle audit will happen at some point (many CIOs can attest that Oracle’s audit notices are frequent). Have an audit response plan ready: know who will gather data, how you will demonstrate your partitioning or isolation, and what your legal stance is. When working with virtual environments, be prepared to provide detailed infrastructure maps and records. When Oracle auditors see that you’re well-prepared and knowledgeable, they are less likely to push unfounded claims.

By following these steps, CIOs can significantly reduce the financial risks associated with Oracle licensing in today’s virtualized data centers.

The key is to be intentional about where and how Oracle runs, and never assume that a virtual environment gives you a licensing break without explicit permission.

A proactive approach to Oracle licensing can save your organization from multi-million-dollar surprises and ensure your virtualization strategy doesn’t backfire financially.

Read about our Oracle Licensing Assessment Service.

Would you like to discuss our Oracle Advisory Services with us?

Please enable JavaScript in your browser to complete this form.

Name *

First

Last

Email *

Message *

Submit