qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Olga Levy <olgalevy91@gmail.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Live viewing qemu running image
Date: Tue, 29 May 2018 14:53:38 -0500	[thread overview]
Message-ID: <7f7124d6-2775-9b5c-e647-6091aebe67a4@redhat.com> (raw)
In-Reply-To: <CA+6CiVCSPCQ-3iBa=ivJtqsbsV2G9MxTndDFXkMBk2AgWHxPOA@mail.gmail.com>

On 05/29/2018 07:33 AM, Olga Levy wrote:
> Hi,
> 
> Nice to meet you. I'm a new security engineer and working on a prototype
> using QEMU.
> 
> What I need is to collect running image internal data (like running
> processes, netstat, files modification, etc.) but without running any
> process inside. I mean, doing it from "outside" (I need Qemu support).
> 
> For example,
> 
> How can I live view FS of a running image?

In general, you can't - qemu does not know and does not care what 
operating system the guest code is running, let alone what file systems 
that guest has structured on top of the raw storage that qemu is 
emulating for the guest.  What you are asking for is akin to asking 
Intel to add a new register to their chips that will tell you how many 
open files a bare-metal processor is managing, while telling the chip 
designers that they are not permitted to know whether the user will 
install Windows, Linux, or some other operating system on the machine 
using that chip.

With some effort and knowledge about specific types of guests, it IS 
possible to take snapshots of a guest, and then peek at specific memory 
locations or read the (hopefully consistent) state of the disk at the 
time of the snapshot to learn things about that guest.  And in fact, the 
libguestfs project does a LOT of those hacks, for several mainstream 
operating systems where the effort of writing the hacks is not too much 
of a maintenance burden.  But that's more a question for the libguestfs 
list, as interacting with the guest (or a snapshot of the guest) is 
outside the realm of things that qemu directly targets.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

  reply	other threads:[~2018-05-29 19:53 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-29 12:33 [Qemu-devel] Live viewing qemu running image Olga Levy
2018-05-29 19:53 ` Eric Blake [this message]
2018-06-01 12:26 ` Stefan Hajnoczi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7f7124d6-2775-9b5c-e647-6091aebe67a4@redhat.com \
    --to=eblake@redhat.com \
    --cc=olgalevy91@gmail.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).