I don't really understand the architecture or exact purpose of this appliance, but the best way to get a VM up and running without ever asking for an IP address is to use DHCP. I know that this is obvious, and probably not what you wanted, but without further details that's the best that I can offer. Studio-built appliances are set up out of the box to configure an IP address from a DHCP server.
If the vm/appliance is downloaded by a user to run on his local box, and dhcp isn't running, how do appliances created by VMware Studio operate?
Although I don't know the Studio app, I'm fairly positive it doesn't impose that the user of a vm studio app should have dhcp running on their box.
Unless the VM Studio process provides it's own dhcp process, !!
It is up to the author of the appliance to handle this however they want. Out of the box, Studio appliances will look for a DHCP server. But if you do not want any interaction from the user to set an IP address in your appliance, that's the normal choice. vCenter will provide an IP address to a VM without user interaction (transient IP address from an IP Pool), but that means that the admin of the platform must have previously set up an appropriate IP Pool, and the deployer of the appliance must know the network to attach the VM to (that has the appropriate IP Pool) to acquire the address. Studio just exposes the various mechanisms that the OS and vCenter provide; it is up to the author to choose how they want to use these mechanisms.
So if I understand you, you're saying that I could setup a pool of 5 192.168.1 addresses, and a pool of 5 10.0.0 addresses, and have the user select an IP from this pool of 10 addresses. OK, might work, but regarding the gateway/routerIP, the process would have to have a way of generating this from the user's/host env, and then inserting this data into the appliance.
Does studio's wrapping process allow for this kind of interaction?
In other words, is there a way to insert data from the user's host environment into the vm/appliance during the user installation process.
No, this is not something the author can do; this is not a Studio mechanism. This is solely a mechanism in vCenter. What you would do in your appliance is set it up to get the IP properties from an IP Pool (Output tab, IP Address Deployment Choices: in Studio 2.5, the option is called "Set DHCP/Fixed/Transient Ip Address using Ip Pools"; in Studio 2.6. the option is called "Prompt for an IP Address and retrieve additional parameters from an IP Pool"). You would then have to instruct the user's vCenter admin to set up an IP Pool of addresses and attach it to a vCenter network, which the eventual deploying user would then specify when they deployed the appliance. The IP Pool is assigned other details like the netmask and gateway, and these are all provided to the appliance via OVF properties by vCenter. Studio reads these OVF properties, and programs the networks appropriately.
Neither Ip Pools nor the OVF format were invented by Studio, and we cannot control IP Pools from an OVF. These are all features of vCenter that Studio is exposing, but Studio is limited by the functionality that OVF provides at deployment time.
It is unfortunate that there is not much documentation on the OVF property and IP Pools features of vCenter in vCenter's own documentation. That's why we have tried to put some of this in Studio's documentation. You can read the Studio 2.6 developer guide, and search for "OVF prop", for example. You can see some of the IP Pool documentation on page 98 and 99 of the developer guide. You can get the guide here: https://www.vmware.com/support/developer/studio/studio26/studio_developer.pdf
In a word, ouch!
Sounds like a painful situation, and given that the appliance would be geared towards regular people, it wouldn't work. The target user would simply download vmplayer, download the appliance app, and run it.. The idea would be that the vmplayer/appliance would be a bundled process.
However, the issue of the IP conflict is still required to be solved...
How about this approach:
The appliance will be used to pull data from a master server, process it internally, and then return the data to the master server.. There's no need for any process, or user interaction with the appliance where the external process has to initiate a connection to the appliance. All network/interaction with the net is established from the appliance.
This requires that the appliance have a predetermined DNS IP, as well as dhcp, which could/should be able to be the vmware supplied dhcp process. The appliance would be created/built, and distributed using NAT, with dhcp.
However, this in and of itself might still have conflicts with the guest IP, and the user's host system.
To get around this, the process can have multiple appliances, with the difference being the NAT subnet for each appliance. Since we don't care, the IP subnet can be 10.0.0... , 192.168.1... etc... and the download process could have the user specify what their current IP is. The download process would provide an appliance that, in theory, wouldn't conflict with the user's host system.
This approach could then allow the user to download an appliance that would have the underlying apps, and the ability to connect back to the master server, while not conflicting with the user's host system.
Yes, well, this is the primary reason that the default in 2.5 (and 2.6 as well), is not to use IP Pools. They are just too confusing, even for the vCenter experts out there. So, the easiest is still to rely on DHCP, and prompt the user for addresses if you need static IPs. Inventing and using private IP addresses on a network infrastructure you've never seen before (at the customer site), is tricky, and ill-advised. Note that quite a few companies use the "unroutable" IP addresses for all their internal machines. VMware, for example, makes heavy use of the 10.* addresses. You may need to revisit your appliance architecture, so that this isn't necessary.