VProbe Toolkit: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
m added new catogory for tracking open source projects from VMware |
||
| (4 intermediate revisions by the same user not shown) | |||
| Line 3: | Line 3: | ||
This provides an interactive, programmer-friendly interface to VMware's VProbes facility. VProbes is a safe, dynamic technology for instrumenting software running in virtual machines, and the software stack itself. | This provides an interactive, programmer-friendly interface to VMware's VProbes facility. VProbes is a safe, dynamic technology for instrumenting software running in virtual machines, and the software stack itself. | ||
[[Category:SDK]] | * [http://sourceforge.net/projects/vprobe-toolkit/ Sourceforge project vprobe-toolkit] | ||
* [http://www.vmware.com/products/beta/ws/vprobes_reference.pdf official reference] | |||
* [http://www.vmware.com/download/ws/ download] | |||
* [http://communities.vmware.com/community/developer/vprobes VProbes community] | |||
==== Advantages and disadvantages of using VProbe ==== | |||
Debugging your applications/kernel from outside the VM has some big pluses, and some big minuses. On the pro | |||
# Most importantly, VProbes is '''safe'''. Using a kernel debugger or something from within a guest provides some very dangerous opportunities: e.g., you could poke a hole in a critical guest memory structure. Also, kernel debuggers usually stop the target program to allow inspection. VProbes keeps things moving along while data is harvested, so it can be used even on mission-critical, highly available systems. | |||
# VProbes doesn't rely on any in-guest tools. If the target is, for instance, an appliance that doesn't even have a login shell, let alone /usr/bin/top, VProbes works no better or worse. | |||
# It doesn't care what state the guest is in. If the guest is hard hung, or is swapping too hard for a shell to come up, or whatever, VProbes can be a "tool of last resort" to try to harvest information. | |||
# VProbes is also immune to guest attempts to fool it. For instance, malware often tries to change in-guest instrumentation tools to make itself undetectable. Since the VM/hypervisor trust boundary protects vprobes, it is immune to this weirdness. | |||
# VProbes is neutral as to the identity of the guest; since it's machine-level, you can use the same tools for Windows, Linux, Solaris, FreeBSD, MacOS, etc. To the extent the preload scripts work, even some common, but OS-specific, notions, like processes, can be captured. | |||
The big negatives all boil down to the same fundamental problem: the machine abstraction level is sometimes very far away from the application abstraction level. If it's a java application running, for instance, VProbes will sit there telling you: "java.exe is running!" Well, no kidding; you probably wanted to know, e.g., which method invocation it was in. VMware is thinking about ways to bridge that gap, but alas, there's very little to offer for serious discussion at this time. | |||
==== External links ==== | |||
* [http://blogs.vmware.com/vmtn/2008/06/introducing-vpr.html Video introducing VProbes] | |||
* [http://communities.vmware.com/thread/194591 Vprobe-toolkit in Windows] | |||
[[Category:SDK]] [[Category: VMware OSS]] | |||
Latest revision as of 17:33, 19 February 2009
VProbe Toolkit
This provides an interactive, programmer-friendly interface to VMware's VProbes facility. VProbes is a safe, dynamic technology for instrumenting software running in virtual machines, and the software stack itself.
Advantages and disadvantages of using VProbe
Debugging your applications/kernel from outside the VM has some big pluses, and some big minuses. On the pro
- Most importantly, VProbes is safe. Using a kernel debugger or something from within a guest provides some very dangerous opportunities: e.g., you could poke a hole in a critical guest memory structure. Also, kernel debuggers usually stop the target program to allow inspection. VProbes keeps things moving along while data is harvested, so it can be used even on mission-critical, highly available systems.
- VProbes doesn't rely on any in-guest tools. If the target is, for instance, an appliance that doesn't even have a login shell, let alone /usr/bin/top, VProbes works no better or worse.
- It doesn't care what state the guest is in. If the guest is hard hung, or is swapping too hard for a shell to come up, or whatever, VProbes can be a "tool of last resort" to try to harvest information.
- VProbes is also immune to guest attempts to fool it. For instance, malware often tries to change in-guest instrumentation tools to make itself undetectable. Since the VM/hypervisor trust boundary protects vprobes, it is immune to this weirdness.
- VProbes is neutral as to the identity of the guest; since it's machine-level, you can use the same tools for Windows, Linux, Solaris, FreeBSD, MacOS, etc. To the extent the preload scripts work, even some common, but OS-specific, notions, like processes, can be captured.
The big negatives all boil down to the same fundamental problem: the machine abstraction level is sometimes very far away from the application abstraction level. If it's a java application running, for instance, VProbes will sit there telling you: "java.exe is running!" Well, no kidding; you probably wanted to know, e.g., which method invocation it was in. VMware is thinking about ways to bridge that gap, but alas, there's very little to offer for serious discussion at this time.
