The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Note | You can directly upgrade to Cisco VTS 2.6 from Cisco VTS 2.5.2.1 and Cisco VTS 2.5.2. If you are running a version earlier than Cisco VTS2.5.2, you have to upgrade to Cisco VTS 2.5.2, before you upgrade to version 2.6. See Cisco VTS 2.5.2 Installation Guide for the procedure to upgrade to Cisco VTS 2.5.2. |
This chapter has the following sections:
Before you upgrade, ensure that:
See Device documentation for the procedure about how to copy Day Zero configuration locally.
# sudo crm status
In an HA setup, both VTCs are online, and one is set as Master and other is set as Slave.
set devices device [device_name] [device_extension]:device-info device-use unmanaged commitWhen a device is specified as unmanaged, Cisco VTS will not sync with these devices as part of the upgrade process. Hence, if before upgrade, you use the above command to mark the devices that are not managed by Cisco VTS, then VTS will not sync with these devices and this will not cause a failure during the upgrade.
Step 1 | Setup a
writable shared drive, which is accessible to the VTC VM to use a backup drive
during the upgrade process. For example:
root@vts1:home/admin# apt-get install sshfs root@vts1:home/admin#mkdir extdrive root@vts1:home/admin#sshfs root@externalServerIp:/home/admin/extdrive1/ /home/admin/extdrive/ root@vts2:home/admin# apt-get install sshfs root@vts2:home/admin#mkdir extdrive root@vts2:home/admin#sshfs root@externalServerIp:/home/admin/extdrive2/ /home/admin/extdrive/ | ||
Step 2 | Mount the upgrade ISO. On an HA setup do this on both Master and Slave: | ||
Step 3 | Run the
following command , as root user.
show_tech_support -t –a This command backs up log files, including device configuration, and generates a tar file . Copy the tar file outside of the VTC host. This file will be required for troubleshooting purpose. This needs to be done on both VTC nodes in case of an HA setup. . | ||
Step 4 | Run upgrade
script. On an HA setup, run the script on both Master and Slave in parallel.
python upgrade.py upgrade -ip <vip-ip> -p <password> -b <backup dir> -stIf you have out of band template configuration in Cisco VTS 2.5.2 or 2.5.2.1, follow the procedure detailed in section Preserving Out of Band Template Configuration. If the upgrade fails, you need to perform a rollback. See Performing a Rollback for details. | ||
Step 5 | Run the
following command , as root user. (Same as Step 3)
show_tech_support -t –a This command backs up log files, including device configuration, and generates a tar file . Copy the tar file outside of the VTC host. This file will be required for troubleshooting purpose. This needs to be done on both VTC nodes in case of an HA setup.
| ||
Step 6 | Reboot VTC after the upgrade is complete using the reboot command on shell . In case of HA, after the upgrade is complete on both the nodes, reboot each VTC node using the reboot command on shell. |
This is a pre-upgrade procedure that has to be done before you start the VTS upgrade. You need to identify the impacted Service Extension/Device templates due to NED upgrade and correct them to be migrated to the new NED version.
Suppose the "sample1.impacted.keys" has the following entry:
config/nx:router/ospf{}/area{}/range{}/maskThis means that in the upgrade-to version the mask attribute was either altered or deleted, now you need to figure out what was the change. To do that we open the target <schema name>.txt under the schemas directory and seek the path up until what was change, in this example we seek the string "
config/nx:router/ospf{}/area{}/range".
Saving VTC snapshots involves:
On OpenStack—Need to be done for all VTC VMs (Master and Slave):
Shutdown the VTC VMs to take snapshot using virsh save utility. VTC VMs will no longer be available in running state.
root@vts-controller-110 ]# virsh list Id Name State ------------------------------------- 236 VTC1 running 237 VTC2 running
virsh save <id> <file>
For example:
virsh save <VTC Domain ID> <file>
virsh save 236 vtc1.txt virsh save 237 vtc2.txt
Take vtc.qcow2 image backup which was used to bring up Master and Slave.
tar –cvf vtc1.qcow2.tar vtc1.qcow2 tar –cvf vtc2.qcow2.tar vtc2.qcow2
Copy tar images to external drive (vtc1.qcow2.tar ,vtc2.qcow2.tar are VTC snapshots, which will be used to rollback).
Restore VTC VMs which will bring VTC VMs back to running state.
virsh restore vtc1.txt virsh restore vtc2.txt
Verify if Master and Slave are up and running in HA mode. Verify GUI login using VIP IP.
Step 1 | Upgrade to VTS
2.6 without doing a sync-to.
cd /mnt/upgrades/python python upgrade.py upgrade -ip <vip-ip> -p <password> -b <backup dir> |
Step 2 | Run sync-to
dry-run.
cd /mnt/upgrades/python/scripts ./sync_to_dry_run.script |
Step 3 | Check /opt/vts/run/upgrade/ folder with files having non-zero size. |
Step 4 | If there are files with non-zero size, then Southbound lock all
the devices.
cd /mnt/upgrades/python/scripts ./southbound_lock_managed_devices.script |
Step 5 | Create templates that contain the out of band configuration and apply the templates. Configuration with - sign will be removed from device configuration. Configuration with + sign will be added to device configuration. |
Step 6 | Unlock all the devices.
cd /mnt/upgrades/python/scripts ./unlock_managed_devices.script |
Step 7 | Do a sync-to to all the devices.
cd /mnt/upgrades/python/scripts ./synch_to.script |
Step 1 | Generate new VTSR ISO before upgrading to new VTSR. |
Step 2 | Delete the existing VTSR VM and bring up the new VM using the new image. See Installing VTSR for details. |
Step 3 | After the VTSR VM comes up, do a sync-to operation in order to sync the configuration from the VTC. |
VTF has to be uninstalled and installed after the VTC upgrade.
Note | In case of upgrade, user cannot use the GUI to install VTF again after uninstallation, if there are any workloads (ports) attached. |
This section certain important points you need to consider after you upgrade to Cisco VTS 2.6
Upgrade from Cisco VTS 2.5.2 to Cisco VTS 2.6—Impact on SRIOV ports:
OpenStack behavior for SRIOV ports is similar to that of OVS ports in that SRIOV ports, by default, get associated with tenant's default Security Group.
When SRIOV ports get migrated from Cisco VTS 2.5.2 to Cisco VTS 2.6, Cisco VTS removes any Security Groups associated with them as they do not serve any purpose anyways.
You must edit these SRIOV ports and associate them with either 'no security groups' or with a security group that does not use 'remote-sg'.
If above action is not performed, any subsequent SRIOV ports updates from OpenStack would get rejected as Cisco VTS does not allow SRIOV ports to get associated with Security Groups containing remote-sg.
See Upgrade Behavior for Security Groups for important information related to Security Groups upgrade behavior.
Eventhough Security Groups were unsupported in versions earlier than Cisco VTS 2.6, the Operator could still use OpenStack to create Security Groups and associate them with VMs. Cisco VTS, in earlier releases, would never register any Security Group event, and hence no Security Group event would flow into the VTS database. But when a Port is associated with an Security Group, OpenStack embeds the entire payload of the corresponding Security Group into Port payload. In version 2.5.2, Cisco VTS used to consume this payload as-is and store in its database. In a way, Cisco VTS was aware of the Security Group contents even in version 2.5.2. But this content would not reflect the latest updated version of the respective Security Group because Cisco VTS did not register for OpenStack Security Group events.
Upgrade from Cisco VTS version 2.5.2 to 2.6, fetches Security Group contents that were already present in its Port database, and creates corresponding Security Groups and Rules in its database. Upgrade process triggers a 'redeploy' of Security Group services post data migration. This may cause out-of-sync VTSRs if there are any VTF eligible Security Groups. If the deployment only has 'default' Security Groups with remote-sg rule then none of these Security Groups are considered eligible; hence none get pushed to VTSR.
We recommend that you update the security groups from the OpenStack backend CLI to trigger Security Group updates from OpenStack Controller towards VTC, post upgrade.
[root@overcloud-controller-0 ~]# source overcloudrc [root@overcloud-controller-0 ~]# openstack (openstack) security group list (openstack) security group set --description "update trigger" 038f2c29-7c66-4119-a4fc-62c826e08223
[stack@ospd-director ~]$ source overcloudrc [stack@ospd-director ~]$ openstack (openstack) security group set <default-sg-id> --project-id <project-id> --description "Updated default SG description" (openstack)Doing this ensures that the VTC is consistent with OpenStack's Security Groups.
All OVS ports get migrated to Cisco VTS 2.6, as-is. Non OVS Ports-SRIOV, Baremetal, and VTF Ports on the other hand go through a scrubbing process where the Security Group list of each of these ports is set to empty. This scrubbing process is required to ensure that no underlying traffic flows are affected due to premature application of Security Groups that come from version 2.5.2. It also helps to avoid pushing not-yet-fully vetted security configuration towards ToRs, thus avoiding traffic disruptions due to upgrade.
Post migration, the Operator is expected to associate each of these non OVS Ports with Security Groups that reflect Operator's vetted security intent.
|
Ports in 2.5.2 (Before Upgrade) |
Ports in 2.6 (After Upgrade) |
Ports in 2.6 (Operator-created new SGs Specifically for non-OVS Ports) |
||||
---|---|---|---|---|---|---|---|
Openstack OVS Ports |
Port P1 { Network: ... ... Security-Groups { default { Ingress Rules, Egress Rules } custom-sg1 { Ingress Rules, Egress Rules } } } |
Port P1 { Network: ... ... Security-Groups { default, custom-sg1 } }
|
Port P1 { Network: ... ... Security-Groups { default, custom-sg1 } }
|
||||
Non OVS Ports (SRIOV, BM, VTF) |
Port P1 { Network: ... ... Security-Groups { default { Ingress Rules, Egress Rules } custom-sg1 { Ingress Rules, Egress Rules } } } |
Port P1 { Network: ... ... Security-Groups { } }
|
Port P1 { Network: ... ... Security-Groups { default, custom-default-with-no-remote-sg, custom-sg2-no-remote-sg } }
|
Openvswitch does not support OVS trunk ports in Newton release.
We recommend that for firewall settings you use OVSHybridIptablesFirewallDriver. When Cisco VTS is upgraded to version 2.6, following settings automatically take effect if the Operator is deploying VTS Plugin via OpenStackPlatform director. If not, settings in column OpenStack Settings Post 2.6 Upgrade that enable Security have to be manually done.
|
OpenStack Setting before Upgrade to 2.6 |
OpenStack Settings Post 2.6 Upgrade that enable Security Groups |
||||||
---|---|---|---|---|---|---|---|---|
Scenario-1: OS Deployment has Security Groups Enabled |
Controllers: /etc/neutron/plugin.ini
enable_security_group = true firewall_driver = openvswitch
firewall_driver = openvswitch
|
Controllers: /etc/neutron/plugin.ini
firewall_driver = neutron.agent.linux. iptables_firewall.OVSHybridIptablesFirewallDriver enable_security_group = true
Computes: openvswitch_agent.ini Settings on the compute do not matter as long as Controller has the above settings. |
||||||
Scenario-2: OS Deployment has Security Groups Disabled |
#enable_security_group = true #firewall_driver = |
Same as above. |
The following sections describes the procedure to roll back to the Cisco VTS version from which you upgraded.
Do the following to rollback to the Cisco VTS version from which you upgraded. This should be done for all the VTC VMs (Master and Slave).
Step 1 | On the
controller, do
virsh list.
root@vts-controller-110 ]# virsh list Id Name State ------------------------------------- 236 VTC1 running 237 VTC2 running | ||
Step 2 | Virsh destroy
already existing VTC VMs (Master and Slave).
virsh destroy <id> | ||
Step 3 | Copy vtc1.qcow2.tar and vtc2.qcow2.tar from external drive to the controller. | ||
Step 4 | Untar
vtc1.qcow2.tar and
vtc2.qcow2.tar
untar –xvf vtc1.qcow2.tar untar –xvf vtc2.qcow2.tar | ||
Step 5 | Create Master
and Slave VTC (virsh create utility) using
vtc.xml file
which points to the location of
qcow images
that is untarred in the above step.
| ||
Step 6 | Verify if
Master and Slave are up and running in HA mode. Verify GUI log in using VIP IP.
| ||
Step 7 | Manually reregister the VMM and Host Agent from VTS GUI. |
Do the following to rollback to the Cisco VTS version from which you upgraded. This should be done for all the VTC VMs (Master and Slave).
Step 1 | Power Off the VTC VM (recommended) |
Step 2 | Right click on VTC VM and select Snapshot, and then Snapshot Manager.... |
Step 3 | Select Snapshot and click Go to. Click Close to close the screen. |
Step 4 | Power On the VTC VM. |
Step 5 | Verify if HA is up and running. Verify GUI log in using VIP IP. |
Step 6 | Manually reregister VMM from VTS GUI. |