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

[John Ferlan]

On 2/28/19 5:43 AM, 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(+)
> 
> diff --git a/docs/news.xml b/docs/news.xml
> index 9c5ae7e8a3..813f1a93e3 100644
> --- a/docs/news.xml
> +++ b/docs/news.xml
> @@ -69,8 +69,104 @@
>            Model Specific Registers (MSRs) reads and writes.
>          </description>
>        </change>
> +      <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.
> +        </description>
> +      </change>

Is this a new feature or improvement to current support?

> +      <change>
> +        <summary>
> +          Add storage pool namespace options
> +        </summary>
> +        <description>
> +          Allow for adjustment of RBD configuration options via Storage
> +          Pool XML Namespace adjustments.
> +        </description>
> +      </change>

I deliberately left this out primarily because of the position that
namespace options were not "standard" or "supported" for guests. It's
more than just RDB too, one could use namespaces to add more mount
options as well.  Still these are only documented within the storage
pool xml page (formatstorage).

> +      <change>
> +        <summary>
> +          qemu: Add support for setting post-copy migration bandwidth
> +        </summary>
> +        <description>
> +          Users can now limit the bandwidth of post-copy migration, e.g.
> +          via <code>virsh migrate --postcopy-bandwidth</code>.
> +        </description>
> +      </change>
>      </section>
>      <section title="Improvements">
> +      <change>
> +        <summary>
> +          Create private chains for virtual network firewall rules
> +        </summary>
> +        <description>
> +          Historically firewall rules for virtual networks were added
> +          straight into the base chains. This works but has a number of
> +          bugs and design limitations. To address them, libvirt now puts
> +          firewall rules into its own chains.
> +        </description>
> +      </change>
> +      <change>
> +        <summary>
> +          Detect CEPH and GPFS as shared FS
> +        </summary>
> +        <description>
> +          When starting a migration libvirt does some sanity checks to
> +          make sure domain will be able to run on destination. One of

"on the destination"

"One of the"

> +          requirements is that disk has to either be migrated too or

"that the disk"

> +          live on network filesystem. CEPH and GPFS weren't detected as

s/live on/be accessible from a/

> +          a network filesystem.
> +        </description>
> +      </change>
> +      <change>
> +        <summary>
> +          Advertise network MTU via DHCP when specified
> +        </summary>
> +        <description>
> +          If network MTU is set and the network has DHCP enabled,
> +          advertise the MTU in DHCP transaction too so that clients can
> +          adjust their link accordingly.
> +        </description>
> +      </change>
> +      <change>
> +        <summary>
> +          Allocate qemu memory at the configured NUMA nodes from start

QEMU   (*repeats many times - other than qemu: XXX, I think they all
should be changed).

> +        </summary>
> +        <description>
> +          Libvirt used to just start qemu, let it allocate memory for
> +          the guest and then use CGroups to move the memory to

the guest, and then

> +          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

A change was made to set process...

> +          affinity corretly from the start so that memory is allocated

correctly

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

Should this be Wireshark ?? It's a product, right?

> +        </summary>
> +        <description>
> +          Wireshark supports out of tree builds of dissectors since its
> +          2.5.0 release. Adapt libvirt to that. This affects minimal
> +          required version then too.

Adapt libvirt to use the more recent release requiring a source build
configuration of libvirt --with-wireshark to upgrade to the more recent
version.

[or something similar]

> +        </description>
> +      </change>
> +      <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>

Hmm.. This I thought would be characterized as cleanups that we don't
advertise. It's not a feature or improvement, just something w/ code
motion or alteration to make use of existing features. I think the whole
<description> section would cause someone to wonder whether previous
versions of libvirt had leaks. I'd just drop the whole thing. If it had
to be kept, please sanitize the description to not make it seem like
those changes actually removed "many" memory leaks. A few were fixed,
but I think those were edge or error conditions.

>      </section>
>      <section title="Bug fixes">
>        <change>
> @@ -133,6 +229,111 @@
>            attribute of the network bridge element).
>          </description>
>        </change>
> +      <change>
> +        <summary>
> +          Refresh block jobs on daemon restart
> +        </summary>
> +        <description>
> +          In case the daemon is restarted it now fetches new state of
> +          blockjobs. This means that libvirt does not lose track of
> +          block jobs anymore.

s/anymore//

> +        </description>
> +      </change>
> +      <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
> +          to chose one (the lowest one) which might not be hotpluggable.

Ensure that libvirt allocates a PCI address for the device so that QEMU
did not default to an address that would not allow for device hotplug.

> +        </description>
> +      </change>
> +      <change>
> +        <summary>
> +          lxc: Don't reboot host on virDomainReboot
> +        </summary>
> +        <description>
> +          If the container is really a simple one (init is just bash and
> +          the whole root is passed through) then virDomainReboot and
> +          virDomainShutdown would reboot or shutdown the host. The
> +          solution is to use different method to reboot or shutdown the
> +          container in that case (e.g. signal).
> +        </description>
> +      </change>
> +      <change>
> +        <summary>
> +          rpc: Various stream fixes
> +        </summary>
> +        <description>
> +          One particular race was fixed, one locking problem and error
> +          reporting from streams was made better.
> +        </description>
> +      </change>
> +      <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.

Fixed the generation of the guestfwd hotplug/unplug command sent to QEMU
to match the syntax used when creating the initial command line.

> +        </description>
> +      </change>
> +      <change>
> +        <summary>
> +          qemu: Forbid cdroms on virtio bus
> +        </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.
> +        </description>
> +      </change>
> +      <change>
> +        <summary>
> +          qemu: Use 'raw' for 'volume' disks without format
> +        </summary>
> +        <description>
> +          Storage pools might want to specify format of the image when
> +          translating the volume thus libvirt can't add any default
> +          format when parsing the XML. Add an explicit format when
> +          starting the VM and format is not present neither by user
> +          specifying it nor by the storage pool translation function.
> +        </description>
> +      </change>
> +      <change>
> +        <summary>
> +          qemu: domain: Assume 'raw' default storage format also for network storage
> +        </summary>
> +        <description>
> +          Post parse callback adds the 'raw' type only for local files.
> +          Remote files can also have backing store (even local) so we
> +          should do this also for network backed storage.
> +        </description>
> +      </change>
> +      <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
> +          synchronised phase. Initiating a pivot in that case will fail.

synchronized

> +          Therefore it is strongly adviced to wait for
> +          VIR_DOMAIN_BLOCK_JOB_READY event which does not suffer from
> +          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
> +          whine that they should not be used. Stop formatting attributes
> +          like cache/readonly/... in that case.

Can we avoid using "whine"...   "If a -drive has no image, then
formatting attributes such as cache, readonly, etc. would cause errors
to be reported from QEMU. This was fixed by not supplying the attributes
for devices without an image."

[I'm sure that can be wordsmithed too]

> +        </description>
> +      </change>
>      </section>
>    </release>
>    <release version="v5.0.0" date="2019-01-15">
> 

Assuming some level of adjustment and I'm sure you'll get more opinions
anyway ;-)...

Thanks for not forgetting this!

Reviewed-by: John Ferlan <jferlan at redhat.com>

John