Skip to content
Merged
Show file tree
Hide file tree
Changes from 7 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 11 additions & 11 deletions source/_global.rst
Original file line number Diff line number Diff line change
Expand Up @@ -25,19 +25,19 @@

.. Latest version systemvm template name
.. |sysvm64-version| replace:: 4.19.1
.. |sysvm64-name-xen| replace:: systemvm-xenserver-4.19.1
.. |sysvm64-name-kvm| replace:: systemvm-kvm-4.19.1
.. |sysvm64-name-vmware| replace:: systemvm-vmware-4.19.1
.. |sysvm64-name-hyperv| replace:: systemvm-hyperv-4.19.1
.. |sysvm64-name-ovm| replace:: systemvm-ovm-4.19.1
.. |sysvm64-version| replace:: 4.20.0
.. |sysvm64-name-xen| replace:: systemvm-xenserver-4.20.0-x86_64
.. |sysvm64-name-kvm| replace:: systemvm-kvm-4.20.0-x86_64
.. |sysvm64-name-vmware| replace:: systemvm-vmware-4.20.0-x86_64
.. |sysvm64-name-hyperv| replace:: systemvm-hyperv-4.20.0-x86_64
.. |sysvm64-name-ovm| replace:: systemvm-ovm-4.20.0-x86_64

.. Latest version systemvm template URL
.. |sysvm64-url-xen| replace:: http://download.cloudstack.org/systemvm/4.19/systemvmtemplate-4.19.1-xen.vhd.bz2
.. |sysvm64-url-kvm| replace:: http://download.cloudstack.org/systemvm/4.19/systemvmtemplate-4.19.1-kvm.qcow2.bz2
.. |sysvm64-url-vmware| replace:: http://download.cloudstack.org/systemvm/4.19/systemvmtemplate-4.19.1-vmware.ova
.. |sysvm64-url-hyperv| replace:: http://download.cloudstack.org/systemvm/4.19/systemvmtemplate-4.19.1-hyperv.vhd.zip
.. |sysvm64-url-ovm| replace:: http://download.cloudstack.org/systemvm/4.19/systemvmtemplate-4.19.1-ovm.raw.bz2
.. |sysvm64-url-xen| replace:: http://download.cloudstack.org/systemvm/4.20/systemvmtemplate-4.20.0.0-x86_64-xen.vhd.bz2
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We seem to have multiple systemvm template versions for 4.20 - one named 4.20.0 and one 4.20.0.0. The checksum files point to the 4.20.0.0 - should we clean that up to avoid ambiguity?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, we should delete the older ones. However I believe I do not have permission to do so, if I have, I do not know how to do it 🙈

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can help with cleaning up but maybe we can confirm first that why we have two different variants.
https://download.cloudstack.org/systemvm/4.20/
Anyone? @rohityadavcloud @weizhouapache @DaanHoogland
Based on older release versions we always used 4.x.y only

.. |sysvm64-url-kvm| replace:: http://download.cloudstack.org/systemvm/4.20/systemvmtemplate-4.20.0.0-x86_64-kvm.qcow2.bz2
.. |sysvm64-url-vmware| replace:: http://download.cloudstack.org/systemvm/4.20/systemvmtemplate-4.20.0.0-x86_64-vmware.ova
.. |sysvm64-url-hyperv| replace:: http://download.cloudstack.org/systemvm/4.20/systemvmtemplate-4.20.0.0-x86_64-hyperv.vhd.zip
.. |sysvm64-url-ovm| replace:: http://download.cloudstack.org/systemvm/4.20/systemvmtemplate-4.20.0.0-x86_64-ovm.raw.bz2

.. Images
Expand Down
4 changes: 2 additions & 2 deletions source/conf.py
Original file line number Diff line number Diff line change
Expand Up @@ -24,9 +24,9 @@
author = 'Apache CloudStack Project'

