This set of patches (well, really only 5/5) introduces a new 'virt-pack'
command that packages a virtual machine image for distribution. To make
that a littel more interesting, it also generates the necesary information
to run the image under VMWare(tm). The intention is to make it as easy as
possible for the budding appliance writer to make their appliance widely
There are lots of choices for a container for a VM image - and they all
suck for various reasons (RPM is useless for Windows users, ZIP on Linux
can't handle archive members bigger than 4GB, tar is slightly unfriendly
for Windows users) I used tarballs since they seem to have the fewest
pitfalls. In the future, another format that looks promising is 7zip; in
my testing the compression it performed was very impressive (and took
impressively long) The Windows implementation of 7zip can read tarballs,
too - in theory; in practice it reads _some_ tarballs, but balks at others,
unclear what causes that.
The VMWare metadata that is added to the image consists of a VMX file and
several VMDK files, one for each disk in the image. The VMX is generally
dumb and conservative, but worked in my simplistic testing with VMWare
Server on XP. VMDK files are primadonnas, despite VMWares docs; I believe
that the ones virt-pack generates do work.
None of the innards of the VM are taken into account by virt-pack; if you
write appliances, you are well served to include a reasonable set of
drivers in the images. Don't cut out support for e1000 or rtl8139 to save a
few bytes - those 'appliances' exist and distinguish themselves by running
only on VMWare and nowhere else.
Anyway, I'd be very interested in any comments/feedback, and even more in
any experiences with using this to package VM images and run them under
libvirt and/or VMWare(tm).
et-mgmt-tools mailing list