An OVF descriptor is designed to be read by a hypervisor directly. Abiquo can read OVF files created automatically. However, Abiquo uses the OVF descriptor to create the VM by calling the hypervisor API (or libvirt). Thus Abiquo will send a command to the hypervisor API to create the virtual machine resources required. As this example shows, some elements of a typical OVF descriptor created by a hypervisor will be ignored by Abiquo.
Abiquo recommends that you use the Template-Repository system to manage virtual machine templates so you do not need to develop your own OVF envelope documents. The OVF Reference section is designed to provide information about OVF for Abiquo for reference and troubleshooting purposes.
Abiquo supports many ways to import virtual machine templates including:
The OVF standard is widely used in virtualization. Abiquo's virtual machine templates and template definitions are based on OVF.
This is an excerpt from the OVF specification.
Open Virtualization Format (OVF) is a hypervisor-neutral, efficient, extensible, and open specification for the packaging and distribution of virtual appliances composed of one or more virtual computer systems.
The rapid adoption of virtual infrastructure has highlighted the need for a standard, portable meta-data model for the distribution of virtual machines to and between virtualization platforms. Packaging an application together with the operating system on which it is certified, into a virtual machine that can be easily transferred from an ISV, through test and development and into production as a pre-configured, pre-packaged unit with no external dependencies, is extremely attractive. Such pre-deployed, ready to run applications packaged as virtual machines (VMs) are called virtual appliances. In order to make this concept practical on a large scale it is important that the industry adopts a vendor-neutral standard for the packaging of such VMs and the meta-data that are required to automatically and securely install, configure, and run the virtual appliance on any virtualization platform.
Whereas current virtual appliances contain a single VM only, modern enterprise applications model service oriented architectures (SOA) with multiple tiers, where each tier contains one or more machines. A single VM model is thus not sufficient to distribute a multi-tier service. In addition, complex applications require install-time customization of networks and other customer specific properties. Furthermore, a virtual appliance is packaged in a run-time format with hard disk images and configuration data suitable for a particular hypervisor. Run-time formats are optimized for execution and not for distribution. For efficient software distribution, a number of additional features become critical, including portability, platform independence, verification, signing, versioning, and licensing terms.
The Open Virtualization Format (OVF) specification is a hypervisor-neutral, efficient, extensible, and open specification for the packaging and distribution of virtual appliances composed of one or more VMs. It aims to facilitate the automated, secure management not only of virtual machines but the appliance as a functional unit. For the OVF format to succeed it must be developed and endorsed by ISVs, virtual appliance vendors, operating system vendors, as well as virtual platform vendors, and must be developed within a standards-based framework.
OVF is the packaging format used to distribute solutions based on virtual machine templates. A virtual machine packaged using the OVF standard can be deployed in Abiquo if it is stored in the appliance library.
An OVF package contains:
Abiquo only uses the elements of the OVF package described on this page.
Abiquo OVF support for multiple disks
Abiquo supports multiple disks in the OVF file. You can:
Note that Abiquo UI template upload only supports the creation of single-disk templates. You can then edit the template to add more disks.
The OVF description file (.ovf) contains metadata of the virtual appliance template.
Envelope is the root element for this XML document.
The mandatory sections are:
This section contains references to external resources used by the virtual appliance. References can point to files such as virtual disks or icons.
Reference information for completing the References section:
In the example below, there are two disk files, 0 and 1, inside the OVF descriptor, and it is located in the same directory on the disk as the OVF descriptor. An icon is also included for this file.
You can use multiple physical disks to create a virtual machine. The disk at sequence 0 on the disk controller must be a boot disk.
Reference information for completing the DiskSection:
Abiquo enables you to define empty disks in the OVF file. These disks have no file reference. The system disk cannot be an empty disk.
The VirtualSystem describes the template configuration for a virtual machine. In Abiquo, the OVF descriptor can only contain one VirtualSystem but you can use a virtual appliance to hold multiple virtual machines.
Abiquo uses the following elements of the virtual system that are mandatory:
The VirtualSystem section is structured as follows.
The ProductSection is required. Enter information about the virtual appliance that is displayed for users.
The ProductSection must contain:
The Icon URL must include a public IP address or domain name (not 127.0.0.1 or localhost).
The ProductSection can also contain the following optional elements:
The user and password are stored as <loginUser> and <loginPassword> in the Abiquo template definition. If these optional elements are not supplied, the default value is null.
Abiquo supports guest operating system codes for ESX. You can set these codes in the OVF or in the Abiquo VM template definition (using the API or UI). See Extended OVF Support and Template Definition
This optional section contains the operating system ID and version.
If you do not supply the operating system ID and version, Abiquo will set the operating system to UNRECOGNIZED. This means that when you deploy in VMware, the guest operating system will be Other32bit. See Extended OVF Support and Template Definition
The operating system ID must be one of the official codes described in the OVF documentation for the CIM Schema version supported by Abiquo.
Please note that the code usually includes the number of bits. For example, the code for Ubuntu 32 bit is not the same as the code for Ubuntu 64 bit. The operating system version is a free text field. There are no restrictions on the values you can enter.
For example, for Windows 7 Server the OperatingSystemSection should be as follows.
To create the template definition, Abiquo will interpret the OperatingSystemSection ovf:id according to the Guest OS Interpretation Table on the Extended OVF Support and Template Definition page. This means that the CIM code will be converted to the name of the OS and the version field will be stored directly in Abiquo without any changes. Note that you can modify the template definition in Abiquo using the API or in the Abiquo database.
When you deploy a virtual machine from this template in ESXi 5.1, Abiquo will set the guest operating system based on the table.
Contains all the information about the hardware resources needed to run the virtual appliance. The System section is followed by various Items.
Previously this field was used to describe the disk format. However, now Abiquo uses the Template Compatibility Table to determine if the target hypervisor can run the source disk format. Abiquo V2V functionality can convert a disk from one format to another. Enter "abiquo" as the VirtualSystemType.
In the System section, an Item specifies a virtual device by describing the resources to allocate on the virtual system. Resources are described using Resource Allocation Setting Data (RASD) elements.
Optional Items (Abiquo will automatically create these if they are not included):
These RASD fields are found in all items
Reference information for completing the Virtual CPU Item:
Reference information for completing the RAM Item:
Abiquo requires a hard disk that is appropriate for your hypervisor and virtual machine.
Reference information for completing the Hard Disk Item:
rasd:AddressOnParent: Set AddressOnParent to the disk sequence number and file/disk number
Abiquo can support DiskControllers of type IDE or SCSI supplied in the .ovf definition. And the specific controller can be set. You can add multiple SCSI controllers. You can change the SCSI controller before or after you deploy the VM.
|ResourceSubType value||diskController saved in template and created on VMware|
|other (default value)||VirtualLsiLogicController|
For example, when you create a volume in an ESXi virtual datacenter, if you don’t enter a value for the disk controller, the platform will use the value set in the Abiquo Configuration Properties or the default VirtualLsiLogicController.
This element is known as the diskControllerType in the Abiquo template definition. For example, <diskControllerType>IDE</diskControllerType>.
By default, Abiquo supports the E1000 ethernet adapter.
On ESX, Abiquo can support three types of Ethernet adapters. The supported adapters are: E1000, PCNet32, and VMXNET3. The default is E1000 and in case of problems with other adapters, E1000 will be used.
On KVM, Abiquo can support the VIRTIO ethernet adapter in addition to the E1000 ethernet adapter.
This element is referred to as <ethernetDriverType> in the Abiquo template definition. For example <ethernetDriverType>E1000</ethernetDriverType>.
The Template-Repository will automatically create an Abiquo-compatible OVF descriptor for you.
This is an example of the OVF descriptor created by Abiquo. It contains only the essential elements. Follow the instructions above to update the OVF descriptor for your virtual disk files.
Right click and use Save As to download the following desc.ovf sample descriptor file which is also attached to this page.
Administrators can validate OVF files for Abiquo by calling the Abiquo appliance manager API.
The .ovf file should contain the fields as described in #OVF for Abiquo above. Replace the text in red with appropriate values for your system, where the "Remote Services Server" is the address of the server with the Appliance Manager.
You can use the fix query parameter to resolve a missing product section and/or disk-format type URI. By default, the fix parameter is set to false. Here is an example query with the fix query parameter.
It should give detailed information about the validation process.
Here is the output from a successful validation test:
And here is an example of the output when checking an incorrect .ovf file.
This section is based on the automatic OVF validation process prior to downloading a VM template from the remote repository to the appliance library.
However, you can check these points before uploading a VM to the appliance library.
There is a single virtual system
Collections are not supported
For each disk, the used disk format type is Abiquo compatible or UNKNOWN
You will not be able to deploy using a template with a disk of type UNKNOWN. You will be able to see the template in the Appliance Library but not in the Virtual Datacenter screen for adding templates to a Virtual Appliance. You can determine the format and size using diskid and then edit the template details in the Appliance Library. Empty disks should be defined as "RAW".
Automatic upload will assign UNKNOWN to unknown disks
Template-Repository can automatically determine the disk format.
There is a product section at envelope level.
If the product section does not exist, the template will not load. If the product section is empty, there will be missing metadata in the Appliance Library. The template will be named after the ovf descriptor file, e.g. for abc.ovf the template will be named abc
If there is no product section, automatic upload will create an empty product section.
Template-repository will require you to enter product data
There is a DiskSection for each disk
The capacity must contain the provisioned size of the template. For flat files, this is the same as the size of the disk file; for compressed files, it is the virtual size. If you do not specify the capacity correctly, you may have deployment problems, because the whole disk will not be copied to the hypervisor datastore for deployment.
You must enter the disk size. See Add VM Templates to the Apps Library#Determining the Size of a VM Disk File
Template-repository will automatically determine the disk size
There is a VirtualHardwareSection inside the virtual system
The VirtualHardwareSection includes RASD for CPU, RAM and HD
The disk referenced by the virtual system is defined (and so is the actual file referenced by the disk on the filesystem)
Empty disks do not require a reference to an actual file on the filesystem.
Allocation units are correct for CPU, RAM and HD
All the referenced FileTypes have the size
VirtualBox does not add the size from CLI. See Add VM Templates to the Apps Library#Determining the Size of a VM Disk File
All these errors are reported on the appliance library screen and directly on the repository filesystem (''deploy.error'' file inside the package folder).