Error: "Power State Unknown" "CDS_EVENT_HOSTING_FAILED_POWER_ACTION" in XenDesktop

Error: "Power State Unknown" "CDS_EVENT_HOSTING_FAILED_POWER_ACTION" in XenDesktop

book

Article ID: CTX131267

calendar_today

Updated On:

Description

Machines in Desktop Studio or Desktop Director display a Power State of Unknown.

CDS_EVENT_HOSTING_FAILED_POWER_ACTION

The Citrix Broker Service detected that power action '%1' on virtual machine '%2' failed.
 
This problem is most likely due to a host issue. Check that the configuration of the virtual machine on the host does not prohibit the requested power action. Verify that there are no storage problems on the host. Check that the host connection information is correct.
 
Error details:
Exception '%3' of type '%4'.

Background

The Desktop Delivery Controller (DDC) broker log contains Citrix Pool Management exceptions relating to the machine in question, such as:

23/08/11 15:18:41.7081: HostingManagement:PollForPowerStateUpdates: problem while fetching state for 02e0d308-c9cf-4fbc-9fb2-aaaaaaaaaaaa: Citrix.ManagedMachineAPI.NoSuchManagedMachineException: Exception of type 'Citrix.ManagedMachineAPI.NoSuchManagedMachineException' was thrown. at Citrix.PoolManagement.VMManager.VmmImplementation.MicrosoftScvmmProvider.Connection.Execute(Runspace runspace, Action`1 action) at Citrix.PoolManagement.VMManager.VmmImplementation.MicrosoftScvmmProvider.Connection.GetVM(String id, Runspace runspace) at Citrix.PoolManagement.VMManager.VmmImplementation.MicrosoftScvmmProvider.SCVMMConnector.<>c__DisplayClass44`1.<CallAndRetry>b__42(Runspace runspace) at Citrix.PoolManagement.VMManager.VmmImplementation.MicrosoftScvmmProvider.SCVMMConnector.Call[T](Func`2 worker) at Citrix.PoolManagement.VMManager.VmmImplementation.MicrosoftScvmmProvider.SCVMMConnector.CallAndRetry[T](Func`3 worker)

Environment

The above mentioned sample code is provided to you as is with no representations, warranties or conditions of any kind. You may use, modify and distribute it at your own risk. CITRIX DISCLAIMS ALL WARRANTIES WHATSOEVER, EXPRESS, IMPLIED, WRITTEN, ORAL OR STATUTORY, INCLUDING WITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NONINFRINGEMENT. Without limiting the generality of the foregoing, you acknowledge and agree that (a) the sample code may exhibit errors, design flaws or other problems, possibly resulting in loss of data or damage to property; (b) it may not be possible to make the sample code fully functional; and (c) Citrix may, without notice or liability to you, cease to make available the current version and/or any future versions of the sample code. In no event should the code be used to support ultra-hazardous activities, including but not limited to life support or blasting activities. NEITHER CITRIX NOR ITS AFFILIATES OR AGENTS WILL BE LIABLE, UNDER BREACH OF CONTRACT OR ANY OTHER THEORY OF LIABILITY, FOR ANY DAMAGES WHATSOEVER ARISING FROM USE OF THE SAMPLE CODE, INCLUDING WITHOUT LIMITATION DIRECT, SPECIAL, INCIDENTAL, PUNITIVE, CONSEQUENTIAL OR OTHER DAMAGES, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Although the copyright in the code belongs to Citrix, any distribution of the sample code should include only your own standard copyright attribution, and not that of Citrix. You agree to indemnify and defend Citrix against any and all claims arising from your use, modification or distribution of the sample code.

Resolution

To update the correct host machine ID on the DDC, complete ONE of the following solutions (Solution 1 or Solution 2). 

This issue can also be resolved using other methods.  Some of these are documented here:

Removing the affected VMs and adding them again
Ensuring SCVMM hotfix version are matching
Using maintenance mode to fix the Hypervisor connection state.
Restarting FMA services


Solution 1

This can be caused by changes made on the hypervisor to VM metadata. If the VM's unique ID has changed then the XenDesktop database may be unaware of this UID mismatch. This process will verify the UID known to XenDesktop for the VMs and compare against the UID provided by the hypervisor. 

Overview of Solution 1 steps diagram
User-added image

Warning! Back up the XenDesktop database before completing these actions.

  1. Open DDC using the PowerShell console and run the following commands to display all machine IDs of the virtual machines from the hypervisor. .

    asnp Citrix*
$ErrorActionPreference=Continue
Get-ChildItem -Path XdHyp:\ -force -recurse | ?{ $_.IsMachine } | Out-File –Filepath c:\xdhyp.txt

  2. The xdhyp.txt output file contains the correct machine IDs from the hypervisor. Open that file and press Ctrl+F or Edit > Find. Search for the name of the Virtual Machine, in this case, the name of the Virtual Machine is PVS0003.

    Example output

    PSPath : Citrix.Host.Admin.V1\Citrix.Hypervisor::XDHyp:\Connections\XenServer\PVS0003.vm
PSParentPath : Citrix.Host.Admin.V1\Citrix.Hypervisor::XDHyp:\Connections\XenServer
PSChildName : PVS0003.vm
PSDrive : XDHyp
PSProvider : Citrix.Host.Admin.V1\Citrix.Hypervisor
PSIsContainer : True
Name : PVS0003
FullName : PVS0003.vm
ObjectType : Vm
Id : 7d1d6004-5319-7a7e-59cb-2662e212a3e5
IsContainer : True
IsMachine : True
IsSnapshotable : True
ObjectPath : /PVS0003.vm
FullPath : XDHyp:\Connections\XenServer\PVS0003.vm
IsSymLink : False
AdditionalData : {}

    Note: The machine ID is as follows:
    Id : 7d1d6004-5319-7a7e-59cb-2662e212a3e5.
    Your result will vary.

  3. Run the following command:
    Get-BrokerMachine -PowerState Unknown
    This identifies the machines that have the unknown power state.

    + Note the “HostedMachineId “ from the output.
     
    + Now comparing the “ID” from Step1, and the “HostedMachineId “ from this step, You’ll find that the IDs are different.
     
    + Correct “Id” is from the Step-1  and incorrect value is present in Database (from step-3)
     
    + We can also verify the same by Browsing the below tables in SQL site database and confirming the values.
     
    Chb_Config.Workers >> HostedMachineId >>
     
    DesktopUpdateManagerSchema.ProvisionedVirtualMachine >> VMId >>
     

  4. Run the following command to change the XenDesktop Database's record for the machine ID to match the Hypervisor's Machine ID:

    Set-BrokerMachine -MachineName 'MyDomain\MyMachine' -HostedMachineId  [machine ID from preceding output]

    This corrects the HostedMachineId for the problem machines using the ID that was retrieved from xdhyp.txt.

  5. Check Desktop Studio or Desktop Director and refresh the list of results.
    The power state must now match the state indicated in the hypervisor.

Note: It might be necessary to restart the Citrix Broker Service on all DDCs and/or restart the virtual machine.

Solution 2

Overview of Solution 2 diagram
User-added image
Understanding of the Broker > Hypervisor communication:

  • The Broker service runs on every Delivery Controller in the site (DDC). It has many subcomponents, one of which is the Hosting Management sub-component.
  • The broker service must communicate to the Hypervisor using the VM/Machine ID
  • The UUID/Machine ID of the VM can be obtained by running “Get-BrokerMachine” cmdlet from any of the DDC’s in the site.
  •  It needs to match with the BIOS file of the VM on the hypervisor to be managed properly by DDC’s on the Site.
“Get-BrokerHypervisorConnection”
  • If the Certificate is updated on the VSphere server the same needs to be updated on all the DDC’s on the Site. Certificate mismatch can also cause the Broker to change the power states to “Unknown” and Hypervisor connection state to “Unavailable”.
  • If there is a Host/VSphere Server which is put under maintenance or is down for any reasons, the Broker will change the Power state to “Unknown” and Hypervisor connection state to “Unavailable”.
  • If there is an issue with broker service on one controller, broker service from another controller will serve as the Preferred controller to control the Power and pool for the site.
Steps to remediate the situation if the issue occurs:
  • If there is a network or VMware host issue which has corrected itself, the broker service won’t be able to re-establish the communication on its own if the disruption is for a longer period of time. In that case, the broker service needs to be restarted on all the DDC’s in the site.
  • Alternatively, you may run the command below cmdlet on any of DDC’s using Power Shell.
  • Update-HypHypervisorconnection – LiteralPath “The Actual Path of hypervisor Connection”
  • -LiteralPath of the Hypervisor connection can be obtained by running the below cmdlet on PowerShell of any DDC.
cd Xdhyp:
cd ./Connections
  • for instance: Update-HypHypervisorConnection -LiteralPath "XDHyp:\connections\Connection"
  • Alternatively, you may do the following using Studio to update the connection:

Click on Hosting tab on Studio -> Right click the connection -> Click on Edit Connection -> Without making any changes click on OK.
 

Solution 3

Remove the affected virtual machines from the Catalog & Delivery Group in Desktop Studio and add them again.

NOTE: Removing machines from an MCS catalog cannot be reversed. Once the VM is removed you will only be able to add that machine to a catalog of the "Manual" type. (This catalog type was called as "Existing" type in XenDesktop 5.x.  It is referred to as "Manual" in XenApp and XenDesktop 7.x.)

Solution 4

Ensure the SCVMM console version and hotfix level, installed on the DDCs, is the same version and hotfix level as the SCVMM server.

For example: Install the upgraded version of the SCVMM Console, version 8, KB3097539 on both controllers, which matched the SCVMM server hotfix level.

Solution 5

  1. Run "Get-BrokerHypervisorConnection", and check the output for Hypervisor state,
  2. If for any hypervisor connection the state is, anything else then ON or OFF,
  3. Then try to put that connection in maintenance mode for few secs and then turn off the maintenance mode again.

User-added image

 

Solution 6

  1. Restart the Citrix Site services on all the DDCs.

    Note: This may result in momentary disruptions of new connections, however current sessions are not affected.
 
  • Open PowerShell as admin and run the following commands:
    • Get-Service Citrix* | Stop-Service -Force
    • Get-Service Citrix* | Start-Service

Problem Cause

The DDC must communicate with the hypervisor using the virtual machine ID. If the DDC has an incorrect machine ID for the virtual machine, it is unable to read the machine power state and throws an exception in the broker log. If the power status is Unknown, the DDC will not be able to manage any power functions on the virtual machine.

Note: This condition can occur if the virtual machine has been forcibly moved between different hosts.

Other Possible Causes

  • The event id’s which will be registered on the DDC’s would give more information on the type of issue.
  • If there is a network disruption between the Broker and the Hypervisor for a brief period, brokers will change the power state of the VM’s to “Unknown” and the Hypervisor Connection state to “Unavailable”.

Issue/Introduction

Machines in the Desktop Studio or Desktop Director display a power state of Unknown.

Additional Information

Powered by Wolken Software