1 person found this helpful
Categories are poorly implemented in the OVF specification, and I've lobbied the DMTF to change them. The problem with them is that they are very un-XML-ish. If a Category element is seen, *all* the properties from then on (in that ProductSection) go into that category, and there is no way to stop the Category except to define another element. That said, they are not exposed in the Studio UI. However, many customers use our post-creation script mechanism to add them after the OVF is created. That way, the entire build mechansim and process is still contained in the build profile.
All the Studio build profile templates have an example post-ovf-creation script in them. Use the ovf signing post-ovf-creation script as an example.
Look for the section
<vadk:DistributionFormat vadk:format="ovf" ...
and a sub element under that called
within that element can be any number of <vadk:Script> elements that define a script to be executed after the OVF is created. In a default build profile, you'll find an example of one that signs the OVF.
There is also a comment in that script that tells you what to expect as the first argument of your script:
# This script will be passed the full path to the ovffile as $1
Thx for your quick response.
Not an easy path... but I will check it out.
Being that I already have a few vApps deployed at customer sites, how can I upgrade their existing vApp OVF properties?
Is there a way to push a new XML file into an existing vApp (in vCenter)?
If this can be done, it can be used to apply categories as well
No, vCenter does not give you any way to do that. Studio would use the facility, if it existed. OVF properties are only set at deploy time, and after that, only through the UI or the vSphere API. And if they are set through the UI or the vSphere API, they will only appear in the VM after the VM is cold power cycled (a reboot of the VM is not sufficient). I believe there is an OVF community forum; you can try to lobby there. :-)