* Keith Mitchell (Keith.Mitchell at Sun.COM) wrote: > >> EXAMPLE: An example of an OVF package as a set of files on Web server >> follows: >> http://mywebsite/virtualappliances/package.ovf >> http://mywebsite/virtualappliances/vmdisk1.vmdk >> http://mywebsite/virtualappliances/vmdisk2.vmdk >> http://mywebsite/virtualappliances/resource.iso >> http://mywebsite/virtualappliances/de-DE-resources.xml >> ... >> >> So OVF spec actually allows both approaches - distributing OVF package >> as set of multiple files or one single TAR archive (which in fact >> just archives of the same set of files) - from observations I have done >> so far Virtual Box uses the former approach - .ovf & .vmdk files >> were created in my case after export finished. >> >> OVF itself doesn't seem to define its own disk format, but allows to use >> any existing one as well as any future one. >> >> Hope it might clarify things a bit :-) >> Jan > Thank you, that helps a lot! It sounds like we need to reword the > functional spec a bit. Our desired output is the "whole package" - The > OVF file, at least one virtual disk (vmdk since that's how VBox does > it), as well as any other additional files. Whether or not we tar it all > up into an OVA (so that it's easier for the user to transport after > completion) is something to consider. It doesn't appear that VBox > currently supports directly importing OVA, which is something to > consider (though, it would be easy enough to specify a flag that lets > the user decide if they want it bundled up into OVA at the end).
We definitely need to reword the functional spec. It's an ommission on my part that I didn't explain we're delivering an OVF file (a config file) as well as the exported virtual disk image. > It sounds like we should also be adding a post-export finalization phase > - which might include items like adding a .cert file, packaging > everything up into the OVA (if desired), etc. This would allow us to let > VBox to do the initial work of creating the final product, but not > restrict us to *only* what VBox itself is capable of (in terms of > exporting). Possibly. What we export (OVF + VMDK vs OVA which contains both) depends on what VB allows us to export as well as what VB and whatever other hypervisors we want to support (xVM for starters) can import. I know xVM can consume (or will be able to) OVF data and a vmdk file. I don't know that they can import an OVA file. I'll follow up with the xVM team on this. Regardless, we can pick one method to start with and it should be relatively easy to add support for the other in later phases. -- Glenn
