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(a)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?
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
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 :|