dambi wrote: > Keith Mitchell wrote: >> >> >> Jan Damborsky wrote: >>> Hey Glenn, >>> >>> I have read through the spec - good work ! >>> Please see my comments below. >>> >>> Thank you, >>> Jan >>> >>> >>> I have couple of general questions - I am not sure if they should >>> be reflected in functional spec or should be captured somewhere else, >>> I think that knowing that information might help to verify if >>> problem statement and project scope have been correctly identified: >>> >>> * what is the main target audience we would like to focus on and >>> satisfy >>> their needs by this project ? >>> >>> * what are other competitive projects (external/internal) that focus >>> on the same target audience, solve the same or similar problem >>> - how they overlap ? >>> - what is the added value of the VMC project ? >>> >>> examples of existing internal/external efforts related to building >>> preconfigured VM images: >>> >>> http://wikis.sun.com/display/Appliance/Virtual+Appliance+Build+Service >>> http://wikis.sun.com/display/Appliance/OpenSolaris+JeOS+Project >>> >>> http://www.vmware.com/appliances/learn/vmware_studio.html >>> http://www.vmxbuilder.com/vmx-builder/ >>> http://www.oracle.com/technology/products/vm/templates.html >>> >>> >>> > 1.2 Scope of Product >>> > While we're primarily targeting VirtualBox for the constructed >>> image we >>> > should be able to support other hypervisors that support the Open >>> Virtual >>> > Machine Format which is what we'll use for the constructed images. >>> >>> Speaking about OVF, it seems it is implicitly assumed that OVF will be >>> created/manipulated by means of VirtualBox APIs. What are the >>> limitations >>> of that approach with respect to the >>> >>> * control over how OVF is actually generated >>> * what type of customization is needed and can be done with respect >>> to needs of another hypervisors which are to supported (XEN, vmWare ?) >>> >>> Were other tools considered which might be used to satisfy requirements >>> identified in that area, for instance >>> >>> http://open-ovf.wiki.sourceforge.net/ >>> http://www.xen.org/files/xensummitboston08/open-ovf-proposal.pdf >>> >>> >>> > 5.2.4 Exporting a Virtual Machine Disk Image >>> > This project will provide a mechanism using VB interfaces to >>> export a VM's >>> > virtual disk into an OVF file ... >>> >>> I think this is not quite correct, as OVF is XML file serving as >>> 'envelope' >>> to bundle virtual machine(s) configuration(s) including information >>> about >>> format of virtual disks used and where to locate them. >>> >>> Speaking about VB approach, it seems that actually following happens >>> when 'export to OVF' is kicked off: >>> >>> * virtual *.VDI drives are converted to compressed *.VMDK ones >>> * VM configuration along with information about virtual drives >>> (format/spec/location) is exported to *.OVF file >>> >> Hi Jan, >> >> I'm a little confused after reading this. I was under the impression >> that Open Virtualization Format (OVF) specified the "whole package" - >> machine configuration as well as virtual disks, including data on >> those virtual disks. Are you saying that OVF actually is just the >> machine configuration (plus pointers to virtual disks), or that >> VirtualBox's specific implementation of 'export to OVF' doesn't >> package up the virtual hard disk? > > Hi Keith, > > I am sorry about the confusion. Please see below for the exact > wording taken directly from OVF spec > (full at > http://www.dmtf.org/standards/published_documents/DSP0243_1.0.0.pdf) > > ... > 5.1 OVF Package Structure > > An OVF package shall consist of the following files: > * one OVF descriptor with extension .ovf > * zero or one OVF manifest with extension .mf > * zero or one OVF certificate with extension .cert > * zero or more disk image files > * zero or more additional resource files, such as ISO images > The file extensions .ovf, .mf and .cert shall be used. > > > EXAMPLE 1: The following list of files is an example of an OVF package. > package.ovf > package.mf > de-DE-resources.xml > vmdisk1.vmdk > vmdisk2.vmdk > resource.iso > > NOTE: The previous example uses VMDK disk files, but multiple disk > formats are supported. > An OVF package can be stored as either a single unit or a set of > files, see clause 5.3 and 5.4. > Both modes shall be supported. > ... > 5.3 Distribution as a Single File > An OVF package may be stored as a single file using the TAR format. > The extension > of that file shall be .ova (open virtual appliance or application). > ... > 5.4 Distribution as a Set of Files > An OVF package can be made available as a set of files, for example > on a standard Web server. > > 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).
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). -Keith > >> >> -Keith >>> >>> Glenn Lagasse wrote: >>>> Hi All, >>>> >>>> I've uploaded the functional specification for this project to be >>>> reviewed at: >>>> >>>> http://opensolaris.org/os/project/caiman/VMC >>>> >>>> For anyone who doesn't know, the VM Constructor project is intended to >>>> enhance the distribution constructor to allow it to create >>>> preconfigured >>>> and preinstalled virtual machines which can be used by VirtualBox (and >>>> any other hypervisors that support and can consume OVF images). >>>> >>>> Please direct any feedback to this alias/thread. >>>> >>>> Thanks! >>>> >>> >>> _______________________________________________ >>> caiman-discuss mailing list >>> caiman-discuss at opensolaris.org >>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >> _______________________________________________ >> caiman-discuss mailing list >> caiman-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >
