[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [tracecompass-dev] New feature: Virtual Machine Analysis
|
Hi Geneviève,
Looks quite interesting! It does introduce a lot of new concepts that
were not there before, so we might not get it perfectly right the first
time. As long as we can iterate on the solution eventually it should
become something good. :)
We discussed recently about extracting the common parts of Linux kernel
traces into a separate plugin. How would the VM analysis fit into this?
I assume it could benefit from it, because then the "kernel" part of the
VM analysis could be provided by any of the kernel tracers.
Should something similar be done for the userspace traces too?
Cheers,
Alexandre
On 11/20/2014 03:20 PM, Geneviève Bastien wrote:
Hello all,
I want to introduce a new feature I will start pushing soon: the
Virtual Machine Analysis, developed by Mohamad Gebai as his master's
project at Dorsal.
I have opened the following feature request (bug) to discuss the
feature [1]
The full patch series has a few pre-requisites patch series:
* The Event Criterion concept series by Alexandre Montplaisir,
discussed in bugzilla, needed by the Virtual Machine unit tests [2].
Series starts here [3]
* The event request coalescing series by Bernd Huffman, discussed in
the thread "Event requets precendence" on this mailing list, needed to
make sure of the consistency and correctness of the analysis. Series
starts here [4]
* Description of the feature:
The Virtual Machine Analysis correlates the traces from a VM host and
guest machines. Typically, kernel and/or UST traces are taken from all
hosts and guests and the traces are put in an experiment, synchronized
(somehow, either with TCP events or hypervisor-specific way), then the
analysis takes place.
The analysis tracks the state of each virtual CPU, which can be either
running guest code, running code from the hypervisor, or not running
at all on the host machine.
This information from the virtual CPU is then correlated with that
from that of the LTTng Kernel Analysis to see the real status of a
thread (it can be running from the guest's point of view, but actually
preempted on the host machine). The first view that will be pushed
shows the status of virtual CPUs and virtual threads.
* Implementation details:
Changes to the Lttng Kernel Analysis: Some methods have been added to
this analysis, so that instead of directly using its state system
(that would require the Virtual Machine Analysis to know about the
internal structure of the state system), we can query the analysis and
it will return its data. Those methods can also be reused by views and
other analysis to retrieve analysis-specific data.
Hypervisor models: Any hypervisor (Qemu/KVM, VirtualBox, LXC, vmware,
etc) will share some concepts, like virtual CPUs, virtual machines,
hypervizor-mode vs running, finding out who is a guest on which host,
etc. But how to link trace data to those concept will vary for each. A
generic model has been described with some base classes and
interfaces, but each hypervisor needs to implement it for itself.
QEMU/KVM implementation of the model: The hypervisor used to develop
this analysis is Qemu, with KVM. KVM being a kernel module, some
tracepoints are integrated in the lttng kernel traces.
The analysis itself: The Virtual Machine Analysis has a state system
to track the status of each virtual CPU. It also depends on each
machine's Lttng Kernel Analysis. Some methods of the analysis use data
from both these analysis and return the required information.
Unit Tests: The analysis is unit tested with stub traces.
Virtual CPU View: A first view will be introduced that displays each
virtual machine on a host, the status of its Virtual CPUs and the
correlated status of its threads.
Documentation: of course!
As I push patches, they will be available under the "virtual machine"
topic [5]. In the meantime, the not split development branch is
available here [6].
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=452581
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=451411
[3] https://git.eclipse.org/r/#/c/36131/
[4] https://git.eclipse.org/r/#/c/35965/
[5]
https://git.eclipse.org/r/#/q/status:open+project:tracecompass/org.eclipse.tracecompass+branch:master+topic:%22virtual+machine%22,n,z
[6]
http://git.dorsal.polymtl.ca/~gbastien?p=org.eclipse.tracecompass.git;a=shortlog;h=refs/heads/vm_analysis
Question: Where shall I put it? In the lttng.kernel.* plugins? Knowing
that some hypervisors might use UST traces or other trace types to
implement the model... Or in new plugins [lttng|tmf].analysis.vm.*?
Thanks,
Geneviève
_______________________________________________
tracecompass-dev mailing list
tracecompass-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/tracecompass-dev
