http://www.systemcentercentral.com/BlogDetails/tabid/143/indexId/63843/CommentRSS/1/Default.aspx en-us Copyright 2009 System Center Central All Rights Reserved. Thu, 17 May 2012 06:33:15 GMT
http://www.management-extensions.org/entry.jspa?externalID=100338&categoryID=252]]> Fri, 23 Apr 2010 01:10:23 GMT http://www.systemcentercentral.com/BlogDetails/tabid/143/indexId/63843/Default.aspx#comment-630


I absolutely agree with Alec! Great blog!



Please note that I have added a comment on your blog giving some direction on how to remove vms from the initial discovery. However, as Alec said, there are some compelling reasons to monitor those VMs. If you ever have any questions with regards to the nworks MP for VMware feel free to contact us at any time on the Veeam forums!



www.veeam.com



Thanks!



Brian Pavnick

Veeam Software

Solutions Architect - MP

brian.pavnick@veeam.com

twitter: vbpav

veeam forums: vbpav]]> Fri, 16 Apr 2010 22:15:52 GMT http://www.systemcentercentral.com/BlogDetails/tabid/143/indexId/63843/Default.aspx#comment-623


Thanks for the comments, and the blog post too - and it shows that some of the new features I'm introducing in nworks 5.5 will be welcome! :-)



I'd say you would still get some interesting info, with both nworks VM monitoring, and SCOM Agent inside the VM guest OS. For example, nworks would tell you about hypervisor metrics such as balloon memory usage, cpu Ready times, and swapfile I/O - the SCOM Agent can't tell you these things.



However - I do know that there can be some duplication of data, and for various reasons some customers want to disable some or all VM monitoring, and use nworks for just the ESX Hosts, their hardware, vCenter events etc.



In nworks 5.5, you have complete control over the discoveries - you can globally disable VM discovery in the nworks UI. And you can also disable VM discovery globally, or on a per-Host basis, using overrides in the MP (it would be discovery rule 'SV102 Stage 3' BTW - these details are in the new 5.5 documentation :-))

You can even disable just the discovery of VM vNICs, or VM storage links (vmhba) and so on. It is completely configurable.



You also now have complete control over performance data collection intervals - this means that core metrics (such as cpu and memory) can be gathered on the most frequent interval, e.g. 5 minutes - but less critical metrics such as network traffic can be averaged over 4, or 5, or more intervals. This means you still have the deep-dive metrics - but you get better scalability and performance, and use less space in SCOM DB as well.



And finally - all our performance collection rules now use Ops Mgr's Optimised Providers, which only deliver a new data point if it exceeds a certain deviation from the previous data point. Again - this means that you really save on DB space, while still having all the relevant metrics for graphs and reports.



With nworks 5.5 we will be introducing two new Deployment Toolkit items - a calculator to predict SCOM Database usage, and a calculator to predict number of Collectors required. These will both be available online at veeam.com.



I hope you can give nworks 5.5 a try - if you'd like to see it just let me know.



Thanks!

Alec]]> Thu, 15 Apr 2010 10:26:02 GMT http://www.systemcentercentral.com/BlogDetails/tabid/143/indexId/63843/Default.aspx#comment-618
Too bad, disabling VM monitoring through the nWorks management Console didn't do the trick.



I also blogged about this: http://michielw.blogspot.com/2010/04/nworks-vmware-management-pack-donts.html

Read it before you go tweak the VM discovery ;)



I wonder how much space is eaten by the nWorks VMware MP in your environments. I saw occasions where this MP used about 15% of used DB space. You can view this easily by using the latest SCOM R2 Management Pack. This contains a new report, Data Volume by Management Pack. When you follow Cameron's advice and disable some VM monitors, DB instance usage for this MP will likely decrease.



Best regards,

Michiel Wouters]]> Thu, 15 Apr 2010 09:54:00 GMT http://www.systemcentercentral.com/BlogDetails/tabid/143/indexId/63843/Default.aspx#comment-617
I think we may have communicated on the Veeam forums before? If so, I know you have encountered two issues with the nworks version you have now:

1. Certain metrics sometimes report very high values.

2. Certain events sometimes are repeated

Both of these can cause duplicate/false alerts.



I can tell you that both of these issues are fixed in v5.5. We will have a Release Candidated for 5.5 available next week, and full release planned very soon after.



