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