[libvirt] [PATCH for 5.1.0] news: Update for 5.1.0 release

[Andrea Bolognani]

On Thu, 2019-02-28 at 11:43 +0100, Michal Privoznik wrote:
> Not exhaustive list of new features, improvements and bugfixes.
> 
> Signed-off-by: Michal Privoznik <mprivozn at redhat.com>
> ---
>  docs/news.xml | 201 ++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 201 insertions(+)

First of all, thanks for agreeing to taking care of this! And
you've been more thorough than I've ever cared to be when updating
release notes, too O:-)

[...]
> +      <change>
> +        <summary>
> +          qemu: add support for encrypted VNC TLS keys
> +        </summary>
> +        <description>
> +          Use the password stored in the secret driver under the uuid
> +          specified by the vnc_tls_x509_secret_uuid option in qemu.conf.

vnc_tls_x509_secret_uuid can be enclosed in <code> elements.

[...]
> +      <change>
> +        <summary>
> +          Detect CEPH and GPFS as shared FS
> +        </summary>
> +        <description>
> +          When starting a migration libvirt does some sanity checks to

s/does/performs/

> +          make sure domain will be able to run on destination. One of
> +          requirements is that disk has to either be migrated too or

Please add "the" in front of the words "domain", "destination",
"requirements" and "disk".

[...]
> +      <change>
> +        <summary>
> +          Allocate qemu memory at the configured NUMA nodes from start

This can be

  qemu: Allocate memory [...]

> +        </summary>
> +        <description>
> +          Libvirt used to just start qemu, let it allocate memory for

s/qemu/QEMU/

> +          the guest and then use CGroups to move the memory to
> +          configured NUMA nodes. This is suboptimal as huge chunks of
> +          memory have to be moved. Moreover, this relies on ability to
> +          move memory later which is not always true. Set process
> +          affinity corretly from the start so that memory is allocated

s/corretly/correctly/

> +          on the configured nodes from the beginning.
> +        </description>
> +      </change>
> +      <change>
> +        <summary>
> +          Support for newer wireshark

s/wireshark/Wireshark/

[...]
> +      <change>
> +        <summary>
> +          More use of VIR_AUTOFREE() and friends
> +        </summary>
> +        <description>
> +          Usuaully, this would be viewed as an internal change that
> +          should not concern users. However, since libvirt is written in
> +          memory unsafe language some memory leaks might have been
> +          actually fixed by using VIR_AUTOFREE(). It is definitely step
> +          towards defensive programming.
> +        </description>
> +      </change>

Despite your explanation, I still don't think this entry belongs to
the release notes, especially without evidence that some very
significant and impactful memory leak has been fixed in the process.

[...]
> +      <change>
> +        <summary>
> +          qemu: Fix i6300esb watchdog hotplug on Q35
> +        </summary>
> +        <description>
> +          Due to a bug libvirt was not allocating PCI address for
> +          watchdog device nor it was telling it to qemu. This lead qemu

s/qemu/QEMU/g

[...]
> +      <change>
> +        <summary>
> +          qemu: Fix guestfwd hotplug/hotunplug
> +        </summary>
> +        <description>
> +          Unaware to libvirt developers whether somebody actually uses
> +          guestfwd, it's hotplug and hotunplug was fixed. Libvirt used
> +          to use incorrect monitor command.

I'm not quite clear on what the first part of the sentence is
supposed to mean... Are you trying to say that this has been broken
for so long that it makes us wonder whether anyone's using the
feature at all? If so, that's not really relevant to the release
notes and can be left out.

> +        </description>
> +      </change>
> +      <change>
> +        <summary>
> +          qemu: Forbid cdroms on virtio bus

s/cdroms/CDROMs/

> +        </summary>
> +        <description>
> +          Attempting to create an empty virtio-blk drive or attempting
> +          to eject it results into an error.  Forbid configurations
> +          where users would attempt to use cdroms in virtio bus.

Again here.

[...]
> +      <change>
> +        <summary>
> +          qemu: Fix block job progress reporting and advocate for READY event
> +        </summary>
> +        <description>
> +          In some cases qemu can get to 100% and still not reach the

s/qemu/QEMU/

> +          synchronised phase. Initiating a pivot in that case will fail.

https://www.youtube.com/watch?v=R2u0sN9stbA&t=1m9s :)

> +          Therefore it is strongly adviced to wait for

s/adviced/advised/

> +          VIR_DOMAIN_BLOCK_JOB_READY event which does not suffer from

VIR_DOMAIN_BLOCK_JOB_READY could have <code> around it.

> +          this problem.
> +        </description>
> +      </change>
> +      <change>
> +        <summary>
> +          qemu: Don't format image properties for empty -drive
> +        </summary>
> +        <description>
> +          If a -drive has no image, using image properties makes qemu

s/qemu/QEMU/


With all of the above taken care of,

  Reviewed-by: Andrea Bolognani <abologna at redhat.com>

-- 
Andrea Bolognani / Red Hat / Virtualization