File README.SuSE of Package open-ovf
README for the open-ovf package =============================== This file contains SUSE-specific instructions and suggestions for using Open-OVF. For more in-depth documentation of using Open-OVF, consult the online documentation at Open-OVF project page http://open-ovf.wiki.sourceforge.net/ About ----- Open-OVF project is an open source library and tools designed to promote adoption of the OVF (Open Virtual Machine Format) specification as an industry standard. It provides complete support for creating, using and maintaining OVF appliances. It aims to establish itself as a de-facto standard toolkit for working with OVF. Open-ovf is under EPL (Eclipse Public License) and plans to build an open community around OVF. Development resources from all across will be leveraged to create the common plumbing, this will help build cross-hypervisor components and prevent fragmentation of the OVF across industry. It promotes the usage of OVF and its adoption as a standard VM appliance format. What is OVF ----------- The Distributed Management Task Force (DMTF) has defined a vendor-neutral standard for packaging virtual appliances enabling automated installation, configuration and activation on any virtualization platform. Open Virtual Machine Format (OVF) specification describes an open, secure, portable, efficient and extensible format for packaging and distribution of virtual machines. Some of the main features of OVF are - DMTF standard, Open Packaging format for Virtual Appliances - XML encoded - Security and licensing features - Enable cross-hypervisor Appliance portability - Enables a neutral appliance ecosystem The latest OVF specification and schema documents (1.0.0d) are located at the DMTF Published Documents page http://www.dmtf.org/standards/published_documents/. - OVF Specification: http://www.dmtf.org/standards/published_documents/DSP0243_1.0.0.pdf - OVF Envelope Schema: http://schemas.dmtf.org/ovf/envelope/1/dsp8023.xsd - OVF Environment Schema: http://schemas.dmtf.org/ovf/environment/1/dsp8027.xsd OVF-based Virtual Appliances ---------------------------- OVF's have three phases: creation, deployment, and activation. The creation phase starts with the initial generation of an OVF and includes the modification of the image by software partners. The state of the OVF is still generic at this point as the image has not been customized for a particular site. The deployment phase is initiated by the system administrator, who in general follows the setup procedures defined by the author of the virtual appliance. The system administrator defines site specific information such as DNS settings, Gateways, and Passwords. The administrator may also make policy decisions such as the virtual platform type as well as the class of machines to be used. Basically, anything that has been parameterized within the OVF may be modified. This information is recorded in the OVF environment file which is created during this step. The OVF may be further customized by the end user. Activation of the OVF marks the final phase. The OVF is launched during this phase by the end user who is asked to accept the license agreement. The virtual machine is allocated, installed, and started during this phase. A handle of some kind is provided to the user, so that he may connect a virtual terminal with the virtual server. In this way, he can monitor the progress of the virtual server as it boots and login to the virtual server if he wants. For creation purpose, commands are needed to create, show, change, and remove data from the OVF. For deployment purposes, commands are needed to show and change data in the OVF, create the environment file, validate the OVF, and build and publish an OVA. For activation purposes, commands are needed to show information in the OVF. The OVF is not modified. OVF Package ----------- An OVF package shall include an OVF file and zero or more optional files. The standard discusses a few additional files such as the manifest file and certificate file. An OVF package can be stored as a single file using the TAR format. In this case, the file extension should be .ova and is referred to as an OVA file. Creating an OVF --------------- The OVF may describe one or more virtual servers which together define a virtual appliance. This is done incrementally with repeated calls to the mkovf command. The mkovf command contains a number of subcommands, which are individually used to build different sections of the OVF. These commands closely parallel the standard, so ambiguity regarding the significance or value of arguments may be determined by looking at the OVF specification. Nonetheless, brief comments about each subcommand are available through the 'help' subcommand: mkovf --help mkovf --help <subcommand> The following is an example of how to create an OVF for a SLES-based virtual appliance that targets the Xen hypervisor, using the mkovf command. # Create the Envelope, or root node, for the OVF file. All other sub-sections # are attached to the Envelope mkovf --init --file sles11.ovf # Add an external file (e.g. the appliance disk image) to the Reference section # of the OVF envelope. mkovf --efile --file sles11.ovf --ovfID disk0 --href sles11.img \ --size 4294967296 # Add a DiskSection to OVF meta-data. The DiskSection describes meta- # data about all virtual disks in the OVF. The fileRef option identifies # the corresponding File element in Reference section. It should be set # to the same value as ovfID option used when creating the File element. mkovf --disk --file sles11.ovf --diskID disk0 --capacity 4294967296 \ --format "Raw Image" --info "Virtual Disks" --size 4294967296 \ --fileRef disk0 # Add a NetworkSection to OVF meta-data. The NetworkSection describes logical # networks used in the OVF. mkovf --net --file sles11.ovf --networkName br0 --netID 1 \ --description "Bridged network" --info "Networks used by appliance" # Add a VirtualSystem to the OVF envelope. An OVF must contain at least one # VirtualSystem or VirtualSystemCollection. mkovf --vs --file sles11.ovf --vsID SLES11-vm \ --info "Single-VM, SLES11-based virtual appliance" # Add an OperatingSystemSection to OVF meta-data. The OperatingSystemSection # specifies the installed guest operating system of a VirtualSystem. It is # only valid for VirtualSystems and does not apply to VirtualSystemCollections. mkovf --os --file sles11.ovf --name SLES11 --description "Linux 2.6.31" \ --info "SuSE Linux Enterprise Server" # Add a VirtualHardwareSection to a VirtualSystem. At least one # VirtualHardwareSection must be specified for each VirtualSystem. Multiple # VirtualHardwarSections can be specified for a VirtualSystem. This section # can not be specified for a VirtualHardwareCollection mkovf --virthw --file sles11.ovf --sysID 275b6cdf-c22d-52c6-5bce-fc17f71644b8 \ --type xenpv --instanceID 1 --elementName "sles11-xen" \ --info "Virtual Hardware Requirements: 512Mb, 4 CPUs, 1 disk, 1 nic" \ # Add virtual resource elements to the VirtualHardwareSection # CPUs mkovf --resource --file sles11.ovf --caption "4 VCPUs" \ --description "Number of VCPUs" --resourceID numVCPU --resourceType 3 \ --virtualQuantity 4 --elementName "vcpus" # Memory mkovf --resource --file sles11.ovf --allocUnits "byte * 2^20" \ --caption "512MB of memory" --description "512MB Memory" \ --resourceID mem0 --resourceType 4 --virtualQuantity 512 \ --elementName "Mem0" # NIC # The connection option specifies the bridge used by the virtual NIC mkovf --resource --file sles11.ovf --automaticAllocation True \ --caption "Ethernet adapter on bridge network" --description "Ethernet" \ --connection br0 --resourceID 3 --resourceType 10 --elementName "eth0" # Disk # The hostResource option specifies the backing disk. Use ovf://disk/<diskId> # where <diskID> is the disk ID specified in the DiskSection. # The address option is used to specify the virtual block device name # presented to the guest, e.g. xvda. mkovf --resource --file sles11.ovf --caption "Disk1" --description "Harddisk" \ --hostResource ovf://disk/sles11.img --resourceID 4 --resourceType 17 \ --elementName xvda --address xvda Creating an OVA --------------- An appliance consists of the ovf file and zero or more optional files that can include a manifest file and a certificate file. The manifest and sign subcommands of the ova command create these two optional files if they are desired. Furthermore, an appliance may be distributed as a set of files or a single tar file with the file extension .ova. The pack subcommand handles the packing of an appliance into this OVA file. # Create an ova with no manifest or certificate file ova --pack --file sles11.ovf --output sles11.ova --no-manifest --no-certificate Activating an OVA ----------------- An ova can be activated on target system using the ova runtime subcommand. Open-OVF will produce libvirt XML from the ovf and start the virtual appliance. Alternatively, libvirt XML can be extracted to an output file using the --ofile option for later activation using for example 'virsh create <libvirt-xml-output>' # First, the ova must be unpacked ova --unpack --directory /tmp/foo --file /tmp/sles11.ova # Next, extract libvirt XML to a file ova --runtime --file sles11.ovf --virt xenpv --ofile sles11-libvirt.xml # Finally, activate the guest using libvirt's virsh command virsh create sles11-libvirt.xml Alternatively, once unpacked, the appliance can be activated directly using the ova runtime subcommand by not specifying the --ofile option: ova --runtime --file sles11.ovf --virt xenpv
