Re: [PATCH v5 1/3] add new virDomainCoreDumpWithFormat API

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

 



On Mon, Mar 17, 2014 at 09:37:46AM +0000, Daniel P. Berrange wrote:
> On Thu, Mar 13, 2014 at 08:42:40AM +0100, Martin Kletzander wrote:
> > 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@xxxxxxxxxxxxxx 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?
>
> I rather prefer it as an enum. Just doing a plain string passthrough
> from the API means that the API ends up exposing impl details of
> QEMU. This has caused us pain the past - eg nic model XML used to just
> be a free-form string, instead of an enum parsed string. The result
> was the same NIC model ended up with different names across different
> hypervisors. Using an enum / int is good for the API, even if it means
> we need to make changes if QEMU adds more formats
>

That makes sense, thanks for the explanation.  That's why I was
asking.

Martin

>
>
> Regards,
> Daniel
> --
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org              -o-             http://virt-manager.org :|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Attachment: signature.asc
Description: Digital signature

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]