# Ignition and VMware

**URL:** <https://forum.inductiveautomation.com/t/ignition-and-vmware/107248>\
**Category:** Ignition\
**Created:** [June 10, 2025, 7:11pm UTC](https://forum.inductiveautomation.com/t/ignition-and-vmware/107248 "2025-06-10T19:11:17Z")\
**Posts on this page:** 15\
**Page:** 1

<div class="post-metadata">

**Author:** ![Tom-L](https://avatars.discourse-cdn.com/v4/letter/t/50afbb/32.png) [@Tom-L](https://forum.inductiveautomation.com/u/Tom-L)\
**Post date:** [June 10, 2025, 7:11pm UTC](https://forum.inductiveautomation.com/t/ignition-and-vmware/107248/1 "2025-06-10T19:11:17Z")

</div>

This question keeps coming back around, looking for a definitive answer:  
We are deploying Ignition on a VMware system that consists of 2 redundant servers. If one server fails, the other takes over, typical stuff. My question is, do I need to setup a master and backup gateway or can I use one gateway and let VMware handle the failover. The problem is cost - if I go with Master/ Backup gateways I assume I will need a second Ignition license (even if it's reduced cost for the backup). Will Ignition work with one license and one gateway and failover properly if VMware does the failover?

---

<div class="post-metadata">

**Author:** ![smcfarlane](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/smcfarlane/32/42150_2.png) [@smcfarlane](https://forum.inductiveautomation.com/u/smcfarlane)\
**Post date:** [June 10, 2025, 7:20pm UTC](https://forum.inductiveautomation.com/t/ignition-and-vmware/107248/2 "2025-06-10T19:20:08Z")

</div>

If VMWare is in charge of the failover then I imagine the backup gateway would go back to being unlicensed. I assume this loophole would have been discovered and closed a long time ago.

Given that you need redundancy, the 50% cost of the backup seems like a no brainer. Out of curiosity - how much money would you lose per hour if Ignition went down?

---

<div class="post-metadata">

**Author:** ![Tom-L](https://avatars.discourse-cdn.com/v4/letter/t/50afbb/32.png) [@Tom-L](https://forum.inductiveautomation.com/u/Tom-L)\
**Post date:** [June 10, 2025, 7:36pm UTC](https://forum.inductiveautomation.com/t/ignition-and-vmware/107248/3 "2025-06-10T19:36:31Z")

</div>

It's not really about Ignition going down, it's about hardware failures and having to pay additional costs to move an already licensed vm to another piece of hardware. I just need to price it for the customer, so want to make sure I do that properly and have the right answer if someone asks what the license cost entails and why moving a vm to another server would require another license since it is just one Ignition gateway running on one piece of hardware at any point in time. It's a big price jump for a FT site moving to Ignition even though I tell them how wonderful it is, so just want to have the proper explanation.

---

<div class="post-metadata">

**Author:** ![ryan.white](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ryan.white/32/73193_2.png) [@ryan.white](https://forum.inductiveautomation.com/u/ryan.white)\
**Post date:** [June 10, 2025, 7:48pm UTC](https://forum.inductiveautomation.com/t/ignition-and-vmware/107248/4 "2025-06-10T19:48:45Z")

</div>

Proper redundancy (for Ignition) is having primary and backup ignition servers on physically separate machines, with both being licensed.

You will run into much headache trying to activate and un-activate your servers on demand during a failover. What happens if you are unable to reach the activation server during a failover?

> **[Redundancy Architecture | Ignition User Manual](https://www.docs.inductiveautomation.com/docs/8.1/system-architectures/redundancy-architecture)**
>
> Mission Critical - Gateway Redundancy

Any failure mode on the primary server should sever that server's connection to all devices and the backup. If it only severs connection to the backup you'll get a split brain scenario.

---

<div class="post-metadata">

**Author:** ![Tom-L](https://avatars.discourse-cdn.com/v4/letter/t/50afbb/32.png) [@Tom-L](https://forum.inductiveautomation.com/u/Tom-L)\
**Post date:** [June 10, 2025, 7:52pm UTC](https://forum.inductiveautomation.com/t/ignition-and-vmware/107248/5 "2025-06-10T19:52:43Z")

</div>

Thanks, I understand, I need to be able to justify and explain it to the [potential] customers so appreciate the answer on what is required.

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [June 10, 2025, 7:54pm UTC](https://forum.inductiveautomation.com/t/ignition-and-vmware/107248/6 "2025-06-10T19:54:41Z")

</div>

Perhaps you should involve IA sales engineering.

---

<div class="post-metadata">

**Author:** ![smcfarlane](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/smcfarlane/32/42150_2.png) [@smcfarlane](https://forum.inductiveautomation.com/u/smcfarlane)\
**Post date:** [June 10, 2025, 8:01pm UTC](https://forum.inductiveautomation.com/t/ignition-and-vmware/107248/7 "2025-06-10T20:01:35Z")

</div>

> It's a big price jump for a FT site moving to Ignition even though I tell them how wonderful it is, so just want to have the proper explanation.

Compared to a redundant factorytalk server?

---

<div class="post-metadata">

**Author:** ![ryan.white](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ryan.white/32/73193_2.png) [@ryan.white](https://forum.inductiveautomation.com/u/ryan.white)\
**Post date:** [June 10, 2025, 8:05pm UTC](https://forum.inductiveautomation.com/t/ignition-and-vmware/107248/8 "2025-06-10T20:05:04Z")

</div>

> [@smcfarlane](#):
>
> Compared to a redundant factorytalk server?

They probably have a license server that the active instance points at. Single license with a fast timeout or a forced return.

---

<div class="post-metadata">

**Author:** ![smcfarlane](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/smcfarlane/32/42150_2.png) [@smcfarlane](https://forum.inductiveautomation.com/u/smcfarlane)\
**Post date:** [June 10, 2025, 8:13pm UTC](https://forum.inductiveautomation.com/t/ignition-and-vmware/107248/9 "2025-06-10T20:13:12Z")

</div>

Right but now there is a single source of failure if your license server vm goes down

---

<div class="post-metadata">

**Author:** ![Tom-L](https://avatars.discourse-cdn.com/v4/letter/t/50afbb/32.png) [@Tom-L](https://forum.inductiveautomation.com/u/Tom-L)\
**Post date:** [June 10, 2025, 8:14pm UTC](https://forum.inductiveautomation.com/t/ignition-and-vmware/107248/10 "2025-06-10T20:14:07Z")

</div>

The existing site had no FT redundancy setup, so it's a big change for them and that's why I wanted to make sure I had the right info for what the proper setup should be. Believe me, I get it, but unfortunately many times the people reviewing the bids don't, so I need to make it clear to them.

---

<div class="post-metadata">

**Author:** ![smcfarlane](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/smcfarlane/32/42150_2.png) [@smcfarlane](https://forum.inductiveautomation.com/u/smcfarlane)\
**Post date:** [June 10, 2025, 8:16pm UTC](https://forum.inductiveautomation.com/t/ignition-and-vmware/107248/11 "2025-06-10T20:16:01Z")

</div>

> unfortunately many times the people reviewing the bids don't

I hear you, Im on the sales and integration side too. The right way to do this is purchase a redundant backup license for ignition.

---

<div class="post-metadata">

**Author:** ![michael.flagler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.flagler/32/26272_2.png) [@michael.flagler](https://forum.inductiveautomation.com/u/michael.flagler)\
**Post date:** [June 11, 2025, 12:01pm UTC](https://forum.inductiveautomation.com/t/ignition-and-vmware/107248/12 "2025-06-11T12:01:27Z")

</div>

I wouldn't think a VM being moved to a new server would cause an issue, but your failover times would not be as fast as using true redundancy. You wouldn't need to deactivate or reactivate anything I wouldn't think as VMware should try to maintain the identity of the server, but I could be wrong as I haven't tested this with Ignition personally. Whenever you copy a VM, VMware gives it a new identity that would cause you to reactivate.

Are you using shared storage for VMware to ensure the data on the VM is consistent when it fails over?

---

<div class="post-metadata">

**Author:** ![pascal.fragnoud](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pascal.fragnoud/32/24728_2.png) [@pascal.fragnoud](https://forum.inductiveautomation.com/u/pascal.fragnoud)\
**Post date:** [June 11, 2025, 2:24pm UTC](https://forum.inductiveautomation.com/t/ignition-and-vmware/107248/13 "2025-06-11T14:24:37Z")

</div>

You'd probably be using a leased license for this.

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [June 11, 2025, 4:13pm UTC](https://forum.inductiveautomation.com/t/ignition-and-vmware/107248/14 "2025-06-11T16:13:06Z")

</div>

I strongly disagree. Leased licenses need a relatively reliable internet connection. If you are setting up redundancy in a local environment, I think a permanent license for both gateways is necessary.

---

<div class="post-metadata">

**Author:** ![dtompkins](https://avatars.discourse-cdn.com/v4/letter/d/a6a055/32.png) [@dtompkins](https://forum.inductiveautomation.com/u/dtompkins)\
**Post date:** [June 17, 2025, 2:00am UTC](https://forum.inductiveautomation.com/t/ignition-and-vmware/107248/15 "2025-06-17T02:00:39Z")

</div>

It seems like the answer depends on the type of outage you are trying to mitigate. In a VM environment (or at least ours) there are multiple hardware nodes. If one fails, the workloads migrate to other nodes. This works fine for hardware outages, but not for software maintenance. To accommodate O/S patches and other software upgrades, you would need a redundant pair in order to maintain operations. Patch one, then fail over and patch the other.
