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

[Michal Privoznik]

On 2/28/19 1:23 PM, John Ferlan wrote:
> 
> 
> 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).

It is sufficient to document feature at one place IMO. But if you don't 
want to advertise it I can remove this item.

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

I was never friends with 'the' and 'a'. We don't have them in my mother 
tounge. O:-)

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

surprisingly, vim spellchecker did not underline this.

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

Of course it did have them. And still does.

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

Okay, I'll drop this section.

> 
>>       </section>
>>       <section title="Bug fixes">
>>         <change>

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

Thanks,
Michal