VMware Tools » boche. VMware v. Evangelist. VMware introduced the VMware Descheduled Time Accounting Service as a new VMware Tools component in ESX 3. The goal was to account for inconsistent CPU cycles allocated to the guest VM by the VMkernel to provide accurate performance statistics using standard performance monitoring tools within the guest VM. Although the service was not installed and enabled with VMware Tools by default, nor did it ever escape the bonds of experimental support status, I found the service to be both stable and reliable and it was a standard installation component in one of my production datacenters. One caveat was that the service only supported uniprocessor guest VMs having a single v. CPU. The VMware Descheduled Time Accounting Service was deprecated in VMware v. Sphere. More accurately, it was sort of replaced by a new v. Sphere feature called Virtual Machine Performance Counters (Integrated into Perfmon). To quote VMware: “Virtual Machine Performance Counters Integration into Perfmon — v. Sphere 4. 0 introduces the integration of virtual machine performance counters such as CPU and memory into Perfmon for Microsoft Windows guest operating systems when VMware Tools is installed. With this feature, virtual machine owners can do accurate performance analysis within the guest operating system. See the v. Sphere Client Online Help.”The v. Sphere Client Online Help has this to say about Virtual Machine Performance: “In a virtualized environment, physical resources are shared among multiple virtual machines. Some virtualization processes dynamically allocate available resources depending on the status, or utilization rates, of virtual machines in the environment. VMware Player is an easy-to-use application will offer users the possibility to run any virtual machine on their computer. Used by MajorGeeks to test software safely. With it, you can use any virtual machine created by. VMware Tools is a suite of utilities that enhances the performance of the virtual machine's guest operating system and improves management of the virtual machine. Important note about upgrading to ESXi 5.5 Update 3b or later. You may already be aware that installing VMware Tools in a Windows VM configures a registry value which controls the I/O timeout for all Windows disk in the event of a short storage outage. This is to help the guest operating. This can make obtaining accurate information about the resource utilization (CPU utilization, in particular) of individual virtual machines, or applications running within virtual machines, difficult. VMware now provides virtual machine- specific performance counter libraries for the Windows Performance utility. Application administrators can view accurate virtual machine resource utilization statistics from within the guest operating system’s Windows Performance utility.”Did you notice the explicit statement about Perfmon? Perfmon is Microsoft Windows Performance Monitor or perfmon. Whereas the legacy VMware Descheduled Time Accounting Service supported both Windows and Linux guest VMs, its successor currently supports Perfmon ala Windows guest VMs only. It seems we’ve gone backwards in functionality from a Linux guest VM perspective. Another pie in the face for shops with Linux guest VMs. Rant. Folks with Linux shops are still struggling with basic concepts such as Linux guest customization as well as flexibility and automation of VMware Tools installation in the Linux guest OS. If VMware is going to tout their support for Linux guest VMs, I’d like to see more of a commitment than what is currently being offered. There’s more to owning a virtualized infrastructure than powering on instances on top of a hypervisor. Building it is the easy part. Managing it can be much more difficult without the right tools. Flexibility and ease with in the management tools is critical, especially as virtual infrastructures grow./Rant. The installation of VMware Tools installs two new Performance Objects along with various associated counters: VM Memory. Memory Active in MBMemory Ballooned in MBMemory Limit in MBMemory Mapped in MBMemory Overhead in MBMemory Reservation in MBMemory Shared in MBMemory Shared Saved in MBMemory Shares. Memory Swapped in MBMemory Used in MBVM Processor. Processor Time. Effective VM Speed in MHz. Host processor speed in MHz. Limit in MHz. Reservation in MHz. Shares. Observing some of the counter names, it’s interesting to see that VMware has given us direct insight into the hypervisor resource configuration settings via Performance Monitor from inside the guest VM. While this may be useful for VI Administrators who manage both the VI as well as the guest operating systems, it may be disservice to VI Administrators in environments where guest OS administration is delegated to another support group. The reason why I say this is that some of these new counters disclose an “over commit” or “thin provisioning” of virtual hardware resources which I’d rather not reveal to other supports groups. What they don’t know won’t hurt them. Revealing some of the tools in our bag of virtualization tricks may bring about difficult discussions we don’t really want to get into or perhaps provoke the finger of blame to be perpetually pointed in our direction whenever a guest OS problem is encountered. I’ve grabbed a few screen shots from my lab which show the disparity between native Perfmon metrics and the new v. Sphere Virtual Machine Performance Counters. In this example, I compare %Processor Time from the Perfmon native Processor object against the %Processor Time from the VM Processor object which was injected into the VM during the v. Sphere VMware Tools installation. It’s interesting to note, and you should be able to clearly see it in the graph, that the VM Processor %Processor time is consistently double that of the Perfmon native Processor % Processor Time counter. Consider this when you are providing performance information for a guest VM or one of its applications. If you choose the native Perfmon counter, you could be reporting performance data with 1. This is significant and if used for capacity planning purposes could lead to all sorts of problems. One other important item to note is that you may recall I said towards the beginning that the legacy VMware Descheduled Time Accounting Service only supported uniprocessor VMs. The same appears to be true for the new v. Sphere Virtual Machine Performance Counters. In the lab I took a single CPU VM which had the v. Sphere Virtual Machine Performance Counters, and I adjusted the v. CPU count to 4. After powering on with the new v. CPU count, the v. Sphere Virtual Machine Performance Counters disappeared from the pulldown list. VMware needs to address this shortcoming. Performance statistics on v. SMP VMs are just as important, if not more important, than performance statistics on uniprocessor VMs. I’m the product manager for the feature and wanted to reach out to on your findings and feedback regarding the feature. First off, thanks for the detailed post on the intricacies of the feature and the screenshots. I think this post would be very helpful to the community! More importantly, vmdesched adds overhead to the guest and is not compatible with some of the newer kernels out there and so the Perfmon integration is our answer to improve on the current state and provide accurate CPU accounting to VM owners that can be deployed in production and is integrated well with VMware Tools for out- of- box functionality. Linux support for accurate counters. The Perfmon integration in v. Sphere 4. 0 leverages the guest SDK API to get to the accurate counters from the hypervisor and that is available on Linux GOS as well. All you need is to have the VMware Tools installed to get access to the guest SDK interface. We couldn’t provide something like Perfmon on Linux since there aren’t many broadly used tools/APIs that we can standardize on. There are some discussions internally to solve the accounting issue on Linux guests in a much simplified manner but I can’t go into the specific details at this time. Rest assured, I can tell you that we are looking into the problem for Linux workloads. On a side note, the Perfmon implementation exposes the two new counter groups through WMI (you can almost think of the Perfmon integration as a WMI provider that sits on top of the guest SDK interface and provide access to the counters). What this means is any in- guest agent, benchmarking, reporting tool etc. The programming guide for v. Sphere guest SDK 4. The list of available perf counters is in Page 1. PDF (Accessor functions for VM data). You can in fact use the older 3. SDK API as well if you want to implement something that works with existing VI3 environments (yes, this SDK has been around for a while!). The only difference is that the v. Sphere version of the API has a few extra counters but you will get access to the important counters such as CPU utilization in the older API itself. Interesting feedback that I’ll take back to engineering This is something that we need to think about for sure. Perfmon? I’m really surprised with your observations after moving to a 4 v. CPUs. Not sure what’s going on but AFAIK, we report the . What that means is regardless of how many CPUs in- guest, we do provide the . Maybe you may have run into a bug. I’ll check with engineering on this anyways to confirm my understanding. Just so you know we have a “standalone” version of the Perfmon tool that works with existing VI 3. We’ve posted details about this experimental tool and the binaries on our performance blog here: http: //communities. The reason I mentioned the standalone version is because on my test box running 3. Perfmon, I was able to see the . I haven’t yet tested your findings on a v. Sphere test box yet but I look into it. I haven’t tested the same standalone version of Perfmon on a v. Sphere 4. 0 setup (with 4. I wouldn’t be surprised if the standalone version does work. You may want to snapshot the VM before you attempt this though so you can rollback. Some background. Also, what we heard is that VI admins didn’t want to give out VI client access to VM owners whenever they wanted to look at “accurate” counters for CPU utilization. In fact, the memory counters in Perfmon were sort of a bonus since it was already available in the guest SDK interface Importantly, other counters when measured inside the guest such as Memory, Disk and Network don’t really suffer from accounting problems (i. So the numbers for Disk, Memory and Network when captured inside the Windows guest will be the same as the VI client.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
January 2017
Categories |