Hi Denes,
> Thanks for the help. Is there any way of determining from either the vCloud (preferably) or from vCenter if the VM has stated?
Well, you just use the same approach by putting code in the "precustomization" block. That one is executed at the very beginning.
(There are some corner-cases like:
- workaround for Windows 8 "respecialize" operation which happens before and may result in additonal reboot
- in 5.1 update releases there was in improvement for Vista+ OSes to configure networking just before to allow folks to activate against KMS in order to avoid "rearms" issue)
> The OVF allows to set ProductSections wiht user modifyable property. If the OVF is imported to vCenter directly
> it is possible to set these variables from the guest VM through VMware tools (and read it from the vCenter API)
> However if the OVF is imported in vCloudc this ProductSection is only visisble from the guest VM as a
> read only Propery in the guestinfo.ovfenv variable.
I think there is some confusion here. OVF properties are part of the OVF spec and are basically a mechanism of delivering certain info into the guest. We do allow users to change value of those in VCD UI, some properties remain constant (userconfigurable == false), others are populated automatically (you can hook values to VCD networks, like "give me Gateway", etc.). OVF properties are delivered to the guest via OVF environment. OVF env itself is a different type of property - VMX property (guestinfo.ovfEnv) provided by the platform. VM can change its own OVF env by doing "info-set" like I posted in another your question. But that won't be visible to VCD and won't be persisted.
The VMX property mechanism is broader. You can set certain VMX properties which will be persisted. Or at least you can actually setup hooks in the platform to listen for those changes. It can be done via something called Property Collectors which are setup in vCenter.
> from inside the guest operating system.
The general recommendation would be to use networking to post some sort of notification by yourself. I mean you could deploy your own service with REST API and do a PUT/POST from within "pre/postcustomization" block. It could be even simplier like creating some file on shared NFS storage.
In addition to that you can use OVF properties to inject IP address of such service. That would be the simpliest for VCD. For pure vCenter there is something called vServices Components Framework. But as far as I know it's not fully hocked up to VCD, so you would have to know which vCenter manages VM which kinda defeats purpose of VCD.
I think that might work even in case where you setup only vApps with vApp-level networks. But you find this approach completely unacceptable, I would be interested to hear more about your use-case.
Anyways, if you completely don't like network service approach, you can go Property Collectors approach. But again, to my knowledge, VCD doesn't provide convenient way to setup those, so you would have to do it via vCenter which again defeats the purpose (but maybe not for your use-case).
I can only add that VCD architecture evolves, so it's quite possible that in the future releases there will be other more user-friendly mechanisms. But I won't go into that.
/Andrii