qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC][PATCH 8/8 v3] introduce a new monitor command 'du


From: andrzej zaborowski
Subject: Re: [Qemu-devel] [RFC][PATCH 8/8 v3] introduce a new monitor command 'dump' to dump guest's memory
Date: Wed, 21 Dec 2011 03:42:37 +0100

On 20 December 2011 17:25, Eric Blake <address@hidden> wrote:
> On 12/20/2011 02:15 AM, Wen Congyang wrote:
>> Signed-off-by: Wen Congyang <address@hidden>
>> ---
>>  Makefile.target |    8 +-
>>  dump.c          |  452 
>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>  dump.h          |    4 +
>>  hmp-commands.hx |   16 ++
>>  monitor.c       |    3 +
>>  qmp-commands.hx |   24 +++
>>  6 files changed, 503 insertions(+), 4 deletions(-)
>>  create mode 100644 dump.c
>>
>> +++ b/qmp-commands.hx
>> @@ -469,6 +469,30 @@ Notes:
>>  EQMP
>>
>>      {
>> +        .name       = "dump",
>> +        .args_type  = "file:s",
>> +        .params     = "file",
>> +        .help       = "dump to file",
>> +        .user_print = monitor_user_noop,
>> +        .mhandler.cmd_new = do_dump,
>> +    },
>
> From a libvirt perspective, we would like the option to be able to pass
> in an already-open fd rather than just a file name.  This is possible if
> the 'file' argument is required to start with '/' for an absolute path,
> vs. 'file:name' for an fd previously passed in via the getfd monitor
> command.
>
> Also, does this command block?  It sounds like it is long-running, which
> means it probably needs to be asynchronous, as well as issue an event
> upon completion, so that other monitor commands can be issued in the
> meantime.

Note that it needs to stop the VM and it'd need to prevent other
commands from resuming if this command becomes asynchronous, like
during migration.

Cheers



reply via email to

[Prev in Thread] Current Thread [Next in Thread]