VM guest customization

[thelittlemouse]

Hi

How can we determine if the guest customization of the VM has finished?

In the VM section of the VAPP there is a flag called needCustomization. This is true by default

if customization is needed.

After (1-2 seconds later) the VM starts this flag jump to false, but the VM is not yet customized,

The VM approximately 1 min later reboots (end of customization).

So how can we detetrmine if the customization has finished.

(There is no change in the powerOn status of the VM)

Thanks Denes

[aneverov]

Hi Denes,

Well, currently there is no easy way. vCenter events are not posted consistently in VCD 5.1 and even when they are, there might still be final reboot. The best you can do is described at http://blogs.vmware.com/vsphere/2012/06/using-a-guest-customization-script-to-tell-when-vappvm-is-re....

"needCustomization" is internal flag which indicates that something has changed and customization needs to trigger. In VCD 5.1 it's not the only one - there is also one such flag per NIC. So, it's all of them combined + "customization enabled" + Tools version >= 7299 + some other factors for particular corner-cases which result into decision whether customization needs to trigger. I strongly not recommend relying on those, since implementation may change at any point, even between "update" releases.

/Andrii

[thelittlemouse]

Hi

Thanks for the help. Is there any way of determining from either the vCloud (preferably) or from vCenter if the VM has stated?

The link provided shows how to determine if the VM has been started from inside the guest operating system.

The only idea that I got is the following:

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.

Is there any workaround for this?

Thanks Denes

[aneverov]

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

[thelittlemouse]

Hi

Thanks for the help. If I got your answer clear than there is no possibility to convey any

information from the guest VM to VMware, where this information is available through

the vCenter API (with the exception of the small png of the screen).

Use case 1

I am provisioning VMs to external services using the vCloud API (I have no knowledge of

the VM with exception that VMware tools is installed). The IP is allocated to the VM in a

static way. I would like to notify the external service that the VM is running and is ready

for use. To this I would like to outwait the power cycle of the VM (guest customization of

networking).

Use case 2

After the VM starts up (linux) it generates a new RSA key of for the SSH service. I would like

to retrieve the fingerprint of the key on a secured channel. So when the external service first

connects to the VM is able to verify it's identity. 2 ideas to this

- use guest customization script to set the fingerprint to the VMX (or some other property) and

retrieve it from vCloud

- print the fingerprint to the console output and retrieve the console output

(these two are not possible in vCloud)

In either of the use cases I do not want to deploy a "service" in the cloud to provide a "callback"

like functionality.

If you have any ideas how to solve this that would be very helpful. I would really want to

avoid using vCenter (defeats the purpose of vCloud).

Thanks

D.

[aneverov]

Hi

Regrettably I'm not aware of any other possibility than "calling back" via network for VCD 5.1.

Thanks for describing your use-cases - those perfectly make sense. But I still can't get to the bottom of it. When you say 'I do not want to deploy a "service" in the cloud to provide a "callback"' - so why is that? Could you elaborate a little bit more?

I mean you already have some piece of software (let's call it "controller") running somewhere which instructs VCD to do provisioning via API. Your VMs have network access. So, why can't they just report back to the "controller" somehow? It doesn't require changing anything inside the VM. You could use pretty "generic" mechanisms like creating file via NFS. You could do even more sophisticated things like Base64 encoding some program/script, delivering it via pre-/post-customization script into the guest and invoking from there. Some folks deliver certificates in this way. There are some size limitations with this approach, but those could be worked around too.

In order to contact your "controller", you would provide its IP via OVF property (set from the "controller" on a particular VM via VCD API) and read it withing the pre-/post-customization script. That would perfectly solve your use-case 1). In the very same way you could establish SSL access to your "controller" by pushing its fingerprint via another OVF property such that VM from the use-case 2) could use that to verify the "controller" and "post" it's fingerprint. There is a great blog post about OVF properties: http://blogs.vmware.com/vsphere/2012/06/leveraging-vapp-vm-custom-properties-in-vcloud-director.html

At the end your "controller" collects the same info as it would by polling VCD, it's more a question of topology.

I do understand your pain, so I'm definitely not trying to "sell" you anything. Just trying to understand better while focusing on finding acceptable interim solution. As I mentioned before - we're working on other more flexible mechanisms. But that may take some time and while you could adapt the suggested approach immediately.

/Andrii