You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »


Related articles:

 Prior to the upgrade, the new software load (for example, dsc_swe_20_x_x_xxx_upgrade.sh file) is uploaded from the 

Unable to show "metadata-from": No such page "_space_variables"
 Global Support Portal onto a space accessible by the KVM, VMWare, OpenStack or 
Unable to show "metadata-from": No such page "_space_variables"
hypervisor.

The upgrade file is installed to an existing/running Management/Routing VM on a KVM, VMWare, OpenStack or

Unable to show "metadata-from": No such page "_space_variables"
 hypervisor.

The upgrade process comprises of the following tasks:

  • run the upgrade file on Management/Routing VM of the hypervisor that contains this file

  • upgrade the system using the upgrade script on the same Management/Routing VM
       
Note

In this documentation, the application software is referred to as

Unable to show "metadata-from": No such page "_space_variables"
software.


The referenced system configuration in this section consists of two host hardware platforms directly connected and running two virtual machines (VMs) each with 

Unable to show "metadata-from": No such page "_space_variables"
 software.

Note

The 

Unable to show "metadata-from": No such page "_space_variables"
supports up to ten VMs on each host hardware platform.


The host hardware platform is equipped with a VM that has routing and management capabilities (Routing and Management VM). This platform may be equipped with additional VMs that only have routing capability (Routing VMs).

For information about all supported hardware configurations, refer to the Installation Guide. 

Service on a properly configured 

Unable to show "metadata-from": No such page "_space_variables"
 should not be impacted by the software upgrade process. During this process, the VMs are stopped, are upgraded to the new software, and are restarted in such an order that the traffic is not interrupted on the system.

It is assumed that your network is configured with redundancy such as two VMs to accommodate a switchover of traffic from VM to the other, while the software upgrade takes place. 

Note

The VM that is being upgraded is referred to as the standby system and the VM that is managing the additional traffic is referred to as the active system.

All the examples in this document assume a Linux/Unix environment. Alternatively, utilities such as psftp.exe and putty.exe can be used in a Windows environment to SSH.

The screen captures for the system pre-upgrade, upgrade, and rollback between releases are the same with the exception of the version numbers in these screen captures.

It is recommended that you upgrade the software when the traffic levels are low to avoid the risk of triggering network congestion on the active system.

If you have to reset the system date and time, it is recommended that you perform this task during the maintenance window. For more information, refer to the DSC - SP2000 Platform Manager User Guide.

Follow the upgrade procedures as described in DSC SWe - vSP2000 Software Upgrade Process.

Caution

Do not log onto the platform using the shared IP address on the Routing and Management VMs during the upgrade procedures provided in this section. The address is disabled as part of the upgrade process.

  • No labels