Can Orion NPM run on an ESX VMware environment?

As Long as you stay above Recommended Values, you can run Orion on a VM without issue:

Requirements for Virtual Machines and Servers

If you are using NTA then you'll need to think about putting Orion into VM. NTA is very intense with SQL.

Solarwinds strongly advised us against using vmware, which was our original plan (much easier and added redundancy) and told us that if we decide to put it on a vmware server, if solarwinds support thinks that it might be a vmware issue, no support will have to be given.

Just to clarify, there are multiple components to an Orion installation:

1. Primary Orion server

2. Orion additional pollers / websites

3. Orion DB (SQL Server)

#1 and #2 above are absolutely fine to run on VMware.  In fact, we have thousands of customers running in that exact configuration.   Where you run into trouble is trying to run SQL server in a VMware environment.   Why?   VMware storage is not optimized for the I/O requirements of storing monitoring data (at least in the majority of customers we've seen try to deploy the Orion DB on VMware), especially when you add the requirements of Orion NTA with heavy NetFlow data collection.   In most cases, VMware storage is on a SAN which is in use by many other applications and not optimized for SQL data storage, which creates contention when SQL needs to be optimized for heavy writes.  

This is why we strongly recommend running SQL server on a physical box with direct attached storage.   SAN is also possible, but you have to know what you're doing.   I've attached some SAN reference environments if you're interested in what other customers are doing.

We are running NPM, APM & NCM on a single VM. Our DB resides on a dedicated physical SQL box optimized for high IO. 4258 elements and no problems.

Hi Chris,

but at least when we bought the product (not yet a year ago) we were told that we can run Orion (not the database) on a VMWare server and while the product would still be supported, if support team has a suspicion that it might be a vmware problem, we would not get any support.

now, from what I have experienced from support (do you have the newest version? no? well then your problem is most likely fixed in the next version, open a new case if the problem still exists then. Oh not fixed? well we have a new version coming soon where it should be fixed, we will notify you when you can download it. You do have the newest version? Well that might be the problem! Some customers reported to have this error with the newest version. That is actually not a bug, it is known behaviour aka a feature) we rather not take the chance to give support more reasons not to investigate problems.

We have our DB-server on a separate physical server and the database itself on a high performance SAN.

To add to Chris's point, see the bottom of this page here regarding our statement regarding VMWare

Ricky,

We have the NPM management server running on a VM with no issue. The pollers are hardware based, and the database sits on our corporate SQL Server SAN. This seems to be a very solid configuration. I have to echo the post stating that SQL Server does not play well on a VM due to I/O issues. I would also say the same with pollers as well.

Hope this helps.

Jim

We are migrating to Cisco UCS, Net Apps SANS, and ESXi 5.0 .

So you are saying your SQL server and pollers are hardware based, and the databases reside on the SANs ? Right now we are running SAM, NPM, NCM on a Server 2008R2 physical machine , and the SQL server with all the databases on another physical server.

Quite a few people have experience with this, but I will add mine as well. I have now worked with Solarwinds products at two companies, though not long with my new company. I will give a breakdown based on each.

My Previous Employer

We had a primary Orion server running in a VM. This server was running Orion Core, NPM, NCM, NPM, and a third part app we used for alerting called Attention. We also had NTM installed, but were not using it much at the time. We also had 2 additional pollers, both VMs. Lastly, we had an MS SQL 2008 backend that was also a VM, and this is where I had some issues. I was not a proponent of a virtual environment when we brought monitoring in-house, but the company was in the process of virtualizing everything, so I really had no say. All of the company's SQL VMs were clustered onto 2 servers due to licensing issues, and I think we were tapping the resources out too much. We saw less than ideal performance in the environment, such as when opening up nodes for editing, things like that. Shortly before I left a couple weeks ago, we migrated our environment to a new (external) datacenter. The solarwinds environment was one of the very first to be moved, and after it was migrated, I saw performance gains that were incredible. Unfortunately, these seemed to disappear in subsequent weeks as more and more servers were migrated. The last thing I want to mention was a major problem that I saw, and this is with regard to VMotions. We had 3 distinct instances where the primary Orion server was VMotioned due to resource issues, and every time, I had a problem to contend with. The first time it happened, I had a ton of issues and had to open a ticket with Solarwinds. After running diag and several other steps, I ended up having to re-install a couple services (can't recall at the moment, but JobEngineV2 and something else). The second and third time didn't require as much, but still needed work, including server reboots and service stops/starts.

My Current Employer

There is a primary Orion server running in a VM, with no additional pollers. The backend is an MS SQL 2008 backend, also a VM. The datacenter is in-house, and the environment is much smaller. So far, I have seen no issues with performance or anything else in this environment, but it is also underutilized (Solarwinds hasn't even been fully rolled out yet). Time will tell if I see any issues here, but I don't really anticipate much based on the nature of the configuration.