在 ESXi 上导出虚拟机的时候，vSphere Web 端只能导出 ovf 格式的虚拟机，无法导出 OVA 格式的，使用 vSphere client 能导出这两种格式。看来一哈官方文档和标准手册，才明白。其实 OVA 是 ovf 的打包文件，导入 ova 格式的时候会自动解包出虚拟机的元数据信息。
OVF
The OVF descriptor contains the metadata about the OVF package. This is an extensible XML document for encoding information, such as product details, virtual hardware requirements, and licensing.
zero or more additional resource files, such as ISO images
.mf
An OVF package may have a manifest file containing the SHA digests of individual files in the package.OVF packages authored according to this version of the specification shall use SHA256 digests. The manifest file shall have an extension .mf and the same base name as the .ovf file and be a sibling of the .ovf file. If the manifest file is present, a consumer of the OVF package should verify the digests in the manifest file in the OVF package by computing the actual SHA digests and comparing them with the digests listed in the manifest file. The manifest file shall contain SHA digests for all distinct files referenced in the References element of the OVF descriptor and for no other files.
翻译一哈
一个 OVF 包可能会有一个
file
usage
need
one OVF descriptor with extension .ovf
虚拟机配置信息
必须
zero or one OVF manifest with extension .mf
SHA256
非必须
zero or one OVF certificate with extension .cert
验证证书
非必须
zero or more disk image files
虚拟机磁盘
非必须
zero or more additional resource files, such as ISO images
其他资源
非必须
下面看一个 ovf 文件的示例 ，可以看出 ovf 是 xml 格式的，描述了虚拟机的配置信息、元数据信息
An OVF package can be stored as either a single compressed file (.ova) or a set of files
An OVF package may be stored as a compressed OVF package or as a set of files in a directory structure. A compressed OVF package is stored as single file. The file extension is .ova (open virtual appliance or application).
In addition, the entries shall be in one of the following orders inside the OVF package:
1) OVF descriptor
2) The remaining files shall be in the same order as listed in the References section
or
1) OVF descriptor
2) OVF manifest
3) OVF certificate
or
1) OVF descriptor
2) The intermediate files shall be in the same order as listed in the References section
#define TMAGIC "ustar"/* ustar and a null */ #define TMAGLEN 6 #define TVERSION "00"/* 00 and no null */ #define TVERSLEN 2
/* Values used in typeflag field. */ #define REGTYPE '0'/* regular file */ #define AREGTYPE '\0'/* regular file */ #define LNKTYPE '1'/* link */ #define SYMTYPE '2'/* reserved */ #define CHRTYPE '3'/* character special */ #define BLKTYPE '4'/* block special */ #define DIRTYPE '5'/* directory */ #define FIFOTYPE '6'/* FIFO special */ #define CONTTYPE '7'/* reserved */
#define XHDTYPE 'x'/* Extended header referring to the next file in the archive */ #define XGLTYPE 'g'/* Global extended header */
/* Bits used in the mode field, values in octal. */ #define TSUID 04000 /* set UID on execution */ #define TSGID 02000 /* set GID on execution */ #define TSVTX 01000 /* reserved */ /* file permissions */ #define TUREAD 00400 /* read by owner */ #define TUWRITE 00200 /* write by owner */ #define TUEXEC 00100 /* execute/search by owner */ #define TGREAD 00040 /* read by group */ #define TGWRITE 00020 /* write by group */ #define TGEXEC 00010 /* execute/search by group */ #define TOREAD 00004 /* read by other */ #define TOWRITE 00002 /* write by other */ #define TOEXEC 00001 /* execute/search by other */
/* tar Header Block, GNU extensions. */
/* In GNU tar, SYMTYPE is for to symbolic links, and CONTTYPE is for contiguous files, so maybe disobeying the "reserved" comment in POSIX header description. I suspect these were meant to be used this way, and should not have really been "reserved" in the published standards. */
/* *BEWARE* *BEWARE* *BEWARE* that the following information is still boiling, and may change. Even if the OLDGNU format description should be accurate, the so-called GNU format is not yet fully decided. It is surely meant to use only extensions allowed by POSIX, but the sketch below repeats some ugliness from the OLDGNU format, which should rather go away. Sparse files should be saved in such a way that they do *not* require two passes at archive creation time. Huge files get some POSIX fields to overflow, alternate solutions have to be sought for this. */
/* Sparse files are not supported in POSIX ustar format. For sparse files with a POSIX header, a GNU extra header is provided which holds overall sparse information and a few sparse descriptors. When an old GNU header replaces both the POSIX header and the GNU extra header, it holds some sparse descriptors too. Whether POSIX or not, if more sparse descriptors are still needed, they are put into as many successive sparse headers as necessary. The following constants tell how many sparse descriptors fit in each kind of header able to hold them. */
/* Extension header for sparse files, used immediately after the GNU extra header, and used only if all sparse information cannot fit into that extra header. There might even be many such extension headers, one after the other, until all sparse information has been recorded. */
/* The old GNU format header conflicts with POSIX format in such a way that POSIX archives may fool old GNU tar's, and POSIX tar's might well be fooled by old GNU tar archives. An old GNU format header uses the space used by the prefix field in a POSIX header, and cumulates information normally found in a GNU extra header. With an old GNU tar header, we never see any POSIX header nor GNU extra header. Supplementary sparse headers are allowed, however. */
structoldgnu_header {/* byte offset */ char unused_pad1[345]; /* 0 */ char atime[12]; /* 345 Incr. archive: atime of the file */ char ctime[12]; /* 357 Incr. archive: ctime of the file */ char offset[12]; /* 369 Multivolume archive: the offset of the start of this volume */ char longnames[4]; /* 381 Not used */ char unused_pad2; /* 385 */ structsparsesp[SPARSES_IN_OLDGNU_HEADER]; /* 386 */ char isextended; /* 482 Sparse file: Extension sparse header follows */ char realsize[12]; /* 483 Sparse file: Real size*/ /* 495 */ };
/* OLDGNU_MAGIC uses both magic and version fields, which are contiguous. Found in an archive, it indicates an old GNU header format, which will be hopefully become obsolescent. With OLDGNU_MAGIC, uname and gname are valid, though the header is not truly POSIX conforming. */ #define OLDGNU_MAGIC "ustar "/* 7 chars and a null */
/* The standards committee allows only capital A through capital Z for user-defined expansion. Other letters in use include: 'A' Solaris Access Control List 'E' Solaris Extended Attribute File 'I' Inode only, as in 'star' 'N' Obsolete GNU tar, for file names that do not fit into the main header. 'X' POSIX 1003.1-2001 eXtended (VU version) */
/* This is a dir entry that contains the names of files that were in the dir at the time the dump was made. */ #define GNUTYPE_DUMPDIR 'D'
/* Identifies the *next* file on the tape as having a long linkname. */ #define GNUTYPE_LONGLINK 'K'
/* Identifies the *next* file on the tape as having a long name. */ #define GNUTYPE_LONGNAME 'L'
/* This is the continuation of a file that began on another volume. */ #define GNUTYPE_MULTIVOL 'M'
/* This is for sparse files. */ #define GNUTYPE_SPARSE 'S'
/* This file is a tape/volume header. Ignore it on extraction. */ #define GNUTYPE_VOLHDR 'V'
/* Solaris extended header */ #define SOLARIS_XHDTYPE 'X'