Virtual machines have been around on Windows for many years now, and for the most part you treat the exactly as if it was a physical machine. In particular with respect to a tool like PerfView, we expect it to 'just work' and I don't have to say anything special. (Actually there is one things different, which is that the 'CPU Ctrs' Textbox on the collection dialog doesn't do something useful, see Cpu Ctrs TextBox for details).
The trend in virtual machines (VMs) is to make them super light weight, so that they are so cheap you use them more frequently. The main way of doing this is to share more of the VM with its underlying host, so that only what REALLY needs to be distinct for each VM is actually unshared. These light weight VMs are called containers and Windows started supporting these light weight containers (Microsoft calls them Windows Server Containers) a few years back. See Windows Container Quick Start for more. A tool/system called Docker is used to create, configure an run applications in these light weight operating system images.
I would have liked to say 'PerfView' 'just works like you would expect in these Docker containers, and I would be almost right. But there are enough caveats that I wrote some documentation on using PerfView in windows Docker containers. Without repeating that documentation much the main points are
- ETW (and PerfView) work in Windows Docker Containers
- However you need a new enough version of the Windows OS (Win 10 1709 or later)
- You only get the basic kernel events (CPU + Context Switch, but that covers most scenarios.
- Because the OSes used in containers can't display a GUI, PerfView has to be used with the /logfile option as described in its automation documentation.
- But other PerfView 'just works'
- You can even collect on Windows Nanoserver OS, however you can't use PerfView but stripped down version called PerfViewCollect.
So if you are using Windows Docker containers for your app, and want to do a performance investigation, know that it is possible to do so, and you should read the PerfView Docs on Windows Containers to learn more. This documentation is also part of the PerfView help, so you can find it there if that is more convenient.
Once you have collected the data from the container, you copy it to a windows machine with a GUI and analyze the trace.
There is one final caveat: as of right now (8/2016) there seem to be an OS problem in what is called 'merging' where the information needed to look up symbolic information from Microsoft's is correctly added to the data file. The exact conditions where it fails is not really clear (it works for some DLLs but not others in the same trace), but the symptom is that sometimes perfView's 'Lookup Symbols' on a native Microsoft-supplied DLL (typically some OS DLL), will fail saying that that data file may not be 'merged' properly. For .NET applications this s rarely a problem since you are much more interested in the app itself and the .NET Framework, and not the OS DLLs, but for other scenarios it may be an issue. There is a bug filed on this, and we will see what we learn.