I have the same question. CJ, did you figure this one out? VMware people, can you answer that please?

Hi CJ,

  Can you please explain more, I am having the same issue. I already raised the issue here:  http://communities.vmware.com/message/2162693#2162693

Thanks for your help

CJ,

It is relatively easy to add support in a Studio Build Profile for both hostname and timezone, but it is necessary to edit the Build Profile XML file to achieve the updates.

You need to open the XML in an editor of choice - for example "vi" - and look for the PropertySection_Type.  It should look something like:

<Section xsi:type="vadk:PropertySection_Type">
                <Info/>

   ...............

</Section>

You can now add new properties after the "<Info/>" but before the closing "</Section>".

Hostname

<Property ovf:key="vami.hostname" ovf:type="string" ovf:userConfigurable="true" ovf:value="" ovf:qualifiers="MinLen(0),MaxLen(65535)">
                        <Label>Hostname</Label>
                        <Description>Linux hostname or fully qualified domain name for VM</Description>
</Property>

Timezone

<Property ovf:key="vamitimezone" ovf:type="string" ovf:userConfigurable="true" ovf:value="Etc/UTC" ovf:qualifiers="ValueMap{&quot;Pacific/Samoa&quot;, &quot;US/Hawaii&quot;, &quot;US/Alaska&quot;, &quot;US/Pacific&quot;, &quot;US/Mountain&quot;, &quot;US/Central&quot;, &quot;US/Eastern&quot;, &quot;America/Caracas&quot;, &quot;America/Argentina/Buenos_Aires&quot;, &quot;America/Recife&quot;, &quot;Etc/GMT-1&quot;, &quot;Etc/UTC&quot;, &quot;Europe/London&quot;, &quot;Europe/Paris&quot;, &quot;Africa/Cairo&quot;, &quot;Europe/Moscow&quot;, &quot;Asia/Baku&quot;, &quot;Asia/Karachi&quot;, &quot;Asia/Calcutta&quot;, &quot;Asia/Dacca&quot;, &quot;Asia/Bangkok&quot;, &quot;Asia/Hong_Kong&quot;, &quot;Asia/Tokyo&quot;, &quot;Australia/Sydney&quot;, &quot;Pacific/Noumea&quot;, &quot;Pacific/Fiji&quot;}">
                        <Label>Timezone setting</Label>
                        <Description>Sets the selected timezone setting for the VM</Description>
</Property>

The period in the hostname property generates an annoying warning on every build, but the process continues without any problems.

The rather strange format of the ValueMap for Timezone is due to the fact that the quote character is a special character for XML, and so must be replaced by "&quot" or the XML parsing will fail.  VMware has enough logic to decode the ValueMap into the correct time zone offset for each of the countries in the list.

Hope this helps,

Robin.

I tried to add the timzone information into my build xml file and I got the dropdown list when deploying to vcenter.

However, the timwzone did not acutally get set--it came up as UTC.

Do I need to put something else in the xml file to hookup the list with a command?

Also, in the example for what to enter in the xml the key shows as vamitimezone iwth not do in there.

I did put a dot as "vami.timezone" for the key.

Also, do I need to do something like &quot;vami.timezone&quot;   instead of using the quotes explicitly?

thanks a lot

We are under pressure to deliver our beta so any help would be a lifesaver

I am sorry to hear you are having problems with setting the timezone for your virtual machine.

This should be a very simple process since it is pretty much a copy of VMware Studio's vApp build process.

However, please be careful in the spelling and syntax of the XML - the code snippet is a direct copy from my virtual machine so should be fine. For some bizarre reason, this parameter does NOT need a period between vami and timezone.  In fact, the current VAMI code will ignore your parameter if it finds a period between the two.  Unusual behaviour, but the VAMI code is pretty easy to understand and this is how it is written.

It is easy to verify the process has worked at deployment time by interrogating the environment file for your VM.

From a shell prompt - /opt/avaya/bin/ovfenv - should display all of the key/value pairs that are presented to your VM by vCenter at boot time.

You should see  - [vamitimezone]= - with a suitable value ( other than UTC ).

There is no need to write any code to process this value, since the existing vaos daemon will extract and apply this value using VAMI.

Hope this helps,

Robin.

Thanks so much for your help.  The issue of period versus no period in the vami timezone was definitely on source of confusion.

I will re-try and hope for better results.

Your answer is very helpful and timely as we are trying to get the first release of our HA product for vSphere out by end of this week.

My work-around was to have the user set timezone on appliance bootup with the Ubuntu linux command:

dpkg-reconfigure tzdata.  Will be much nicer to do this during deployment.

Kris Dines | Senior Software Engineer | Vision Solutions | +1 (317) 813-1181 | Kris.Dines@visionsolutions.com

Double-Take | iTERA | MIMIX | Website<http://www.visionsolutions.com/> | Blogs & Social Media<http://www.visionsolutions.com/Popular-Resources/socmedia.aspx>

The contents of this e-mail (and any attachments) are privileged and confidential. Unauthorized use is strictly prohibited(+).

Sure - no problem.

Please ping me if it still fails to work for you,

Robin.

Property ovf:key="vami.hostname"

produces

"[vami.vami.hostname"

when running ovfenv

so should the entry be

Property ovf:key="hostname"

will check anyway.

P

I received some information regarding this.

The ovf process itself uses periods as delimiters at some point so having properties with periods often produces undesirable results. Although it does work fine if you manually enter these in the custom properties section of the ovfEnv.xml

The correct key is most definitely "vami.hostname" - I am looking at my build.xml and the deployed VM, and "/opt/vmware/bin/ovfenv" returns a key called "[vami.hostname]" - I am using VMware Studio V2.6.

The property should be declared as a string with userConfigurable set to true.

Hope this helps,

Robin.

All,

In my build xml file I use the following for password and hostname in the Property section (with periods): -- it works fine.

I enter this directly in the .xml file rather than via the Studio tool itself.

The contents of this e-mail (and any attachments) are privileged and confidential. Unauthorized use is strictly prohibited(+).