Karen Tung wrote: > Joseph J. VLcek 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. >> >> >> Joe > Why would such an option make it less easy to use? As with all > parameters > in the manifest, we will provide defaults, and if people don't want, > they don't > need to specify anything. Also, I don't think we would allow every > single option for creating a VM to be configurable via our manifest, > only the ones that would matter > for a user, such as the size of the virtual hard disk. > > --Karen > > a VM > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss Correct me if I'm wrong, but I think the initial solution suggestions include the following:
1) VM Configured by manifest, user given basic set of options 2) VM Configured by manifest, user given full set of options 3) VM Configured externally, VM-image-constructor is pointed at externally configured VM and installs onto it. Or is the 1st option going to be a VM completely configured with defaults we define, with almost no configure options by the user? If I'm understanding the basic options correctly, option 2 is where things get sketchy and difficult for the user when compared with option 3. Assuming that a VM user already knows how to set up their own VM, is there any reason to ask them to re-learn how to configure their VM through our manifest? One of the problems previously discussed is that the user could pick a "bad set" of options. These are all just thoughts that come from my attempts to understand the desired product. It seems that, regardless of how it's done, at some point the constructor will need a fresh empty VM instance to install into. Given that, it would appear that it wouldn't be that hard to provide a hook into the constructor. Basic users could have the VM configured for them; advanced users could skip that step and provide a VM that they set-up. It doesn't appear mutually exclusive to provide both options, and assuming we want to provide the "user-friendly" method regardless, adding the advanced option would be minimal additional work. -Keith
