Virtual Service Package
The Service Manager orchestrates the installation, creation, instantiation, management and termination of services. The Service Manager supports the open standard OVF packaging model (http://www/dmtf/org/standards/ovf) for the service package. OVF is an open standard for describing virtual appliances and is widely used to distribute virtual appliances. The OVF package for virtual appliances used for Cisco platforms is based on the OVF standard but is not 100 % compatible with OVF standard.
The Open Virtualization Archive (OVA) is a software package that contains the application and metafiles used to create the hosting environment. The OVA package has a.OVA extension and is a tar of the following files:
- One OVA descriptor file(.xml)—The OVA descriptor file is an XML file that defines the content and requirements of the packaged service. However, instead of using standard OVA envelop (.ova), Libvirt XML format (.xml) is used because Libvirt is used for virtualization infrastructure support and it requires a Libvirt XML file instead of OVA XML. In order to support other virtualization infrastructures in future, especially for service deployment on external servers, this file will also contain the information about the type of the virtualization infrastructure the rest of the contents are defined for. This file is mandatory.
- One OVA manifest file(.mf)—As per OVF standard, zero or one manifest file containing the SHA-2 digests of the individual files in the OVA package. This file is mandatory.
- One package version file (.ver)—The package version file contains the IOS-XR virtualization framework version that a given virtual application is compatible with. This file is not mandatory per OVF standard. However, this is mandated for OVA packages installed on Cisco platforms, and allows different application versions to work seamlessly with a given IOS-XR package version.
- One OVA metadata file (.env)—The metadata file contains information such as signing algorithm, signature, X-509 certificate and so on. The signature of the digest is stored along with base64-encoded X.509 certificate in the signature envelop file (.env). The purpose of the certificate is to ensure package authenticity. The package will be unsigned using Cisco virtualization public key that is part of the Service Manager code segment rather than the public key included in the certificate file. This may also contain application type (app_type) which the Service Enablement infrastructure may use internally. This file is not mandatory.
- Zero to many disk image files—These files represent the virtual disks that support the defined virtual image(s) or service. More generally, the package includes artefacts needed by the service, including virtual disks, localized language resources, and other artefacts. Typical disk format options for KVM/QEMU are vmdk, qcow2, iso and raw formats. ISO disk format may also be used for IOS-XR Services. This file is not mandatory.
- Zero to many file systems—These files represent the file systems such as the USB file system that is synchronized to standby RSP. This file is not mandatory.
Note In Cisco IOS XR Release 5.1.1, package authenticity, disk image files, and file systems are not supported.
The first step in service creation is to install the virtual service package. The virtual service package installation involves unpacking the virtual service package, verifying the signature and downloading the ISO image and data disks onto the target where the virtual service is to be installed and activated. A given virtual service can be installed on one or more Cisco ASR 9000 VSM Cards. Once a virtual service is installed, it needs to be provisioned and activated. Any platform specific configuration needed can be performed before activating the service.
The steps for installing a service consist of:
1. Service Manager receives CLI command to install a given service. Service Manager downloads, if needed, the OVA package.
2. Service Manager stores the OVA package on local hard disk, unpacks it, and validates all the files using the SHA-2 signatures specified in the manifest file. Service Manager checks the compatibility between the minimum IOS-XR version the service requires mentioned in the version file and the running IOS-XR version. Service Manager authenticates the Service package using the signature provided in the metadata file (.env). The public key will be part of the Service Manager code. Once all the verification is done, the Service Manager proceeds with the installation on the target nodes.
3. Service Manager informs the Lead Install to install the service package on a list of target nodes. Lead Install pulls the ISO image and other hard disk images given in the OVA package.
4. Lead Install stores the ISO image and other hard disk images onto the local storage. Lead Install broadcasts to install in all sys admin instances with a list of sys admin instances that need to install these images. Lead Install will specify the multicast group to join to receive the images. Install on the targeted sys admin instances joins the multicast group.
5. Lead Install multicasts the images. Install in sys admin instances that join the multicast group receives the images.
6. The install stores the ISO image in the boot partition and creates the data partition to store the other hard disk images.
Note The flow above is specified for installing a given service package on multiple destination nodes with a single CLI command. However, in IOS XR Release 5.1.1, the CLI command takes only single location. In IOS XR Release 5.1.1 a given virtual service package can only be installed on a single location.