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

Reply via email to