Sundar Yamunachari wrote: > 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! >> >> > > General comment: if you have any architecture diagram to explain the > different parts of the VM construction, it will be useful. > > Section 1.4: > > - Are the tasks listed here (boot unattended .................. > Shutdown the VM) constitutes the requirements of bootable AI image? So > the boot image will start the VM, complete the image creation and > shutdown the VM? The VM Constructor will start the VM. Either the VM Constructor or the AI install will shutdown the system after install completes, with AI install being the preferred sender. > > - The post processing ICT tasks will be gone once we have SMF > enhanced profiles project implemented. What are the ICT tasks this > refers to? Glenn correct me if I'm wrong - but, in this case, I think the ICT items mentioned are not anything beyond what is currently used by AI, in which case, they would be replaced by SMF enhanced profiles. > > Section 5.1: > > - Automated Installer currents uses a manifest to decide where to > install and what to install. How will the manifest supplied? There is perhaps a bit of magic hand waving here - the VM constructor is relying on a bootable AI image, but I don't know exactly how such an image would work. The general assumption so far seems to be that the VM constructor performs an essentially hands-off installation once the VM is up and running. It's as if the VM constructor popped an AI CD in the drive of a physical machine, then walked away - for the purposes of this project, it doesn't necessarily matter *how* the AI CD does the install, only that it does it. The exceptions being that the AI install process really needs to provide observability so that the constructor can monitor and report progress to the user (and correct errors when needed and possible), and it needs to shutdown on completion. > > - Just a nit -- AI doesn't use cpio for transfer. The assumption here is that an AI CD could theoretically come with the bits on it, and cpio from the image to the virtual disk, instead of using IPS. See the discussions between Sarah and Glenn on this. > > Section 6.1.2: > > - Does this uses case assume that the user creates the bootable AI > image from some other tools we supply? Yes. > > Section 6.1.3: > - This use case assumes livecd image? No, this use case is similar to the default case. It differs in that, instead of default values for the VM, the user indicates different values. For example, the default setting for RAM might be 1 GB, but (in this use case) the user might explicitly specify to the constructor to create an image with 2 GB of RAM.
Thanks, Keith > > Thanks, > Sundar > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
