On Fri, 2017-09-01 at 11:45 -0400, John Ferlan wrote:
Documents some changes that have slipped through the cracks during the development cycle.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> --- Changes from [v1]:
* rebase on top of master * remove the part about guests no longer disappearing if the QEMU binary is missing, since Peter already documented that
[v1] https://www.redhat.com/archives/libvir-list/2017-September/msg00030.html
docs/news.xml | 76 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 76 insertions(+)
Hrmph... Guess we have to get better at remembering this when we do reviews as the last few release cycles there's been a need to update news.xml appropriately at the last moment...
Yeah, we haven't gotten as good at this as I hoped we would have by now. Even I forgot to update the release notes once during this development cycle! .-.
+ <change> + <summary> + qemu: Implement editing guest configuration for managed save files + </summary> + <description> + New <code>managedsave-define</code>, <code>managedsave-edit</code> + and <code>managedsave-dumpxml</code> commands have been added to + <code>virsh</code> to allow editing the guest configuration for + managed save files just like it was already possible for unmanaged + save files. + </description> + </change>
FWIW:
https://www.redhat.com/archives/libvir-list/2017-August/msg00953.html
No one ACK'd it yet... The 1/2 of the v2 series was pushed from the v1 posting, but v2 looks lost in the volume ;-(
IDC how you decide to "handle" that - either apply Kothapally's change or go with yours...
I've dropped this hunk and pushed the author's version.
+ <change> + <summary> + apparmor: Update for QEMU 2.10 compatibility + </summary> + <description> + Starting with version 2.10, QEMU locks disk images and NVRAM files
The way this reads it seems it could be libvirt 2.10... I'd go with "QEMU 2.10" (although some will point out it's possible to backport things into earlier versions)...
I don't think there's much room for confusion, but there's also no harm in being explicit :)
+ <change> + <summary> + daemon: Fix <code>--verbose</code> option
Should we state for all the daemon's fixed? Looks very strange naked like this unless you know "daemon" means more than one place.
Fair enough, I hadn't realized that myself :) I changed the structure quite a bit, hopefully it's not a complete trainwreck.
Reviewed-by: John Ferlan <jferlan@redhat.com>
Pushed now, thanks for the review. -- Andrea Bolognani / Red Hat / Virtualization