About da VIBs

VMware's 4th generation hypervisor's patching method is mainly based on a new package format, known as VIB. The abbreviation stands for vSphere Installation Bundle. Basically, a VIB is a unix AR archive. You can unpack any VMware VIB using ar x . By using the unix file command, You will see there are 2 types of VIBs: Debian binary package (format 2.0) and current ar archive. The second one (ar) only used on ESX 4, with the redhat based Service Console. It's VIBs contain 3 files:

• descriptor.xml - It's name contains it's function pretty much. Current vibVersion for example is 1.4.5. The vibType tag says it is an RPM type vib, which means it may only contain an RPM. The pkgfile tag tells the installer the RPM's original name. Other tags state if the package needs maintenance mode or after-remediation reboot on the server, version numbers of the package or suitable ESX build numbers.
• sig.pkcs7 - A digital signature of the package. Used to make it cryptographically impossible to fake an installation file. By using -nosigcheck with esxupdate, You can force to ignore this file. (See http://en.wikipedia.org/wiki/PKCS). This also invalidates Your support for the given ESX based on the argument's "unsupported" help message.
• complete.rpm - The real RPM package, the file renamed from the tag above. See http://www.rpm.org/max-rpm/s1-rpm-file-format-rpm-file-format.html.

The first type, DEB package is a bit more interesting. There are 2 sub-types of this VIB based on descriptor.xml's tag: deb and cross. The deb subtype of Debian based VIBs are used only on ESXi thin hypervisor version, and contain the additional following files (descriptor.xml and sig.pkcs7 are obligatory in every VIB).

• debian-binary - Debian archive version number: 2.0
• control.tar.gz - Control files for the installation method.
• data.tar.gz - Binaries to install/replace.

These are standard Deb package structure files, see http://tldp.org/HOWTO/Debian-Binary-Package-Building-HOWTO/x60.html. There is also another sub-type of the DEB package based VIB, and that is cross. It means, that it contains the 3 debian package structure files, plus an additional short.rpm. This type of VIB may be used on both ESX and ESXi, ESXi probably uses the debian files, while ESX uses the rpm.
This makes a matrix of VIB types/usability/files like this:

VIB main (unix file)	VIB sub (vibType tag)	Suitable Hypervisor	Contained files
ar	rpm	ESX	descriptor.xml, sig.pkcs7, complete.rpm
deb	deb	ESXi	descriptor.xml, sig.pkcs7, debian-binary, control.tar.gz, data.tar.gz
deb	cross	both	descriptor.xml, sig.pkcs7, debian-binary, control.tar.gz, data.tar.gz, short.rpm

Based on this info, and by using a simple VIB as a template, anyone can create a vSphere Installation Bundle. Of course VMware won't grant You a copy of it's PKCS7 signing private key, unless Your company is called, for example, Cisco. So Your custom VIB will fail to install with an error like "error checking PKCS7 signature" or "missing or invalid signature" etc. This is where -nochecksig comes in, and support goes out.
If You have a function on Your custom ESXi farm, that You have to implement on every host after the installation by using the unsupported busybox CLI, than unsigned VIBs may be usable for You. Currently I can think of home-brew scripts for ESXi PXE stateless for example.
Because of the major difference between ESX and ESXi, VMware and 3rd parties have to create most installation/init scripts for every device driver twice. I think most drivers fit into both kernels (at the same build number ofc). Cross VIBs contain the short.rpm as a patch between the debian and redhat install method, for VIBs that have identical scripts and binaries on both hypervisors.