* Keith Mitchell (Keith.Mitchell at Sun.COM) wrote: > > > 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.
Yes, when I refer to ICT tasks I'm talking about *any* tasks that need to be done after bits are transferred to complete the installation. >> >> 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. To expand on this, a bootable AI image is (likely) going to be a new image type that the DC can produce. So it's conceivable that someone could create one (for a different purpose) and then want to use it to populate a virtual machine. >> >> 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. Cheers, -- Glenn
