Jump to: navigation, search

Enhanced-Platform-Awareness-OVF-Meta-Data-Import

Revision as of 01:08, 18 October 2013 by Adrian Hoban (talk | contribs) (Created page with "= Enhanced Platform Awareness – OVF Meta-Data Import in Glance = = Summary = This proposal focuses on how meta-data contained in the OVF package can be imported automaticall...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Enhanced Platform Awareness – OVF Meta-Data Import in Glance

Summary

This proposal focuses on how meta-data contained in the OVF package can be imported automatically by Glance. At the VM deployment phase, Nova, via the Image Properties Filter, can leverage the meta-data imported by Glance to filter the available platforms to a subset of platforms that are most suitable for deploying the VM image on. One use case relates to automatic provisioning of VMs for Network Function Virtualization applications that may require enhanced platform awareness and more fine-grained provisioning of platform resources in order to meet performance criteria. The DMTF CIM models are referenced as examples of meta-data that may be imported.

Background

There is a growing movement in the telecommunications industry to transform the network. This transformation includes the distinct, but mutually beneficial disciplines of Software Defined Networking (SDN) and Network Functions Virtualization (NFV). One of the challenges of virtualizing appliances in general, and virtualizing network functions in particular, is to deliver near native (i.e. non-virtualized) performance. Many virtual appliances have intense I/O requirements, many also could benefit from access to high performance accelerators for workloads such as cryptography, and others could operate more efficiently with greater access to CPU instruction set extensions.

Network Functions Virtualization

Network Functions Virtualization (NFV) is an Industry Specification Group (ISG) in the European Telecommunications Standards Institute (ETSI). Leading network operators, TEMs, IT vendors and technology providers have joined the ISG. One of their goals is to “Develop requirements and architecture specifications for the hardware and software infrastructure required to support these virtualized functions, as well as guidelines for developing network functions.”[Ref 1] One of the challenges of virtualizing functions in general, and virtualizing network functions in particular is to deliver near native (i.e. non-virtualized) performance. To help address this challenge, developers of virtualized network functions leverage virtualization technologies traditionally associated with IT deployments such as Intel® Virtualization Technology (Intel® VT) for IA-32, Intel® 64 and Intel® Architecture (Intel® VT-x), Intel® Virtualization Technology for Directed I/O (Intel® VT-d) and Intel® Virtualization Technology for Connectivity (Intel® VT-c). They also develop their application with specific drivers for platform features such as Intel® Advanced Encryption Standard New Instructions (Intel® AES-NI) and the Intel® QuickAssist Integrated Accelerator.

Open Virtualization Format

The Distributed Management Task Force (DMTF) Open Virtualization Format (OVF) specification [Ref 2] and the related OVF Envelope XML Schema Document (XSD) [Ref 3] were developed to describe the packaging and distribution of software to be run in a virtual machine. This is one of the open standards that the NFV Industry Specification Group (ISG) in the European Telecommunications Standards Institute (ETSI) are considering as part of the interface between the higher level orchestration layers and the virtualized infrastructure manager.

DMTF Common Information Model (CIM)

OVF relies on a number of DMTF Common Information Model (CIM) [Ref 4] standards. CIM has defined ~1378 classes/subclasses, with another ~61 Problem Resolution Standard (PRS) classes that can be treated as CIM extensions. With these classes it is possible to model many of the characteristics of the platform that the VM/application has been developed to take advantage of.

Enhanced Platform Awareness

It can be generalized that there is a growing demand for the cloud OS to have a greater awareness of the capabilities of the platforms it controls. The Enhanced Platform Awareness (EPA) related updates proposed to OpenStack aim to facilitate better informed decision making related to VM placement and help drive tangible improvements for cloud tenants.

Sample Use Case

A sample use case for the feature described herein relates to the deployment in an OpenStack managed cloud of a virtualized deep packet inspection application. The application developers coded routines to leverage Intel® instruction set extensions such as AVX when they are available on the platform. When packaging the VM, they also configured the OVF meta-data to include in the CIM_ProcessorAllocationSettingData class the InstructionSetExtensionName to have a value of AVX. Leveraging extensions noted in this blueprint, the image would be automatically tagged to request AVX support on the platform. During deployment, Nova would use the image properties from within the image properties filter to help identify the most appropriate platform.

Benefits of OVF Meta-Data Import via Glance Proposal

This EPA proposal focuses on how meta-data contained in the OVF files can be imported automatically by Glance. At the VM deployment phase, Nova, via the Image Properties Filter, can leverage the meta-data imported by Glance to filter the available platforms to a subset of platforms that are most suitable for deploying the VM image on. The use of standardized meta-data descriptions/attributes should help with ensuring related support exists in other parts of OpenStack. The following is a list of some of the benefits of adding OVF Meta-Data Import support to Glance:

  • Leverage an open, industry standard on the description of permitted key-value pairs applicable to VM virtual hardware requirements.
  • Standardize the format of platform properties discovered by Nova agents.
  • Addition of administrator policy controls can restrict properties that can be tagged to an image thereby enabling an admin to control how much granularity they offer tenants in terms of platform requests.
  • Enable more efficient, higher performing VM deployments based on an enhanced ability to match optimal VM requirements to platform capabilities.
  • Less error prone workflow between the engineers creating VMs and tagging them with known properties, and the engineers/tenants/administrators deploying the VM in the cloud environment.

Existing solutions in OpenStack

It is possible to tag images with meta-data via the --property argument on the glance image-create and glance image-update commands. This --property argument takes a key-value pair. The meta-data associated with the image can be used by the Image Properties Filter during the host scheduling process. Potential issues with the existing approach:

  • If the tenant is to perform the image tagging, then permission must be granted to the tenant to update the image property with the meta-data.
  • Currently no protection/policy control on what fields they may choose to specify once they are granted permission to update the image.
  • Some image meta-data key-value pairs have been described in documentation, there is no standard recommended for the myriad of other definitions of key-value pairs that are possible. This makes automatic platform property discovery and correlation with the image meta-data more problematic if a user chooses to add additional meta-data to an image.
  • The tenant or administrator performing the image tagging are likely not to be the same person or company that developed the VM image and hence may incorrectly tag an image with sub-optimal or inaccurate properties.

Proposed Updates to OpenStack

The following are the proposed changes to Glance.

Part 1: API - Setting to enable/disable import of OVF meta-data

  • Add an optional meta-data header to instruct Glance on what to do with OVF meta-data during a POST image command: (POST http://glance.example.com/v1/images)
  • New HTTP header x-image-meta-ovf-meta-import-enable .
  • Valid values are true and false. true means Glance will import all supported OVF meta-data limited only by settings in the policy.
  • If the header is not specified, the default behavior is for OVF meta-data import to be disabled.

Part 2: Global control of permitted OVF meta-data import settings

  • The policy configuration file impacts the commands to add and modify images
add_image - Create an image entity

POST /v1/images

POST /v2/images

modify_image - Update an image entity

PUT /v1/images/<IMAGE_ID>

PUT /v2/images/<IMAGE_ID>

  • A JSON list is used to apply policy on the commands above. Policy can define what user role has permission to run the commands.

{

"default": [],

"add_image": ["role:admin", “role:superuser”, "ovf-meta-data-import:XXX", “ovf-meta-data-import:YYY”, “ovf-meta-data-import:ZZZ”],

"modify_image": ["role:admin", "role:superuser", "ovf-meta-data-import:XXX", “ovf-meta-data-import:YYY”, “ovf-meta-data-import:ZZZ”]

}

  • The new addition of the ovf-meta-data-import:XXX item in list indicates that the authorized user may import the meta-data with the key (name) XXX.
  • If <x-image-meta-ovf-meta-import-enable is not specified or set to false, then Glance shall not import all of the OVF meta-data properties that it supports parsing.

Part 3: Retrieving Image Meta-Data

  • It shall be possible to retrieve the image meta-data, e.g. via a HEAD request such as 

HEAD http://glance.example.com/v1/images/<image-URI>

  • Imported fields shall be available with the HTTP headers: x-image-meta-ovf-XXX where XXX is the name of the imported meta-data field.

Part 4: Retrieving supported Glance OVF and CIM version.

  • It shall be possible to retrieve the version of OVF and CIM models that Glance supports.
  • Possibly via HTTP headers: x-image-meta-ovf-version and x-image-meta-ovf-cim-schema-version.

Part 5: OVF Certificate Verification

Among other things, the OVF package contains a manifest file with a list of all the files in the package, a hash of each file and the hash algorithm used. To sign an OVF package, the manifest file is signed with a base64 encoded X.509 certificate. The digest of the manifest and the certificate are stored in a .cert file. By validating the certificate and verifying the signature the user can be assured the package has not been tampered with.

  • TBD – Possibly a separate blueprint needed with details on how to implement this security step.

OVF Meta-Data Fields to Import

The following table describes the suggested OVF meta-data properties that should be among the first to be imported via Glance. This is not intended to be an exhaustive list in terms of keys or values and it is expected that the OpenStack community will extend support as needed. The DMTF CIM documentation should be consulted to get a full list. Open: To help with namespace, it may be better to have the key also contain the related CIM class name and not just the property. E.g. ProcessorArchitecture would become CIM_ProcessorAllocationSettingData.ProcessorArchitecture.

Name Key [class.property] Value(s) Standard Info
CPU Architecture ProcessorArchitecture Examples noted in the class definition include x86, x86-64, ARM, MIPS, etc Described in the CIM_ProcessorAllocationSettingData class.
CPU Instruction Set InstructionSet Examples included in the class definition include x86-i386 instruction set, x86-64 instruction set, ARM A32, ARM A64, MIPS32 (32-bit), MIPS64 (64-bit) ARM, POWER etc. Described in the CIM_ProcessorAllocationSettingData class.
CPU Instruction Set Extensions InstructionSetExtensionName Instruction set extensions are listed in the CIM classes for several architectures such as Intel extensions.

Examples of Intel® 64 instruction set extensions that benefit NFV include but are not limited to:

  • Advanced Encryption Standard New Instruction (Intel® AES-NI).
  • Carry-less Multiply (PCLMULQDQ).
  • Advanced Vector Extensions (AVX)
  • Advanced Vector Extensions 2 (AVX2)
  • Streaming Single Instruction Multiple Data (SIMD) Extension (SSE) 2/3/4/4.1/4.2.
  • RDRAND (aka SecureKey)
  • Fused Multiply Add (FMA)
  • Virtualization Technology for IA-32, Intel® 64 and Intel® Architecture (Intel® VT-x)
  • Extended Page Tables (EPT)
  • Virtualization Technology for Directed I/O (Intel® VT-d)
 Described in the CIM_ProcessorAllocationSettingData class. Instruction set extensions are listed in the CIM classes for several architectures such as Intel extensions (some of which are listed in the column to the left), ARM® extensions such as ARM® NEON TM, etc.
CPU Model Family Examples included in the class definition include Intel(R) Xeon(R) processor 5400 Series. The Family property in the CIM_Processor class describes processor families.
CPU Last Level Cache Size LastLevelCacheSize Examples included in the class definition The CIM_AssociatedCacheMemory class can be used to specify the cache size. It is possible to specify the size for Level 1, Level 2 and Level 3 caches as well as other properties such as cache associativity and cache line size
Memory Type MemoryType Examples included in the class definition include DDR2, DDR3, DDR4. The CIM_PhysicalMemory class can be used to define the memory type.
Memory Speed Speed Units of nanoseconds The speed of the memory bus can be described in the CIM_AssociatedProcessorMemory class. Also described in the CIM_PhysicalMemory class.
Memory Size ConsumableBlocks Need to reference the BlockSize property to determine this value. In the CIM_Memory class the ConsumableBlocks property may be suitable for capturing this information.
Memory Error Correction ECCSupported Examples included in the class definition include {UNKNOWN, SINGLE-BIT ECC, MULTI-BIT ECC} Described in the CIM_ComputerSystemNodeCapabilities class.
Trusted Platform Module TPM Examples included in the class definition include {TXT, …, N} A Trusted Platform Module (TPM) is part of the Intel® TXT solution. A CIM_TPM class has been defined in the experimental part of the CIM V2.38.0 schema.
Platform Power States Capability PowerStatesSupported Examples included in the class definition include a numeric value to map to a power state. CIM describes power related attributes in classes such as the CIM_PowerAllocationSettingData class and the CIM_PowerManagementCapabilities class.
Hypervisor Type VirtualSystemType Examples included in the class definition include {KVM, ESXI, HYPERV, XEN, … N} This field could also be used to specify that the image should be deployed in a bare metal environment (e.g. via Ironic) Described in the CIM_VirtualSystemSettingData class .
Platform PCIe Capabilities Capabilities Examples included in the class definition include the identified PCIe capabilities such as PCIe Gen2 or PCIe Gen3. Defined in the CIM_PCIController class.
PCIe Device Passthrough VendorID PCIDeviceID “Passthrough” mode results in the entire PCIe device being decoupled from the host OS and fully allocated to the guest OS. An example of this technology is Intel® Virtualization Technology for Directed I/O (Intel® VT-d) If SR-IOV is enabled, a virtual function rather than the entire PCIe device can be allocated to the the VM. The CIM_PCIDevice class can be used to describe the capabilities of PCI devices.
Local Storage Media Technology Technology Examples included in the class definition include Solid State Drive, Fibre Channel, SATA, SAS, Mixed, Hard Disk Drive, etc. The experimental CIM_StorageTier class can be used to describe the storage technology.

Not covered by this blueprint

  • OVF can be used to package multiple VMs. This initial proposal is focused on adding support for single VM based OVF packages. The solution should be extensible to multiple VM based packages, but would require additional work to factor in the multi-VM inter-dependency models (e.g. networking) that can be described in OVF into OpenStack.
  • This blueprint is focusing on automatic configuration use cases. It does not cover potential API extensions to allow similar configuration requests to be made in a CLI driven fashion. Such extensions are considered desirable due to the additional flexibility and custom configurability of image properties and would complement the automated solution presented here.
  • Acting upon some of the meta-data properties that can be modeled in OVF would require more advanced scheduling/filtering in Nova. E.g. Core allocation can be modelled In the CIM_ProcessorCore class.
  • This blueprint is not intended to restrict the import of meta-data that may not comply with a standard. However, if non-standard meta-data is imported then the user should also add support for leveraging that data elsewhere in OpenStack.
  • Per-tenant restrictions on image properties that they may specify. Current proposal is based on global restrictions.
  • Nova agent updates to detect additional platform properties.
  • Horizon updates.

Additional Note

Although Intel developed technologies and products have been mentioned in this blueprint as examples of usage, it is intended that the design proposal is applicable to solutions from other vendors.

References

  1. Leading operators create ETSI standards group for network functions virtualization. http://www.etsi.org/news-events/news/644-2013-01-isg-nfv-created
  2. Open Virtualization Format (OVF) specification version 2.0.1, document number DSP0243, dated 2013-08-22. http://dmtf.org/sites/default/files/standards/documents/DSP0243_2.0.1.pdf
  3. OVF Envelope XML Schema Document (XSD). http://schemas.dmtf.org/ovf/envelope/2/dsp8023_2.0.1.xsd
  4. DMTF Common Information Model (CIM). http://dmtf.org/standards/cim
  5. CIM V2.38.0 schema. http://dmtf.org/standards/cim/cim_schema_v2380

Related Blueprints

Retrieved from "https://wiki.openstack.org/w/index.php?title=Enhanced-Platform-Awareness-OVF-Meta-Data-Import&oldid=32994"