Glenn Lagasse wrote: > * Joseph J. VLcek (Joseph.Vlcek at Sun.COM) wrote: >> Karen Tung wrote: >>> Glenn Lagasse wrote: >>>> One part of the automated VM construction project is that we'll need to >>>> have a VM to install in to. My original thought was that using >>>> VirtualBox's cli VBoxManage, DC could configure a VM with either a >>>> vanilla set of options statically or configure the VM using data >>>> supplied in a manifest. The issue I see is that there are a LOT of >>>> options that one can set for a VM. And providing support for all of >>>> them in a manifest is going to be unwieldy. Using a vanilla set of >>>> options could work, but then we have to decide what those settings are >>>> and do they provide what users (those creating the virtual appliances) >>>> will want. >>>> >>> With all the options that we can pass to >>> the VBoxManage to automatically configure a VM, >>> some are more important than others in terms of creating VM images, and >>> some of them would actually affect the resulting image. One of such >>> example that I can think of is the size of the virtual hard disk. >>> Since the content >>> of the virtual hard disk is the output of VM construction, I would >>> think that >>> people might want to specify their desired size. Other things >>> kinda have to be a certain way in order for things to work at all. >>> Examples of those are amount of memory and networking setting. >>> Without sufficient amount of memory, the ISO might not boot, IPS might >>> not >>> work. Without networking setup correctly, we might not be able to >>> install >>> from the IPS repo on the network. >>> Then, there are other options like sound support >>> that we would not need for creating VM images. >>> >>> Therefore, I don't think we should allow users to specify every single >>> possible option for creating a VM in a manifest, but I think we should >>> give them >>> the option to specify a few. Which ones, I don't know, I guess we >>> can discuss and decide as part of the overall design. >>> >>>> The third option is to have DC take the name of a pre-configured VM from >>>> a manifest and use that to install in to. This would require the user >>>> running DC to create and configure a VM in VirtualBox before running DC >>>> and supplying the name (and possibly a few other bits of relevant >>>> information) in the manifest used to create the virtual appliance. >>>> This option allows us to not 're-invent the wheel' as it were in terms >>>> of configuring VMs but does require some manual setup on the part of the >>>> user before he can actually create his virtual appliance (instead of >>>> just modifying a manifest and running distro_const build). >>>> >>>> Thoughts? >>>> >>>> >>> Allowing users to alternatively provided a pre-configured VM is also a >>> good idea, >>> but I don't think this should be a required thing to do. It should >>> just be an option. >>> >>> --Karen >>> _______________________________________________ >>> caiman-discuss mailing list >>> caiman-discuss at opensolaris.org >>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >> I think allowing the user to provide VM configuration parameters in a >> manifest would make it less easy to use. > > Yeah, there's far too many possible options to support that in a > manifest. > > I think we can have a default config for new VMs which we use to create > the VM unless the user specified a pre-configured VM for us to use. We > might also allow some customization of the default config in the > manifest for a select few VM parameters (size of disk, size of ram for > instance). > > Thanks Joe, >
OK. I now understand the justification for allowing for some manifest driven VM configuration. Let me summarize 1- VM Construction does full VM configuration 2- The user can provide a fully configured VM 3- We identify which VM configuration parameters which most likely may need tweaking and we provide for customization via manifest for them. I think this is what Karen was suggesting too. Thanks! Joe
