Every once in a while I see something in a product that just doesn’t seem right. I have used SCVMM every day for years but somehow overlooked this this minor bug that caught my eye the other day.
In the screen shot below I am viewing all VMs sorted by CPU usage. As you can see there are some VMs that seem out of place. XP_Test is listed at 0% in the GUI, but in the number 4 position of heaviest CPU usage. It is also off which makes sense that it would be 0%, but not the 4th highest CPU usage.
This got me thinking about where all the data for SCVMM comes from, SQL. I have edited SCVMM SQL tables many times to correct other issues so it makes sense that this is where I might be able to dig into why XP_Test is reporting as it is.
Within the SCVMM SQL tables performance data is not listed under its VM name, but instead is associated with its VMID. In order to find the data I want, I need to first get the VMID. The SCVMM PowerShell command below will get this VMID.
Once you have the VMID, it all comes down to knowing what table the SCVMM VM performance data lives (WLC_VMInstance), and using a SQL SELECT statement from within the SQL Management Console to find the information.
Looking at the results section from the SQL query, you can see that my XP_Test VM is reporting 31% CPU utilization, which, if that value was valid, would have put it 4th overall in my CPU Utilization. Since the system is off, something went wrong with reporting correctly to SQL even though the GUI has the value correct at 0%, but incorrectly sorted due to the incorrect value in SQL.
By no means is this a large bug and the correction would be to manually modify table entry , but this is a good example of where the real data for SCVMM resides and why you should be knowledgeable about SQL if you use SCVMM. Knowing how the tables are laid out and where specific data resides will help you tremendously in understanding the product and correcting occasional incorrect statuses or performance data.