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@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 :|