In our implementation of the OVF we allow a choice between raw, cow and
vmdk disk formats for both import and export. Other formats covertable
-using ``qemu-img`` are allowed, but not tested.
+using ``qemu-img`` are allowed in import mode, but not tested.
The justification is the following:
- Raw format is supported as it is the main format of disk images used
As mentioned, Ganeti will allow export in ``raw``, ``cow`` and ``vmdk``
formats. This means i.e. that the appropriate ``ovf:format``
-will be provided. It does not mean that other formats cannot be used,
-rather that we did not test them.
+will be provided.
As for import, we will support all formats that ``qemu-img`` can convert
to ``raw``. At this point this means ``raw``, ``cow``, ``qcow``,
``qcow2``, ``vmdk`` and ``cloop``. We do not plan for now to support
purposes and is better standardized.
Please note, that due to security reasons we require the disk image to
-be in the same directory as the ``.ovf`` description file.
+be in the same directory as the ``.ovf`` description file for both
+import and export.
In order to completely ignore disk-related information in resulting
config file, please use ``--disk-template=diskless`` option.
accessibility for Ganeti instances. List of installed OSes can be
checked using ``gnt-os list`` command.
+References
+----------
+
+Files listed in ``ovf:References`` section cannot be hyperlinks.
+
Other
-----
---------------
Disk conversion for both import and export is done using external tool
-called qemu-tools. The same tool is used to determine the type of disk,
-as well as its virtual size.
+called ``qemu-img``. The same tool is used to determine the type of
+disk, as well as its virtual size.
Import
Typical workflow for the import is very simple:
-- read the ``.ovf`` file info memory
+- read the ``.ovf`` file into memory
- verify manifest
- parse each element of the configuration file: name, disk template,
hypervisor, operating system, backend parameters, network and disks
- save gathered information in ``config.ini`` file
+Export
+------
+
+Similar to import, export functionality also uses two classes -
+OVFWriter and OVFExporter.
+
+OVFWriter class produces XML output based on the information given. Its
+sole role is to separate the creation of ``.ovf`` file content.
+
+OVFExporter class gathers information from ``config.ini`` file or
+command line and performs necessary operations like disk conversion, disk
+compression, manifest creation and OVA package creation.
+
+Typical workflow for the export is even simpler, than for the import:
+
+- read the ``config.ini`` file into memory
+- gather information about certain parts of the instance, convert and
+ compress disks if desired
+- save each of these elements as a fragment of XML tree
+- save the XML tree as ``.ovf`` file
+- create manifest file and fill it with appropriate checksums
+- if ``--ova`` option was chosen, pack the results into ``.ova`` tarfile
+
+
+Work in progress
+----------------
+
+- conversion to/from raw disk should be quicker
+- add graphic card memory to export information (12 MB of memory)
+- space requirements for conversion + compression + ova are currently
+ enormous
+- add support for disks in chunks
+- add support for certificates
+- investigate why VMWare's ovftool does not work with ovfconverter's
+ compression and ova packaging -- maybe noteworty: if OVA archive does
+ not have a disk (i.e. in OVA package there is only .ovf ad .mf file),
+ then the ovftool works
+- investigate why new versions of VirtualBox have problems with OVF
+ created by ovfconverter (everything works fine with 3.16 version, but
+ not with 4.0)
+
.. vim: set textwidth=72 :
.. Local Variables:
projects / ganeti-local / blobdiff