On Wed, 24 Apr 2013 10:23:58 -0600 Eric Blake <ebl...@redhat.com> wrote:
> On 04/24/2013 09:50 AM, Luiz Capitulino wrote: > >> This raises an interesting question about introspection - how will > >> management apps (such as libvirt) be able to determine whether the > >> paging command is supported for a given architecture? Do we need to > >> expand the 'MachineInfo' QMP datatype so that 'query-machines' can tell > >> us whether a given machine will support or reject attempts to set > >> 'paging':true during 'dump-guest-memory'? > > > > Is libvirt going to query this for the automatic dump feature? > > Probably. Right now, libvirt has already exposed the paging option to > users, and uses the try-and-fail approach of reporting back any error > message from QMP if the dump command fails. But we've had error reports > in the past against libvirt that the error reported by qemu isn't always > the sanest, and that sometimes it is much nicer to have libvirt detect > in advance that a qemu command cannot succeed than it is to do a > try-and-fail approach. There's also a matter of clean rollbacks; > libvirt has to set up some state when starting a dump command, and has > to undo that state if try-and-fail reported an error; whereas a > capability detection can avoid having to set up any state in the first > place. Fair enough. So, we have to choose a good and consistent method for reporting arch-dependent capabilities. I like what you suggest, but there are two issues with it. First, we're adding query-<command>-capabilities commands for some commands, so I feel that reporting this capability through MachineInfo is inconsistent. The other issue is that, if we do add this capability to MachineInfo, then we'll have to add future arch-dependent capabilities to MachineInfo as well. I'd prefer query-dump-guest-memory-capabilities myself, although I'm unsure if the proliferation of such commands is a good thing.
