openSUSE Build Service

Overview Repositories Revisions Requests Users Attributes Meta

File README.SuSE of Package open-ovf (Revision b536031a174df70940dbc900b3b1e3da)

Currently displaying revision b536031a174df70940dbc900b3b1e3da , Show latest

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

Places

File README.SuSE of Package open-ovf (Revision b536031a174df70940dbc900b3b1e3da)

Places