# The short X.Y version
version = '4.19'
version = '4.20'
# The full version, including alpha/beta/rc tags
release = '4.19.1.0'
release = '4.20.0.0'

rst_epilog = """
.. include:: /_global.rst
Expand Down
138 changes: 22 additions & 116 deletions source/releasenotes/about.rst
Original file line number Diff line number Diff line change
Expand Up @@ -17,128 +17,34 @@
What's New in |release|
=======================

Apache CloudStack |release| is a 4.19 LTS minor release with over 300 fixes
and improvements since the 4.19.0.0 release. Some of the highlights include:

• Improvements for VMware migration to KVM
• Support to manage/unmanage DATA volume of a primary storage on KVM
• Support for NFS mount options for a primary storage on KVM
• Support to change storage pool scope from Cluster to Zone and vice versa
• Support for RHEL/OL/Rocky/Alma Linux in the same cluster
• Import from remote KVM enhancements
• Storage plugins, PowerFlex, StorPool, Linstor related fixes and improvements
• Some CKS, Veeam (B&R) related fixes and improvements
• Several UI fixes and improvements

The full list of fixes and improvements can be found in the project release notes at
https://docs.cloudstack.apache.org/en/4.19.1.0/releasenotes/changes.html

What's in since 4.19.0.0
========================

Apache CloudStack 4.19.0.0 is the initial 4.19 LTS release with 300+ new
features, improvements and bug fixes since 4.18, including 26 major
Apache CloudStack 4.20.0.0 is the initial 4.20 LTS release with 190+ new
features, improvements and bug fixes since 4.19, including 15 major
new features. Some of the highlights include:

• CloudStack Object Storage Feature
• VMware to KVM Migration
• KVM Import
• CloudStack DRS
• OAuth2 Authentication
• VNF Appliances Support
• CloudStack DRS
• CloudStack Snapshot Copy
• Scheduled Instance Lifecycle Operations
• Guest OS Management
• Pure Flash Array and HPE-Primera Support
• User-specified source NAT
• Storage Browser
• Safe CloudStack Shutdown
• New CloudStack Dashboard
• Domain migration
• Flexible tags for hosts and storage pools
• Support for Userdata in Autoscale Groups
• KVM Host HA for StorPool storage
• Dynamic secondary storage selection
• Domain VPCs
• Global ACL for VPCs

The full list of new features can be found in the project release notes at
https://docs.cloudstack.apache.org/en/4.19.0.0/releasenotes/changes.html

.. _guestosids
Possible Issue with volume snapshot revert with KVM
===================================================

Between versions 4.17.x, 4.18.0 and 4.18.1, KVM volume snapshot backups were
not full snapshots and they rely on the primary storage as a backing store.
To prevent any loss of data, care must be taken during revert operation and
it must be ensured that the source primary storage snapshot file is present
if the snapshot is created with any of these CloudStack versions.

Users will have a backing store in their volume snapshots in the following cases:

- the snapshots are from a ROOT volume created from template;
• Webhooks
• Dynamic and Static Routing
• Ceph RGW Object Store Support
• NSX integration
• Shared Filesystem
• Multi-arch Zones

Users will not have a backing store in their volume snapshots in the following cases:

- the snapshots are from ROOT volumes created with ISO;
- the snapshots are from DATADISK volumes;

Following there are two queries to help users identify snapshots with a backing store:

Identify snapshots that were not removed yet and were created from a volume that was created from a template:

.. parsed-literal::
SELECT s.uuid AS "Snapshot ID",
s.name AS "Snapshot Name",
s.created AS "Snapshot creation datetime",
img_s.uuid AS "Sec Storage ID",
img_s.name AS "Sec Storage Name",
ssr.install_path AS "Snapshot path on Sec Storage",
v.uuid AS "Volume ID",
v.name AS "Volume Name"
FROM cloud.snapshots s
INNER JOIN cloud.volumes v ON (v.id = s.volume_id)
INNER JOIN cloud.snapshot_store_ref ssr ON (ssr.snapshot_id = s.id
AND ssr.store_role = 'Image')
INNER JOIN cloud.image_store img_s ON (img_s.id = ssr.store_id)
WHERE s.removed IS NULL
AND v.template_id IS NOT NULL;
With that, one can use qemu-img info in the snapshot file to check if they have a backing store.

For those snapshots that have a backing store, one can use the following query to check which template is it and in which storage pool it is:

.. parsed-literal::
SELECT vt.uuid AS "Template ID",
vt.name AS "Template Name",
tsr.install_path AS "Template file on Pri Storage",
sp.uuid AS "Pri Storage ID",
sp.name AS "Pri Storage Name",
sp.`path` AS "Pri Storage Path",
sp.pool_type as "Pri Storage type"
FROM cloud.template_spool_ref tsr
INNER JOIN cloud.storage_pool sp ON (sp.id = tsr.pool_id AND sp.removed IS NULL)
INNER JOIN cloud.vm_template vt ON (vt.id = tsr.template_id)
WHERE tsr.install_path = "<template file in the snapshot backing store>";
After identifying the snapshots with a backing store and the related templates, one can mount the secondary storage on a host that has access to the template and use qemu-img convert on the snapshot to consolidate it:

.. parsed-literal::
qemu-img convert -O qcow2 -U --image-opts driver=qcow2,file.filename=<path to snapshot on secondary storage> <path to snapshot on secondary storage>-converted
Issue regarding LDAP authentication on version 4.19.0
=====================================================
The full list of new features can be found in the project release notes at
https://docs.cloudstack.apache.org/en/4.20.0.0/releasenotes/changes.html

In version 4.19.0, the encryption of scoped configurations of Accounts and Domains was changed to only encrypt if there were sensitive data (e.g, they belonged to the Hidden or Secure category) as all configurations for Accounts and Domains were encrypted in previous versions. However, when using the encrypted values from these scopes, ACS did not correctly decrypt these values. For this reason, a simple solution was to update these configurations to their plain values with manual DB intervention, as reported in issue `#8637`.
Log4j Upgrade
=============

This issue has been fixed in Apache CloudStack 4.19.1.0. However, for users that manually set the configurations ``ldap.bind.password`` and ``ldap.truststore.password`` to a plain value in order to fix the faulty behaviour, it is required to store them encrypted after upgrading to version 4.19.1 and onwards. It will not be possible to update the configuration via UI, as an exception will be thrown when ACS tries to decrypt the plain value. To fix this, it is required to set the password again for ACS to encrypt it. There are two options:
Up until 4.19.x.x, the logging library used for the project was Log4j 1.29.
The 4.20.0.0 version has updated the library to Log4j2. The new Log4j2 configuration file format is not backwards
compatible with the old one. The 4.20.0.0 packages will come with the default configuration files updated.
Users that have made customizations to their files must update their configuration files to match with the new format,
the `official Log4j documentation`_ might help you migrate your custom configurations.

#. Manually set the configuration via CloudMonkey, for example ``update configuration domainid=<domain-uuid> name="ldap.bind.password" value="password"``;
#. Or, removing the defined configuration through the database via the query ``DELETE from cloud.domain_details WHERE name like "%ldap%password%"``, and setting the configuration via UI for the affected domains.
JRE Upgrade
============

After updating these configurations, LDAP authentication should be working as expected.
Up until 4.19.x.x, the JRE used for ACS was JRE 11. In 4.20.0.0, the JRE was upgraded to JRE 17 as JRE 11 has reached EOL.
This means that Centos7 (EL7) is no longer supported.

.. _`#8637`: https://github.com/apache/cloudstack/pull/8637
.. _official Log4j documentation: https://logging.apache.org/log4j/2.x/migrate-from-log4j1.html
Loading
Loading