Synnefo » snf-ganeti » ganeti-local

There are no limitations regarding disk images used, as long as the

description is provided. Any hardware described in a proper format

(i.e. CIM - Common Information Model) is accepted, although there is no

guarantee that every virtualization software will support all types of

hardware.

OVF package should contain exactly one file with ``.ovf`` extension,

which is an XML file specifying the following (per virtual machine):

In order to provide secure means of distribution for OVF packages, the

manifest and certificate are provided. Manifest (``.mf`` file) contains

checksums for all the files in OVF package, whereas certificate

(``.cert`` file) contains X.509 certificate and a checksum of manifest

file. Both files are not compulsory, but certificate requires manifest

to be present.

interested in is which formats are supported by VM managers that

currently use OVF.

  OpenStack: mostly ``.vmdk``

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.

                <gnt:Parameters></gnt:Parameters>

                <gnt:Parameters></gnt:Parameters>

      disk0_size = size_in_mb   => calculated after disk conversion

In the :doc:`ovfconverter` we provide examples of

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.

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

``vdi`` or ``vhd`` unless they become part of qemu-img supported formats.

We plan to support compression both for import and export - in gzip

The ``ovf:format`` tag is not used in our case when importing. Instead

we use ``qemu-img info``, which provides enough information for our

purposes and is better standardized.

which case the cluster's default value for that field will be used when

importing.

This provides a safe fallback in case of NAT networks usage, which are

commonly used e.g. in VirtualBox.

The instance name (``gnt:VirtualSystem\gnt:Name`` or command line's

``--name`` option ) has to be resolvable in order for successful import

using ``gnt-backup import``.

    ovfconverter export --format=<format> filename

disk option - both from .ovf file and the command line. Other disk

template options include ``plain``, ``drdb``, ``file``, ``sharedfile``

and ``blockdev``.

	ovfconverter import file.ovf --disk-template=diskless \

          --os-type=lenny-image \

          --backend=vcpus=1,memory=512,auto_balance \

          -H:xen-pvm \

          --net=0:mode=bridged,link=xen-br0 \

          --name=xen.i1

	[...]

	[...]

(``--format``) and compression of the disk into gzip format

(``--compress``). User has also the choice of allowing to skip the

Ganeti-specific part of the OVF document (``--external``).

Example::

	gnt-backup export -n node1.xen xen.i1

	[...]

	ovfconverter export --format=vmdk --ova --external \

	  --output-dir=~/xen.i1 \

	  /srv/ganeti/export/xen.i1.node1.xen/config.ini

called qemu-tools. The same tool is used to determine the type of disk,

as well as its virtual size.

   ovfconverter.rst

=============

OVF converter

=============

Using ``ovfconverter`` from the ``tools`` directory, one can easily

convert previously exported Ganeti instance into OVF package, supported

by VMWare, VirtualBox and some other virtualization software. It is

also possible to use instance exported from such a tool and convert it

to Ganeti config file, used by ``gnt-backup import`` command.

For the internal design of the converter and more detailed description,

including listing of available command line options, please refer to

:doc:`design-ovf-support`

As the amount of Ganeti-specific details, that need to be provided in

order to import an external instance, is rather large, we will present

here some examples of importing instances from different sources.

It is also worth noting that there are some limitations regarding

support for different hardware.

Limitations on import

=====================

Network

-------

Available modes for the network include ``bridged`` and ``routed``.

There is no ``NIC`` mode, which is typically used e.g. by VirtualBox.

For most usecases this should not be of any effect, since if

``NetworkSection`` contains any networks which are not discovered as

``bridged`` or ``routed``, the network mode is assigned automatically,

using Ganeti's cluster defaults.

Backend

-------

The only values that are taken into account regarding Virtual Hardware

(described in ``VirtualHardwareSection`` of the ``.ovf`` file) are:

- number of virtual CPUs

- RAM memory

- hard disks

- networks

Neither USB nor CD-ROM drive are used in Ganeti. We decided to simply

ignore unused elements of this section, so their presence won't raise

any warnings.

Operating System

----------------

List of operating systems available on a cluster is viewable using

``gnt-os list`` command. When importing from external source, providing

OS type in a command line (``--os-type=...``) is **required**. This is

because rven if the type is given in OVF description, it is not detailed

enough for Ganeti to know which os-specific scripts to use.

Import examples

===============

Ganeti's OVF

------------

If you are importing instance created using ``ovfconverter export`` --

you most probably will not have to provide any additional information.

In that case, the following is all you need (unless you wish to change

some configuration options)::

	ovfconverter import ganeti.ovf

	[...]

	gnt-instance import -n <node> <instance name>

Virtualbox, VMWare and other external sources

---------------------------------------------

In case of importing from external source, you will most likely have to

provide the following details:

- ``os-type`` can be any operating system listed on ``gnt-os list``

- ``name`` that has to be resolvable, as it will be used as instance

  name (even if your external instance has a name, it most probably is

  not resolvable to an IP address)

These are not the only options, but the recommended ones. For the

complete list of available options please refer to

`Command Line description <design-ovf-support.rst>`

Minimalistic but complete example of importing Virtualbox's OVF

instance may look like::

    ovfconverter virtualbox.ovf --os-type=lenny-image \

      --name=xen.test.i1 --disk-template=diskless

    [...]

    gnt-instance import -n node1.xen xen.test.i1

.. vim: set textwidth=72 :

.. Local Variables:

.. mode: rst

.. fill-column: 72

.. End: