[libvirt] [PATCH v5 1/3] add new virDomainCoreDumpWithFormat API

Martin Kletzander mkletzan at redhat.com
Thu Mar 13 07:42:40 UTC 2014


On Wed, Mar 12, 2014 at 09:29:55AM -0600, Eric Blake wrote:
> On 03/12/2014 09:04 AM, Martin Kletzander wrote:
> > On Thu, Mar 06, 2014 at 09:35:47AM +0000, qiaonuohan at cn.fujitsu.com wrote:
> >> --memory-only option is introduced without compression supported. Therefore,
> >> this is a freature regression of virsh dump. Now qemu has support dumping memory
> >
> > s/freature/feature/
> >
> > but I would not use the word "regression" since that never worked.
> > Also it would help mentioning the commit ID or a version it
> > got included in qemu.  On that note, is there a possibility of
> > of introspection of that feature, so we can gracefully error out in
> > case older qemu is used?
>
> Yes - qemu 2.0 is adding 'query-dump-guest-memory-capability', which can
> be used for two purposes: 1. if this command exists, 'dump-guest-memory'
> supports the new optional 'format' argument; and 2. calling this command
> will return a list of WHICH formats are supported by the given qemu
> binary (since configure-time choices can disable some of the formats
> from actually working).  So you need to have a patch that modifies
> src/qemu/qemu_capabilities.[ch] to do the probing and set capability
> bits, so that we can gracefully error out when talking to a too-old
> qemu, or requesting a format that was not compiled in to a new qemu.
>

Great.  Could we have the compression parameter just as an arbitrary
string then (properly checked for, etc.) so there is no need to adapt
our code to qemu format additions?

>
> >
> > Looking at the rest, I rather fixed what I wanted to change in my repo
> > and here's the diff I'd squash in.  Let me know if you're OK with
> > that.  I'll still want an ACK from someone in order to push that,
> > though.  And feel free to ask about that changes as well.
>
> I suppose the capability detection could be done as an add-on patch, but
> I'm personally thinking it's better to hold off on this series until ALL
> the work is done, so we don't forget to do the capability detection work.
>

Definitely, I just asked this question in the wrong patch, the
detection and use of the capability should be in 2/3 or in separate
one.

Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140313/b559b25d/attachment-0001.sig>


More information about the libvir-list mailing list