Revision 54f834df
b/doc/design-ovf-support.rst | ||
---|---|---|
454 | 454 |
|
455 | 455 |
Typical workflow for the import is very simple: |
456 | 456 |
|
457 |
- read the ``.ovf`` file info memory
|
|
457 |
- read the ``.ovf`` file into memory
|
|
458 | 458 |
- verify manifest |
459 | 459 |
- parse each element of the configuration file: name, disk template, |
460 | 460 |
hypervisor, operating system, backend parameters, network and disks |
... | ... | |
468 | 468 |
|
469 | 469 |
- save gathered information in ``config.ini`` file |
470 | 470 |
|
471 |
Export |
|
472 |
------ |
|
473 |
|
|
474 |
Similar to import, export functionality also uses two classes - |
|
475 |
OVFWriter and OVFExporter. |
|
476 |
|
|
477 |
OVFWriter class produces XML output based on the information given. Its |
|
478 |
sole role is to separate the creation of ``.ovf`` file content. |
|
479 |
|
|
480 |
OVFExporter class gathers information from ``config.ini`` file or |
|
481 |
command line and performs necessary operations like disk conversion, disk |
|
482 |
compression, manifest creation and OVA package creation. |
|
483 |
|
|
484 |
Typical workflow for the export is even simpler, than for the import: |
|
485 |
|
|
486 |
- read the ``config.ini`` file into memory |
|
487 |
- gather information about certain parts of the instance, convert and |
|
488 |
compress disks if desired |
|
489 |
- save each of these elements as a fragment of XML tree |
|
490 |
- save the XML tree as ``.ovf`` file |
|
491 |
- create manifest file and fill it with appropriate checksums |
|
492 |
- if ``--ova`` option was chosen, pack the results into ``.ova`` tarfile |
|
493 |
|
|
471 | 494 |
|
472 | 495 |
.. vim: set textwidth=72 : |
473 | 496 |
.. Local Variables: |
b/doc/ovfconverter.rst | ||
---|---|---|
92 | 92 |
gnt-instance import -n node1.xen xen.test.i1 |
93 | 93 |
|
94 | 94 |
|
95 |
|
|
96 |
Export example |
|
97 |
============== |
|
98 |
|
|
99 |
Exporting instance into ``.ovf`` format is pretty streightforward and |
|
100 |
requires little - if any - explanation. The only compulsory detail is |
|
101 |
the required disk format, provided using the ``--format`` option. |
|
102 |
|
|
103 |
Export to another Ganeti instance |
|
104 |
--------------------------------- |
|
105 |
If for some reason it is convenient for you to use ``ovfconverter`` to |
|
106 |
move instance between clusters (e.g. because of the disk compression), |
|
107 |
the complete example of export may look like this:: |
|
108 |
|
|
109 |
gnt-backup export -n node1.xen xen.test.i1 |
|
110 |
[...] |
|
111 |
ovfconverter export --format=vmdk --ova \ |
|
112 |
/srv/ganeti/export/xen.i1.node1.xen/config.ini |
|
113 |
[...] |
|
114 |
|
|
115 |
The result is then in |
|
116 |
``/srv/ganeti/export/xen.i1.node1.xen/xen.test.i1.ova`` |
|
117 |
|
|
118 |
Export to Virtualbox/VMWare/other external tool |
|
119 |
----------------------------------------------- |
|
120 |
Typically, when exporting to external tool we do not want |
|
121 |
Ganeti-specific configuration to be saved. In that case, simply use the |
|
122 |
``--external`` option:: |
|
123 |
|
|
124 |
gnt-backup export -n node1.xen xen.test.i1 |
|
125 |
[...] |
|
126 |
ovfconverter export --external --output-dir ~/ganeti-instance/ \ |
|
127 |
/srv/ganeti/export/xen.i1.node1.xen/config.ini |
|
128 |
|
|
129 |
|
|
130 |
Known issues |
|
131 |
============ |
|
132 |
|
|
133 |
Export |
|
134 |
------ |
|
135 |
When exporting to **VirtualBox**, you may encounter errors regarding |
|
136 |
network. If that is the case, simply change the network type in options |
|
137 |
to ``NAT``. |
|
138 |
|
|
139 |
|
|
95 | 140 |
.. vim: set textwidth=72 : |
96 | 141 |
.. Local Variables: |
97 | 142 |
.. mode: rst |
Also available in: Unified diff