Hey Ethan, * Ethan Quach (Ethan.Quach at Sun.COM) wrote: > > > Glenn Lagasse wrote: >> Hey Joe, >> >> * Joseph J VLcek (Joseph.Vlcek at Sun.COM) wrote: >> >>> If I understand correctly you describe 3 scenarios: >>> >>> 1- Configure VM with a set of predefined option settings. >>> 2- Provide for user supplied, manifest driven VM configuration >>> 3- Allow the user to specify the identifier of a pre-configured VM in >>> the manifest. >>> >>> If I got this correct, I think from the users perspective providing 1 >>> and 3 would also provide for option 2. In that, if the user desires >>> a specific configuration in the VM, they can configure the VM and >>> specify it in the DC manifest. >>> >>> This would also allow us to avoid the unwieldy support of the many VM >>> options in a manifest, while at the same time provide the user with >>> a mechanism to utilize VM as they need. >>> >> >> I think you're probably right. If we implement support for 1 and 3, >> then users could create their own custom configured VM and supply it via >> whatever mechanism we have for 3. The question is, are we happy with >> that tradeoff? >> >> Any other thoughts out there? >> > > With #3, would we be any closer to being able to support > virtualization software other than VBox, or are there other > pieces in the process that are virt software specific?
No. Setting up the VM is very much specific to VB. And we're only using VB to do the install inside of and produce the output OVF file. Though VB is our main intended target, xVM could use the OVF file we produce but using xVM to create the OVF file is not a goal. -- Glenn
