Search the Community

Showing results for tags 'vmware'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • From LogicMonitor
    • Product Announcements
    • LM Staff Contributions
    • Community Events
  • LogicMonitor Product Discussion
    • Feature Requests
    • LM Exchange
    • Ask the Community

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start



About Me

Found 15 results

  1. Has anyone had any luck monitoring VMStatus for reboots without using the DaysSinceLastReboot? as this gives a false reading, as it kicks in when the VM is vMotioned. I have tried the GuestState but it looks like the GuestOS isnt in the state for long enough for that to trigger
  2. We would like the ability to generate alarm on events generated within the vSphere event log, I really can't believe this isn't in place already.
  3. Does anyone have a good datasource they are using for monitoring key services on a VMware vSphere ESXi host - e.g. hostd, vpxa, vpxd, mgmt-vmware, etc? Thanks Will
  4. Hello, I'm new to LogicMonitor and we've just got our first vCenter server configured and monitored. I'm trying to figure out why the VMware Virtual Machine Status dashboard is saying "Instance limit exceeded (2000) (other than the obvious - that we exceeded the limit) and how to modify the dashboard to provide some meaningful data and visualizations that we can use. Has anyone else encountered this? And if so do you have a smaller query or dashboard panel that can help correct this? Thanks in advance.
  5. We were running into an issue where disks were not consolidating properly following our backup completing, we are using Veeam with VMware. Since this wasn't included our of the box I have updated the default datasource to include a consolidationNeeded graph and datapoint. consolidationNeeded - Whether any disk of the virtual machine requires consolidation. This can happen for example when a snapshot is deleted but its associated disk is not committed back to the base disk. ( This can cause a problem with performance as it will require more IO and for database servers this can be damaging for high io solutions. Since I am not able to attach XML files, I have copied the exported code below. If you want to do this manually, you will need to modify the active discovery script to the collector attributes script and then add the data point and graph. In the active discovery script make the following changes: In the props_hash def include a line for "'auto.runtime.consolidationNeeded' : vm?.runtime?.consolidationNeeded" make sure you include a comma to separate the values. def props_hash = ['auto.config.alternate_guest_os_Name': vm?.config?.alternateGuestName, 'auto.config.annotation' : vm?.config?.annotation, 'auto.config.firmware' : vm?.config?.firmware, 'auto.config.guest_os_full_Name' : vm?.config?.guestFullName, 'auto.config.guest_os_id' : vm?.config?.guestId, 'auto.config.managed_by' : vm?.config?.managedBy?.type ?: "false", 'auto.config.modified' : vm?.config?.modified?.getTime(), 'auto.config.template' : vm?.config?.template, 'auto.guest.guest_os_family' : vm?.guest?.guestFamily, 'auto.guest.guest_os_full_name' : vm?.guest?.guestFullName, 'auto.guest.guest_os_id' : vm?.guest?.guestId, 'auto.guest.hostname' : vm?.guest?.hostName, 'auto.guest.tools_version' : vm?.guest?.toolsVersion, 'auto.guest.tools_version_status' : vm?.guest?.toolsVersionStatus2, 'auto.hardware.memory_mb' : vm?.config?.hardware?.memoryMB ?: 0, 'auto.hardware.num_cpu' : vm?.config?.hardware?.numCPU ?: 0, 'auto.hardware.num_cores_per_socket' : vm?.config?.hardware?.numCoresPerSocket ?: 0, 'auto.hardware.num_virtual_disks' : vm?.summary?.config?.numVirtualDisks ?: 0, 'auto.hardware.num_ethernet_cards' : vm?.summary?.config?.numEthernetCards ?: 0, 'auto.resource_pool' : vm?.resourcePool?.name, 'auto.resource_pool_full_path' : resource_pool_array.reverse().join(' -> '), 'auto.snapshot_count' : vm?.layoutEx?.snapshot?.size() ?: 0, 'auto.cluster' : esxhost?.parent?.name, 'auto.cluster_full_path' : cluster_path_array.reverse().join(' -> '), '' : esxhost?.name, 'auto.runtime.connection_state' : vm?.runtime?.connectionState, 'auto.runtime.power_state' : vm?.runtime?.powerState, 'auto.runtime.consolidationNeeded' : vm?.runtime?.consolidationNeeded] Test the script against a vcenter server to make sure you are getting a true or false response from a server. In the collector attributes script make the following changes Create a consolidation_states def, this will allow us to translate the value of the boolean to a 0 or 1 def consolidation_states = [ 'false' : 0, 'true' : 1 ] In the Iteration of VMs section, add a line for the def consolidation_Needed value, this is where we are actually translating the value to 0 or 1 with a toString compare. // iterate over vms vms.each { vm -> // Get AD info def wildvalue = vm.MOR.val def power_state = power_states[vm?.runtime?.powerState?.val] def consolidation_Needed = consolidation_states[vm?.runtime?.consolidationNeeded?.toString()] Finally, at the end, create a println to make the value go to standard out // Print that data println wildvalue + ".PowerState=" + power_state println wildvalue + ".ConsolidationNeeded=" + consolidation_Needed Test the script against a vcenter server to make sure you are getting a 0 or 1 response from a server if you are getting a null something is misconfigured. Once you get that working it is just a simple matter of adding a datapoint and graph Datapoint graph
  6. Hi, I just got done working with VMware support on an issue where our ESXi 6.5 hostd process would crash during a booting phase. We eventually traced it back to a bug in some vSAN code that LM monitoring is polling.. It doesn't matter if you're running vSAN in your environment or not. Our work around has been to disable host level monitoring in LM for our ESXi hosts for now and it's been stable ever since. The expected fix is scheduled for release in Q3 2018 from VMware.
  7. Previous versions of VMware datasources had the ability to monitor disk space for VMs via vCenter. Looks like this ability has disappeared after LM fixed a datasource bug in January. We now have 100+ VMs that we monitor via vCenter but no alerts for their disk space. Is this something we are missing by accident, or has LM stripped this functionality on purpose?
  8. VMware "In­-Guest" DataSources - Version 1.0 - LogicMonitor Custom Development Summary: The following provides information and deployment instructions for the application of hypervisor-­level monitoring data - as presented within a Windows virtual machine in LogicMonitor. There are three "In­Guest" VMware DataSources ­- they are: VMware_vSphere_VMperformance_InGuest (locator code: CHLF7C ) VMware_vSphere_VMsnapshots_InGuest (locator code: 9YF42D ) VMware_vSphere_VMstatus_InGuest (locator code: ZMEJ6P ) How it Works: These datasources were cloned from the official LogicMonitor VMware DataSources ­ with ‘_InGuest’ appended to the end of the standard name. They have been altered in the following fashion to apply them 'within' the virtual machine device: A critical feature built into the DataSources is the ability to ‘override’ a vCenter location with ‘esx.url.’ ○ This allows us to apply the DataSource to a VM and point it to vCenter for data. The AppliesTo language is updated to apply the DataSources to Windows Virtual Machines: ○ system.model =~ "Vmware Virtual Platform" && esx.url && esx.user && esx.pass The host property variable is switched from system.hostname to system.sysname: ○ def host = hostProps.get("system.sysname") The Active Discovery of virtual machines is limited to the device hostname to which it is applied: ○ ManagedEntity[] vms = new InventoryNavigator(rootFolder).searchManagedEntity("VirtualMachine","${host}"); Implementation: Three properties are required to be applied to the virtual machine device(s) in LogicMonitor: esx.user esx.pass esx.url in format: https://<vcenter­ip­address>/sdk Once the device properties are present, the AppliesTo language will kick in and the DataSources will apply. Suggestion: create a dynamic group of Windows virtual machines, and set the ‘ESX’ properties at that group level. Notes: ­These DataSources are custom development and officially unsupported by LogicMonitor. Restrict the application of property esx.url to ONLY the virtual machines needed. This property will apply to ESXi hosts if allowed, which impacts vCenter collection and performance. Deploy this in stages - we will be increasing the load on vCenter due to the additional API queries. We do not currently identify Linux VM’s out of the box, for now this is Windows-­only. Automated detection of VM to vCenter relationship is difficult at the device level, hence the need for esx.url. vCenter is the preferred integration point for esx.url, but an ESXi host should also work (until the VM moves.)
  9. Is there a an LM Exhange module similar to/ or a variation of the one below which can alert for VMs if they go offline as long as their properties are tagged with a certain keyword? We have had instances where running VMs go offline but LM does not alert, because of this particular filter. Lookign for a simple module to only alert if VM is down based ona vm tag we can set.
  10. The Windows EventSources monitoring has been very useful for us, and we were hoping to be able to replicate the same with vSphere's logging (vCenter, vpxd, etc). Right now our only alternative is leveraging VMware's "Log Insight" tool, but we were hoping to have this integrated into LogicMonitor so we're not duplicating monitoring across separate monitoring tools.
  11. We have all of our VMs monitored with LogicMonitor which does a good job gathering details from our VMs. However, we have VMware tools installed on all VMs and leave WMI Performance Logging enabled. This VMware tools feature ends up generating a ton of events: 256 and 258 which reference vmGuestLibrary vmStatsProvider alerts. This is just standard behavior of VMware tools since it is pulling logging details in and creates these events. What I am trying to determine is if I can safely disable this WMI performance logging and allow LogicMonitor to still do the WMI calls, and if there is any impact. I am not sure if LogicMonitor relies on this WMI performance logging anyway since I believe it is gathering data directly from Windows and doesn't care that VMware tools is generating anything. Anyone have any insight on this?
  12. I would love to see the "ESX VM" datasource allow grouping its instances by the VDC/Resource Pool in which each VM is contained. Use case: Each VDC in our infrastructure may have different alerting rules. We have many VDCs and most of these VDCs are available directly to customers through vcloud director, allowing them to create their own VMs using names over which we have no control (so we can't use the automated name filters to group them). Customers may add a new VM at any time within their own VDC and they have the option to expand out at will without notifying us. Currently, grouping VMs by their VDC in LogicMonitor is a manual process which gets outdated everytime a new VM is created - which is at least daily. As a workaround, if the LogicMonitor APIs allowed a way to create instance groups and add instances to those groups, we could script this out and just add new VMs into the appropriate groups as the scripts detect that they have been added into the environment, however, it appears that this functionality doesn't exist in the API either.
  13. Need support for IPFIX flows coming out of VMWARE v10. v10 does not use v5 or 9 flows.
  14. These are some simple troubleshooting steps I use when dealing with ESX servers. LogicMonitor has debug tools that can be run in the debug window on the collector the ESX currently assigned collector. The first useful tool is !http. This simply sends a HTTP request to a host and print the response. The ESX API has a few pages we can use that DOES NOT require authentication. This is helpful to test a connection outside of credential issues. For example the below debug command returns “The Web Services Description Language (WSDL) file containing definition of the VMware Infrastructure Management API.” !http What data is returned isn't important, what this command will tell us is can the collector connect to the ESX device or is network infrastructure somehow stopping communication. The next command is !esx and it's a bit more powerful help !esx !esx: query a list of esx performance counter against the given host and print the result usage: !esx [username=foo password=bar] <host> <entityName> <entityType[host|vm|datastore|cluster|resourcepool|hoststatus|cpu|memory|disk|network]> [counter1 [counter2...]] If you don't give the username/password, the agent will use esx.user/esx.pass properties of the host. !esx is a debug tool that allows us to query the VMware API directly in the same way the datasources poll data. To decode the help example let’s run this on the ESX server and the virtual machine “marvin”. The example !esx command is "!esx vc-server esx-name host cpu.usage.average mem.consumed.average" Broken down for the test environment "!esx marvin vm cpu.usage.average mem.consumed.average" If you don't give the username/password, the agent will use the esx.user/esx.pass properties of the host. This is a fantastic way to test the credentials entered into LogicMonitor. You could also push the credentials by using the username= and password= options with the !esx command to verify they work with LogicMonitor. So far we have only tested connectivity which is the most common form of ESX troubleshooting. We can also use the !esx to query individual datapoints in the datasources to ensure the data presented by LogicMonitor is accurate. The command can be built by viewing the datapoint in question. For this example we can use the Cpu Usage counter used in previous examples. Lets take another look at the !esx usage usage: !esx [username=foo password=bar] <host> <entityName> <entityType[host|vm|datastore|cluster|resourcepool|hoststatus|cpu|memory|disk|network]> [counter1 [counter2...]] We know the host is the ESX server, Entity Name is the Virtual Machine Marvin, EntityType can be found in the datapoint which is "VM" and the ESX counter is cpu.usage.average. !esx marvin vm cpu.usage.average cpu.usage.average which will return the value cpu.usage.average=211.0
  15. There are quite a few datasources that require direct access to ESXi hosts when the data is readily available in vCenter. This is painful since establishing permissions to hosts in most environments is tricky at best (confirmed after extended testing done yesterday) and the documentation provided is not complete. The problem is if you just point current DS definitions to vCenter (e.g., hardware), data is acquired, but the DS has no per-host data, it just grabs the data for one host and displays it in that subtree.