I'm sorry you haven't had a 100% satisfactory experience with nworks so far - but please engage with our support again, and we can get

you the 5.5 build (RC or GA) as soon as possilbe.

Please feel free to CC me on your communications - alec dot king at veeam dot com.



Regards

Alec ]]> Wed, 14 Apr 2010 06:22:50 GMT http://www.systemcentercentral.com/BlogDetails/tabid/143/indexId/63843/Default.aspx#comment-615
Since we deployed, we are still struggling to tune the alerts. Our VM admins have configured their outlook to send alerts to the deleted items.

Thanks for this article, i am going to give a thorough read again and work on tuning the alerts accordingly.. ]]> Tue, 13 Apr 2010 20:45:14 GMT http://www.systemcentercentral.com/BlogDetails/tabid/143/indexId/63843/Default.aspx#comment-613


Re: how nworks has 'less functionality for the System Center user'...

Not true, actually. I wrote the MP from the ground up for Ops Mgr 2007, and there is a lot of key functionality that leverages specific Ops Mgr features - such as our integration of data from a VMware VM with the Ops Mgr agent running inside that VM.

Pretty specific to Ops Mgr, that one :-)



Re: failover - not sure what you mean about "overloading SCOM". We have a scalable centrally managed distributed architecture - that's how we avoid 'overloading SCOM'. And we have fault-tolerant HA monitoring capability, because this is a requirement for enterprise customers.



Re: Knowledge Base - yes indeed, our KB includes links to external articles. As most good KBs should. However we also have plenty of built-in knowledge contained there, leveraged from our years in the market and our status as VMware partners with 'VMware Ready' certification.



Re: a 'deep view' of CPU and memory - we have 80+ performance metrics in the MP. Fifteen specifically on memory for VMs.

And more on Resource Pools, on Hosts, on Clusters, and we watch for 150+ events from VC....I think we have some depth :-)



The final point on 'managing beyond the virtual layer' - I already addressed in my first point I believe. The nworks MP will integrate VMware monitoring data with the apps and services running inside a VM. Allowing true 'end-to-end' monitoring perspective.



We also will be at MMS, previewing our new nworks 5.5 - more enhancements to our core Ops Mgr MP for VMware, and now featuring our PRO Pack integration - for automation of VMware management in System Center Virtual Machine Manager. See you there! ;-)



Alec King

Senior Product Manager

Veeam Software]]> Mon, 12 Apr 2010 17:10:24 GMT http://www.systemcentercentral.com/BlogDetails/tabid/143/indexId/63843/Default.aspx#comment-608


I have not used BridgeWays VMware MP (it may also be great for all I know), but not really looking to change.]]> Mon, 12 Apr 2010 15:55:41 GMT http://www.systemcentercentral.com/BlogDetails/tabid/143/indexId/63843/Default.aspx#comment-607
This series focuses on tuning tips for selected management packs; this particular blog posting is specifically related to the Veeam nworks management pack, which we had the opportunity to deploy into production.

We are aware of BridgeWays and their management packs and often recommend them for clients. ]]> Mon, 12 Apr 2010 15:29:03 GMT http://www.systemcentercentral.com/BlogDetails/tabid/143/indexId/63843/Default.aspx#comment-606


This is why in a shot period of time BridgeWays VMware MP is used by some of the largest Systems Center users, because of the depth of monitoring and seamless integration with Microsoft the product is easier to install and learn. In the failover situation above situation BridgeWays will generate an alert if the collector becomes unavaialable and provides a task in the SCOM console for restarting... just one of many example how BridgeWays was designed exclusively for the Systems Center user.



BridgeWays KB works self contained in SCOM... Veeam relies on 3 external site.



BridgeWays provide much deeper look at CPU and memory usage (actie vs consumed) from a given pool... etc



BridgeWays allows you to use SCOM and SCCM to trigger tickets and manage beyond the virtual layer and into the complete SLA service stack by providing views into the application, database, and Hypervisors such as VMware and HyperV.



For those MVP authors or Microsoft users that would like to learn more about BridgeWays MPs, look at or website or drop by at the 2010 MMS... we would enjoy meeting you.



http://www.bridgeways.ca/]]> Sun, 11 Apr 2010 23:24:44 GMT http://www.systemcentercentral.com/BlogDetails/tabid/143/indexId/63843/Default.aspx#comment-604