1. Virtualization Manager dashboard widgets can be embedded into Orion - you can read about that here Single Pane of Glass – Tying in Storage Manager & Virtualization Manager into Orion Dashboard
2. Virtualization Manager does not integrate into the alerting engine, but Virtualization Manager alerts can be forwarded as SNMP traps.
3. For VMware data collection, only port 443 should be required.
4. Virtualization Manager has a federated deployment model for large environments, where a "Federated Collector" can be located close to the source of data (e.g. at the end of a WAN link) You can read about that here http://www.solarwinds.com/documentation/vman/docs/html/en-US/wwhelp/wwhimpl/js/html/wwhelp.htm#href=SVMAG_InstallationFederatedCollectors.htm#9000445
brilliant, thank you for the great reply! so basically:
- I can deploy a federated collector to each of my customer sites that will pull back all information about their VMware infrastructure.
- I will deploy a central Virtualisation appliance at my Data center
- Central Appliance will poll the remote collectors for data and collect all at the central point for alerting and reporting
ALL alerting will be done from the central server appliance
- Can the remote federated collector be deployed on a multi-homed server? i.e. one with 2 network cards, thus giving access to a VMware LAN, while being able to give the information back out over the core LAN to the central Solarwinds server?
- Can the central server deal with communication with federated collectors over a NAT’ed IP address?
- how often do the collector and the central Solarwinds servers communicate (transfer performance data)
- How is communication done, does the remote Collector push from the remote collector back to the central appliance? Or does central go out and ;poll the remote collectors?
- Is All communication between the main Solarwinds Server and the remote collectors is done over port 443, or just the collector > VMware infrastructure?
- Can we get any hardware failure alerting out of this product yet? Or do we need to configure the Virtual centre to do that ourselves still?
- How is this method licensed? Do I just keep buying more core licenses or is it on the number of Virtual centres or ESX hosts or CPUs?
- Do the remote collectors require a database instances? Or just the central one (is it SQL server, and can it be remote)
Sorry for so many questions, I am looking to make a strategic decision on what product to go for, to take over the VMware monitoring of mine and my customer environments…
- The federated collector is a linux based (VMware) virtual appliance, so should be pretty flexible configuration wise as far as multi-homing
- All communication is essentially push (message bus) and occurs over port tcp/61616 (ActiveMQ) between the collectors and the main appliance
- NAT is likely possible with some appropriate forwarding rules - the collector needs to be able to reach the main appliance (using above port)
- You would need to leverage vCenter for most hardware alerting
- The product is licensed based on the number of Powered ON VMs under management
- The federated collectors have no database and simply forward data to the main appliance
Let me know of you want to talk to a Sales Engineer
this is brilliant, thank you so much for the help.
So my final solution to try and get end to end VMware management would be:
1 - deploy SW Virtual manager to get capacity and performance information and alerting about the ESX hosts and the virtual centre using the virtual appliance in the federated model
2. upgrade my core Orion to 10.2 to be able to see hardware information about the physical hosts and then point it to the ESX hosts and virtual centre over 443
this should eventually give me hardware and software layer monitoring/alerting of the whole infrastructure (assuming the vendor versions of ESX are installed onto the physical servers)
1 - During my demo, it looks impossible within the Victual manger, to identify what VMs and ESX hosts belong to a specific customer (assuming i a monitoring multiple customer VMs from the same central server). is there anything that can be done, like the custom property editor in NPM? if not, this would be a major flaw and possibly make it non-feasible for us :-(
2. what is the back end database, can i pull information out of it direct, i.e. using reporting services to generate monthly reports for customers?
3. if i have tons of development VMs, and i do not want any information about them, how do i stop them affecting the license count for the virtual manager? is this possible?
1. You can do this in a variety of ways but generally you can use search to group VMs and hosts by customer. For example, a search for all of the VMs in a certain folder or Resource Pool, or having a specific naming convention. We also have custom fields (labels) that can be applied to objects.
2. We use a PostgreSQL database, we don't allow access to the database but we do have an API and Perl and Powershell wrappers to it.
3. The way we recommend to do this is to filter them out on the vCenter side. For example, make sure the development clusters (or similar) are not visible by the account we use to collect data from vCenter (see http://www.solarwinds.com/documentation/vMan/docs/html/en-US/wwhelp/wwhimpl/common/html/wwhelp.htm#context=SolarWinds&file=SVMAG_Installation.htm#9000488 licensing section)
any more thoughts on this? will mrk as NOT answer for the time being as i have lots more questions :-)