Jan Damborsky wrote: > Hi Glenn, > > > Glenn Lagasse wrote: >> Hi Jan, >> >> * Jan Damborsky (jan.damborsky at devcom.cz) wrote: >>> Hey Glenn, >>> >>> I have read through the spec - good work ! >> >> Thanks! I appreciate that. >> >>> 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 ? >> >> The target audience are people that want to create preconfigured virtual >> machines using the distribution constructor. > > Do we happen to know, what their requirements and expectations are with > respect to what they can install into virtual image and what level of > post install configuration will be supported ? > For instance, I am thinking that some people would be interested in > creating OpenSolaris based virtual appliances with application stack > which might be available in different than IPS format - is it something > we might want to consider ?
It is interesting you point this out. Glenn and Keith and I were talking about how folks could get bits into the VM image. The current way would be to get the bits into an IPS repo. but I was thinking it could be valuable to have the AI engine, in addition to pulling bits from IPS also have exra bits built into it by DC. This way if a customer would like to do a custom AI install, or VMC, with bits they develop, they would not have to push the bits to an IPS for AI to pull from. We could provide some, as yet to be defined, method of adding some bits to an AI image that could be copied from the image via CPIO after the IPS transfer. This would provide an easy way for folks to add custom bits to am AI image. > >> >>> * 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 >> >> I've been in touch with the aklite team. There is some overlap, though >> the tools/methods we're using differ. There will be ongoing discussions >> with them to see if there are ways we can sync up. > > Thanks a lot for following up on this ! > >> >>>> 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 >> >> Well, creating OVF is merely exporting a VM from VirtualBox. So there's >> as much control as we need. Which is very little really. >> >>> * what type of customization is needed and can be done with respect >>> to needs of another hypervisors which are to supported (XEN, vmWare ?) >> >> I'm not aware of any special things we need to do to support other >> hypervisors. We'll provide a .ovf file and a .vmdk file. Other >> hypervisors will need to be able to consume those pieces. > > ok. >> >>> 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 >> >> No, these weren't considered because we're using VirtualBox to create >> the image and then we're exporting that image to OVF. If we weren't >> using VirtualBox in the first place, then perhaps we might use some >> other tool, but I don't see a need to consider anything else since VB is >> what we're using and it supports exporting to OVF. >> >>>> 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 >> >> This is correct, an ommision on my part. I'll update the functional >> specification to more clearly state what we're producing (a .ovf file >> which contains the VM configuration data and a .vmdk file which is the >> virtual disk containing the installed bits). > > Thank you for making those changes ! > Jan > > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
