Citrix Virtual Apps and Desktops helps administrators manage virtual machines (VMs) on hypervisors securely and reliably and in a cost-efficient way. The power state of the VMs on Citrix Virtual Apps and Desktops represents the power state of the corresponding VMs on hypervisors such as VMware.

However, in some cases, admins see VMs on Citrix Virtual Apps and Desktops continuously showing a power state of “unknown.” Because of this, they can’t manage power actions for the VMs, like turning off VMs that aren’t in use. This can lead to wasted resources and affect reliability, especially when the VMs are deployed on cloud providers.

In this blog post, we’ll look at the reasons for the unknown power state, and I’ll introduce the Get-ProvVmInUnknownPowerState PowerShell command, which can help you to diagnose the VMs in an unknown power state, report the causes, and help fix the causes.

3 Reasons Why VMs Show an Unknown Power State

Let’s look at the three reasons why VMs on Citrix Virtual Apps and Desktops can continuously show an unknown power state.

Scenario 1: The ID of the VM on Citrix Virtual Apps and Desktops doesn’t match the corresponding ID of the VM on the hypervisor.

As shown below, the an unknown power state can occur when re-registering the VMs, such as when you’re using a different vCenter for the upgrade or migrating the VMs to a new vCenter. The IDs of the VMs on hypervisors change when you re-register, so the ID of the VM on Citrix Virtual Apps and Desktops doesn’t match the corresponding ID of the VM on the hypervisor. This can lead to the unknown power state of the VMs on Citrix Virtual Apps and Desktops.

An instance of the problem of mismatched IDs of the VMs (using UML notations).

Scenario 2: The VM on the hypervisor is deleted.

The figure below shows a scenario where an admin deletes a VM on a hypervisor. The VM on Citrix Virtual Apps and Desktops is supposed to represent the VM on the hypervisor. However, due to the deletion of the VM on the hypervisor, the power state of the VM on Citrix Virtual Apps and Desktops is unknown.

An instance of the problem of deleted VMs on hypervisors (using UML notations).

Scenario 3: The hypervisor connection on Citrix Virtual Apps and Desktops is broken.

As shown below, if the hypervisor connection is broken, the VM on Citrix Virtual Apps and Desktops cannot synchronize with the VM on the hypervisor, resulting in an unknown power state.

An instance of the problem of broken hypervisor connection (using UML notations).

In the past, we would assist by helping administrators manually change the IDs of the VM on Citrix Virtual Apps and Desktops stored on their database; change the IDs on the hypervisor (e.g. VMware); or delete and recreate the VMs. But that can be an inconvenient, error-prone process for admins, especially when a number of machines are in an unknown power state.

A Solution: Get-ProvVmInUnknownPowerState

The PowerShell command Get-ProvVmInUnknownPowerState can diagnose the VMs on Citrix Virtual Apps and Desktops that are an unknown power state, report the causes, and help to fix the causes. Get-ProvVmInUnknownPowerState uses the names of VMs on Citrix Virtual Apps and Desktops to find the corresponding VMs on hypervisors and check the three scenarios, covered above, that can make the power state of the VMs unknown.

The figure below shows the input, output, and a stakeholder of Get-ProvVmInUnknownPowerState. Get-ProvVmInUnknownPowerState can take a hypervisor connection name, a broker catalog name, and/or “-Fix” as input.

  • If either a hypervisor connection name or a broker catalog is given, Get-ProvVmInUnknownPowerState reports the VMs in an unknown power state associated with the hypervisor connection name or the broker catalog.
  • If both a hypervisor connection name and a broker catalog are given, Get-ProvVmInUnknownPowerState reports the VMs associated with the broker catalog, because the VMs on the catalog are a subset of the VMs on the hypervisor connection.
  • Without the “-Fix” parameter, the admin can get the report that includes the list of the VMs with the unknown power states together with the causes and suggestions.
  • With the parameter “-Fix”, the admin can get the report, and the script automatically resolves the issue in Scenario 1 by updating the IDs of VMs.
A high-level description of the input, output, and a stakeholder of the Get-ProvVmInUnknownPowerState (using IDEF0).

In the case of Scenario 1, Get-ProvVmInUnknownPowerState reports the causes and suggestions. If the “-Fix” parameter is specified, Get-ProvVmInUnknownPowerState fixes the causes of Scenario 1 automatically.

With Scenario 2 and Scenario 3, Get-ProvVmInUnknownPowerState reports the causes of the unknown power state and provides suggestions to help admins fix the issues such as correcting the credentials or deleting the VMs on Citrix Virtual Apps and Desktops.

Scenarios 1, 2, and 3 are exclusive. If the connection is unavailable and, as a result, it is not possible to access the hypervisor, check whether the corresponding VM on the hypervisor is deleted or the IDs are matched.

The Syntax of the Script.

Follow this syntax to execute the script:

Get-ProvVmInUnknownPowerState [[-HypervisorConnectionName] ] [[-BrokerCatalogName]] [-Fix]]

With this syntax, you can get a report for all VMs in an unknown power state, together with causes and suggestions:

Get-ProvVmInUnknownPowerState

By following this syntax, you can get a report for all VMs in an unknown power state, together with causes and suggestions and then automatically fix the mismatched VM IDs detailed in Scenario 1:

Get-ProvVmInUnknownPowerState -Fix

With this syntax, you can get a report only for VMs in an unknown power state that are associated with the hypervisor connection name “ExampleConnectionName,” together with causes and suggestions, and then automatically fix the mismatched VM IDs detailed in Scenario 1:

Get-ProvVmInUnknownPowerState -HypervisorConnectionName "ExampleConnectionName" -Fix

Please note, the script requires a minimum permission to execute Set-BrokerMachine.

Examples of the Script Execution

When parameters are not given, the script returns all VMs in an unknown power state as the figure below shows.

The VMs, named example0001 and example0002, are in an unknown power state due to the invalid credential for the hypervisor connection.

The VM, named example0003, is in an unknown power state because the IDs are mismatched with the VMs on the hypervisor.

An example of the script execution without parameters.

In the figure below, the broker catalog, named VMwareCatalog2, is given as an input. Get-ProvVmInUnknownPowerState returns the VM in an unknown power state associated with the catalog, together with the reason that the ID of the VM is not matched with the ID of the corresponding VM on the hypervisor.

An example of the script execution with a broker catalog name.

Here, a broker catalog name and the -Fix options are given. Because the ID is updated, you must restart the broker service.

An example of the script execution with a broker catalog name and -Fix.

After restarting the broker service, the Get-ProvVmInUnknownPowerState does not report VMs because the ID mismatch issue is resolved, as shown here:

An example of the script execution with a hypervisor connection name and -Fix.

Please note, this version of the script uses the name of VMs to find the correct ID of the VMs from the hypervisor. If the names are changed when re-registering, the script cannot find the correct IDs.

Get Started

In this blog post, we looked at three reasons why you might find VMs in an unknown power state, which can prevent admins from completing important tasks like turning off VMs that aren’t in use. The PowerShell script Get-ProvVmInUnknownPowerState can help you detect the VMs in an unknown power state and fix the issue so admins can more effectively manage their VMs. The script Get-ProvVmInUnknownPowerState is available now on the Citrix GitHub page.