Last week I received an e-mail from Karen from Tripwire asking me if I was interested in writing a review about their latest release of vWire. When I got my hands on their first very early beta a few months ago, I had trouble understanding the product which made me a bit reluctant on playing with this new release. It had many options and views, but I couldnâ€™t see it as a useful tool. It made me very happy to see that the release I downloaded for this review (vWire 1.0.1), felt completely different. I had quite a number of oohâ€™s and aahâ€™s when reviewing this version and to spoil the rest of the review, I can already tell you that I was very impressed with this product and I really like it. Yes, I do notice this is already the second product lately that Iâ€™m so enthusiastic about, maybe itâ€™s an age thing and Iâ€™m getting softer?
Letâ€™s start from the beginning. According to the Tripwire website at (http://tripwire.com/products/vwire.cfm ) vWire will â€œreduce downtime and operational costâ€. Well the standard marketing stuff you and I have read so many times before which tells you nothing about what the product really does. A bit more: â€œMonitoring the health of virtual infrastructureâ€ and â€œActively managing virtual infrastructure and helping to further automate the virtual environmentâ€ but still not really clear. Iâ€™m always looking for the easier explanations for simple minds like me. To me, what vWire does is monitor the configuration of your virtual environment and alert you if it detects any problems. As a response to these alerts, vWire has a number of pre-defined actions that you can start to solve a number of these problems. What I really like is how open vWire is. All rules to detect problems are based on SQL queries that you can edit and use for your own special queries. The actions that can be taken are based on Powershell actions that you can also edit or adopt for your own special actions. This is what gives vWire that extra that made me really love the product. Enough chit chat, letâ€™s start the review.
Installation is very easy and as simple next, next, finish job. Every MCSE can do that. The only remarkable thing I noticed was that besides the .Net 2.0 framework, vWire requires PowerShell 1.0 and the VMware Infrastructure Toolkit 1.5 or VMware vSphere PowerCLI 4.0. vWire uses a SQL database for its data which can be the integrated SQL Express database or an external MS SQL 2005/2008 database. Nothing special there, so you will have it up and running within a few minutes. After installation the vWire dashboard website is available and you can logon with the domain or local Windows admin to do the last configuration settings, like adding a license file and adding one or more Virtual Center servers. The Quick Tour on the opening page is a nice idea but the info presented doesnâ€™t really help you on your way, to me it is more like a sales slide and I quickly disabled it.
The dashboard gives you a quick overview of all the alerts that are active, a nice bar-graph on the severity of the alerts and a shortcut to some frequently used functies like â€œFind a VMâ€, â€œFind a Hostâ€, etc.
Another part of the dashboard gives you an overview of the latest entries on the vWire Community forum which I found comes sometimes very handy. Like most Dashboard it is just a summary page of what is happening and if you want to get to the real info, you click through to the other pages.
My test lab of 3 hosts is a rather simple setup and I didnâ€™t expect any problems to be found, but when opening the Alerts tab from the dashboard I was presented a list of 20 alerts in my environment. Auch.
First section of alerts was about â€œInaccessible VM Networkâ€ with 4 open alerts affecting 4 VM Networks. When clicking the link a window pops-up that gives more detail and tells me that in total 4 VM Networks or portgroups are used in a VM configuration that arenâ€™t available on the host the VM is on. When looking at this info it took me some time to get to the names of the VMs and that is what I think is a small learning curve in the vWire product. The amount of info you get from the interface gives you the impression that you will be able to see really everything you want to know, but sometimes youâ€™ll have trouble getting there. Once you found it however, youâ€™ll never forget. So, yes there is a small learning curve but youâ€™ll catch on quickly. Like in the screenshot below, on the right-hand side the networks are shown that are connected to a VM but donâ€™t exist anymore.
However, clicking any of the tabs below doesnâ€™t give me the name of the VMs Iâ€™m looking for. Well, little curve here, just press the â€œSee related:â€ pull down and select â€œVirtual Machineâ€ and voila, there you have your list.
Now select one of the VMs with a problem and click on â€œdetailsâ€. This will bring you to the â€œSearchâ€ tab and present more info on the VM.
The tab â€œActionsâ€ gives you a number of pre-defined actions. Unfortunately in my case, the correct action (switch network to â€˜productionâ€™) isnâ€™t on the list. But should you have an alert that a Snapshot is older than 30 days, you could easily start the action to remove a snapshot. Very nice thing of vWire though is that you can create a custom action to do this for you. Iâ€™ll come to this later on when reviewing the â€œWorkbenchâ€ section.
One very impressive part is the â€œSearchâ€ tab, which will give you the opportunity to get every bit of info out of your infrastructure and maybe more. This powerful function has a lot of predefined searches that are linked to the â€œSearch forâ€ object you select at the top. There are about 40 different objects that can be used to search on and just like with the alerts, if you need more searches that youâ€™re going to use frequently you can create your own search in the â€œWorkbenchâ€ section.
An impression of predefined searches:
For the Virtual Machine object:
- Alert Rule Scope
- VMs in DRS Clusters
- VMs in HA Clusters
- VMs With Inaccessible Networks
- Snapshot Age
- VMs With Snapshots Older Than 30 Days
- VMs With Snapshots Older Than 7 Days
- VMs Datastore is Inaccessible
- CPU Affinity Configured
- Memory Affinity Configured
- Virtual CD May Cause vMotion Failures for VM
- Virtual Disk May Cause vMotion Failures for VM
- Virtual Floppy May Cause vMotion Failures for VM
- Virtual Parallel Port May Cause vMotion Failures for VM
- Virtual Serial Port May Cause vMotion Failures for VM
- VM Network May Cause vMotion Failures for VM
- VM Not Configured to Inherit Swap Placement
- VM Using VM Network On an Internal-only vSwitch
For the Host objects:
- Alert Rule Scope
- Hosts in DRS Clusters
- Hosts in HA Clusters
- Hosts in Maintenance Mode
- Hosts With Internal-only vSwitches
- Security Profile
- High Security Not Enabled on Host Firewall
- Host Contains Datastore Not Present on All Clustered Hosts
- Host Contains VM Network Not Present on All Clustered Hosts
- Identical vMotion IP Addresses
- vMotion is Not Enabled
This is my favorite section because here you will be able to adjust vWire to meet your needs. If you want to create your own alert, you first have to check if there is a search that meets your need, because this will filter the objects (VM, Host, Datastores, etc) you will base your alert on. Now those search queries vary from very simple to rocket science and you might want to do a little search for your SQL books before diving into the deep.
The â€œInaccessible Datastoresâ€ search:
SELECT datastore1 FROM DatastoreEntity AS datastore1Â WHERE ( datastore1.summary.accessible = false )
The â€œVM Port Group Security Policy Mismatchâ€ search:
SELECT hpg1 FROM ClusterEntity AS cluster1 JOIN cluster1.host AS host1 JOIN host1.config.network.portgroup AS hpg1 WHERE hpg1.spec.name IN (SELECT network1.name FROM NetworkEntity AS NETWORK1) AND EXISTS( SELECT 1 FROM ClusterEntity AS cluster2 JOIN cluster2.host AS host2 JOIN host2.config.network.portgroupÂ AS hpg2 WHERE hpg1.key = hpg2.keyÂ AND host1.moid <> host2.moid AND cluster1.id = cluster2.id AND (hpg1.computedPolicy.security.allowPromiscuous <> hpg2.computedPolicy.security.allowPromiscuous
OR hpg1.computedPolicy.security.forgedTransmits <> hpg2.computedPolicy.security.forgedTransmits
OR hpg1.computedPolicy.security.macChanges <> hpg2.computedPolicy.security.macChanges)
Since an Alert can also have an action, you should switch to the Actions page to write your special action to be attached. These actions are pure Powershell scripts and the VMware community has jumped on Powershell and made it to the number one tool for scripting in the Virtual Infrastructure which will give you plenty of resources to start looking if you need a specific script. To get you started quickly have a look at the websites of these Powershell Guruâ€™s:
Alan Renouf: http://www.virtu-al.net/
Hugo Peeters: http://www.peetersonline.nl/
Now that you have your action and your search itâ€™s very easy to create your Alert rule. Just name it, connect the search, connect the alert, enter an optional e-mail address if you want e-mail warnings and youâ€™re good to go. Easy as that.
Sharing searches and actions
Like I wrote above, it is not always so easy to create a search or an action. This is where the community from vWire comes to help at: http://community.vwire.com/community/contentlibrary. Here you can post your own shares and actions by switching to either Alerts, Search or Actions tab, select your item and press the â€œShareâ€ button below. It will create and XML that you can upload to the community website. It would be great if more and more users of the product would share their searches and alerts like I showed in the previous section because it will make your own vWire install better and better.
It might be obvious that I really like the way vWire is built and that is very open to adapt to my needs. I see this product as a very useful tool that I think should be used to do the daily check list in any virtual infrastructure.
vWire is licensed per host for $ 395,- but there is a special offer now for $295,-.