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

Re: [libvirt] [PATCH 0/2 v3 use qemu's dump-guest-meory when vm uses host device

On 04/19/2012 02:45 AM, Wen Congyang wrote:
> At 04/19/2012 04:38 PM, Daniel P. Berrange Wrote:
>> On Thu, Apr 19, 2012 at 09:03:16AM +0800, Wen Congyang wrote:
>>> Currently, we use migrate to dump guest's memory. There is one
>>> restriction in migrate command: the device's status should be
>>> stored in qemu because the device's status should be passed to
>>> target machine.
>>> If we passthrough a host device to guest, the device's status
>>> is stored in the real device. So migrate command will fail.
>>> We usually use dump when guest is panicked. So there is no need
>>> to store device's status in the vmcore.
>>> qemu will have a new monitor command dump-guest-memory to dump
>>> guest memory, but it doesn't support async now(it will support
>>> later when the common async API is implemented).
>>> So I use dump-guest-memory only when the guest uses host device
>>> in this patchset.
>> Hmm, doesn't the new command generate dump files in a totally
>> different format to the existing command ?  If so I don't
>> think it is nice behaviour to silently switch between 2 different
>> dump formats depending on the XML config.  I think we'd want some
>> kind of flag to specify what format is desired.
> Agree with it. But the new command is not a async command, and it
> will block the other operation. So I only use it when the vm uses
> host device(migrate command will fail in this case).
> The new command will be converted to async command later(after
> async API is implemented). I think we can allow the user specify
> the format when the new command is async command.

You missed the point.  We need 2 flags - one now that says whether to
dump via migrate-to-file or via dumping memory (I'd name it
VIR_DOMAIN_CORE_DUMP_MEMORY_ONLY), and another flag later to state
whether to block the dump or whether to do the dump asynchronously
(similar to the recent block-job-cancel conversion, I'd name it

In other words, the user should be able to choose which format they get,
for 3 of the 4 combinations of user's XML vs. available qemu commands:

                      hostdev             no hostdev
flag = 0              error               migrate-to-file
flag = MEMORY_ONLY    dump-guest-memory   dump-guest-memory

and the choice of async or blocking is orthogonal to the above choice.

Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

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