Partially Powered Off

[klaaslauwers]

Hi,

We are creating a vApp and virtual machine by sending the following body to a VDC instantiation: (the x’s should be replaced)

<InstantiateVAppTemplateParams name='xxxxx' xmlns='http://www.vmware.com/vcloud/v1' xmlns:ovf='http://schemas.dmtf.org/ovf/envelope/1' deploy='true'>

<Description>{1}</Description>

       <InstantiationParams>

       <NetworkConfigSection>

              <ovf:Info>Configuration parameters for vAppNetwork</ovf:Info>

              <NetworkConfig networkName='xxxx'>

                     <Configuration>

                           <ParentNetwork href='xxxx'/>

                           <FenceMode>bridged</FenceMode>

</Configuration>

             </NetworkConfig>

</NetworkConfigSection>

       </InstantiationParams>

<Source href='xxxx'/>

</InstantiateVAppTemplateParams>

This all goes well.

Next, we are trying to configure the guestcustomization and the networkconnection of that vApp and that virtual machine by sending the following XML bodies to the guestCustomizationSection of the virtual machine and the networkConnectionSection of the vApp respectively. Again, the x’s should be replaced:

<GuestCustomizationSection xmlns='http://www.vmware.com/vcloud/v1' xmlns:ovf='http://schemas.dmtf.org/ovf/envelope/1'

type='application/vnd.vmware.vcloud.guestCustomizationSection+xml' href='xxxx' ovf:required='false'

       xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'

xsi:schemaLocation='http://schemas.dmtf.org/ovf/envelope/1 http://schemas.dmtf.org/ovf/envelope/1/dsp8023_1.1.0.xsd http://www.vmware.com/vcloud/v1 http://xxx/schema/master.xsd'>

<ovf:Info>Specifies Guest OS Customization Settings</ovf:Info>

       <Enabled>false</Enabled>

       <ChangeSid>true</ChangeSid>

<JoinDomainEnabled>true</JoinDomainEnabled>

       <UseOrgSettings>true</UseOrgSettings>

       <AdminPasswordEnabled>true</AdminPasswordEnabled>

       <AdminPasswordAuto>false</AdminPasswordAuto>

       <ResetPasswordRequired>false</ResetPasswordRequired>

       <CustomizationScript/>

       <ComputerName>xxxx</ComputerName>

       <Link rel='edit' type='application/vnd.vmware.vcloud.guestCustomizationSection+xml' href='xxxx'/>

</GuestCustomizationSection>

<NetworkConnectionSection xmlns='http://www.vmware.com/vcloud/v1' xmlns:ovf='http://schemas.dmtf.org/ovf/envelope/1' type='application/vnd.vmware.vcloud.networkConnectionSection+xml' href='xxxx' ovf:required='false' xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xsi:schemaLocation='http://schemas.dmtf.org/ovf/envelope/1 http://schemas.dmtf.org/ovf/envelope/1/dsp8023_1.1.0.xsd http://www.vmware.com/vcloud/v1 http://xxxx/schema/master.xsd'>

<ovf:Info>Specifies the available VM network connections</ovf:Info>

       <PrimaryNetworkConnectionIndex>0</PrimaryNetworkConnectionIndex>

       <NetworkConnection network='xxxx'>

              <NetworkConnectionIndex>0</NetworkConnectionIndex>

<IsConnected>true</IsConnected>

              <IpAddressAllocationMode>POOL</IpAddressAllocationMode>

      </NetworkConnection>

      <Link rel='edit' type='application/vnd.vmware.vcloud.networkConnectionSection+xml' href='xxxxx'/>

</NetworkConnectionSection>

Again, this all goes smoothly.

We start encountering problems when trying to power on / power off the virtual machine. Whatever we try – be it powering off / on the vApp or the machine itself – we can’t seem to retrieve the right actions and state afterwards. An example to clarify what I mean by this: suppose we made a virtual machine by executing the above steps. Next, we send a Power On (/action/powerOn) command to the vApp (or vm). Later, we send a Power Off (/action/powerOff) command. When we look in vCenter / vCloud director, we see that the virtual machine is stopped, but the vApp is still ‘running’ in a Partially Powered Off state. We can’t seem to get it completely stopped. This is a problem because we want to show the users the different actions on that virtual machine, given its state. By getting stuck in that Partially Powered Off state, there is no delete action in the Link XML Nodes received by querying the virtual machine.

Thanks in advance,

Regards,

Klaas

[geoffaviarc]

this appears to be a bug that vmware need to know about.  I saw the same behaviour.

I'm working around this by iterating through all the vm's of the vApp to power them off.  The correct status resumes once you power them all off one by one.

[mreferre · Accepted solution]

I am not sure if this is the deal but there are actually a couple of actions that govern the state of the VM. They are deploy and power-on to start the VM. Power-off and undeploy to stop it. These should be 4 different API calls. The UI used to expose all these but then we decided that we may have confused end-users as they just want to push a button and power it on (or off). That's what the two buttons in the UI do today (the green one calls two API calls and same does the red one).

If you are building your app against the API you need to use the four calls accordingly. I am not an API person ... so apply your programming skills filters to what I am saying here. 

I am not sure we are talking about the same thing but usually those "partially powered on/off....." states are due to this. HTH.

Massimo.

[klaaslauwers]

Massimo,

First Powering Off the vApp and then undeploying did the trick.

Thanks for the help!

Regards,

Klaas

[jake_robinson_b]

Massimo,

Why do we have to undeploy to get something completely powered off? Just curious.

Cheers,

Jake

Edit: Thought I would mention this is basically the same question I asked in another thread: http://communities.vmware.com/thread/302858

[mreferre]

I don't have all the details but basically we use "deploy" to do preliminary steps like connecting the vNic to the proper switch, assigning an IP address (if from Static Pool) etc etc.

It's an intermediate step that for the end-user doesn't mean anything (hence why now the UI doesn't show it anymore - it used to show it up until the beta) but it's used internally to make the solution more scalable / efficient.

Massimo.

[kirilk]

It is a bit strange but undeploy with power off is the operation that shuts down a vApp completely. No need to call power off first.  Undeploy stops the service VM of vShield that is used to connect vApp networks.  I hope this helps. This a bit strange functionality is to give a bit more flexibility from API - one can power off all VMs without releasing network resources with power off or suspend. Alternatively undeploy with appropriate flag does the same but also releases the network resources. UI only provides complete power off with undeploy.

[jake_robinson_b]

Strange is definitely the operative word. I think I am going to work up some documentation and submit a bug or... I dunno, a plea to change the functionality?

--Jake

[klaaslauwers]

Thanks for clearing out this functionality. If I may be honest, this part of the API indeed lacks a well documented example.

Kind regards,

Klaas

[geoffaviarc]

Yes, documentation and completness would be this APIs biggest let downs.

Sent from Samsung Mobile

[adamalsalman]

It is also worth noting that powerOff is the equivalent of pulling the plug of the computer out the socket. You really need to do a shutDown but the problem is that the shutDown API call returns a 204 No Content and therefore no Task reference for you to track the progress of the shutDown.

This is because the shutDown request sends a signal to the guest OS and the vCloud API cannot tract the progress or verify the result of this requested operation.