VM's Power State Does Not Update And Shows As “Unknown” After vCenter Server Reboots

This is an issue with Citrix hypervisor communication library plugin since version Xenapp/XenDesktop version 7.16.

When vCenter server goes alive after reboot i.e “https://<vCenter FQDN>/sdk” becomes accessible, BrokerHostingPlugin still fails to login the vCenter server with exception “The session is not authenticated.”.

CDF Traces from Delivery Controller

,BrokerHostingPlugin,,0,,1,Information,”Attempting connection”,””

,BrokerHostingPlugin,,0,,1,Information,”***** Get Hypervisor Certificate for Connection to ‘https://<vCenter FQDN>/sdk​​​​​​​’ *****”,””

,BrokerHostingPlugin,,0,,1,Information,”Certificate is untrusted: False”,””

,BrokerHostingPlugin,,0,,1,Information,”Time elapsed to get the hypervisor certificate: xxms”,””

,BrokerHostingPlugin,,0,,1,Information,”***** Login Connection – 0 to ‘​​​​​​​https://<vCenter FQDN>/sdk’ as ‘#login_name#‘ *****”,””

,BrokerHostingPlugin,,0,,1,Information,”VMware plugin initialisation times: create service xms, content time xxxms, total xxxms”,””

,BrokerHostingPlugin,,0,,1,Information,”Connected to ‘VMware vCenter Server #vCenter version info#’“,””

,BrokerHostingPlugin,,0,,1,Error,”System.Web.Services.Protocols.SoapException: The session is not authenticated.

,BrokerHostingPlugin,,0,,1,Information,”Connection attempt threw exception System.Web.Services.Protocols.SoapException: The session is not authenticated.

,BrokerHostingPlugin,,0,,1,Information,”Connection is still down”,””

,BrokerHostingPlugin,,0,,1,Information,”Sleeping for 00:00:30 before trying to reconnect again”,””

Related:

  • No Related Posts

How to Create Machine Catalog using MCS in Azure Resource Manager

Pre-requisites

  • Access to the XenApp and XenDesktop Service of Citrix Cloud.
  • An Azure Subscription.
  • An Azure Active Directory (Azure AD) user account in the directory associated with your subscription, which is also co-administrator of the subscription.
  • An ARM virtual network and subnet in your preferred region with connectivity to an AD controller and Citrix Cloud Connector.
  • “Microsoft Azure” host connection
  • To create an MCS machine catalog, XenDesktop requires a master image that will be used as a template for all the machines in that catalog.

User-added image

Creating Master Image from Virtual Machine deployed in Azure Resource Manager

Create a virtual machine (VM) in Azure using the Azure Resource Manager gallery image with either the Server OS or Desktop OS (based on whether you want to create Server OS catalog or Desktop OS catalog).

Refer to Citrix Documentation – install Citrix VDA software on the VM for more information.

Install the applications on the VM that you want to publish using this master image. Shutdown the VM from Azure Portal once you have finished installing applications. Make sure that the power status for the VM in Azure Portal is Stopped (deallocated)

User-added image

When creating MCS catalog we need to use the .vhd file that represents OS disk associated with this VM as master image for the catalog. If you have the experience of using Microsoft Azure Classic connection type in XenDesktop, you would have captured specialized image of the VM at this stage, but for Microsoft Azure connection type you don’t have to capture the VM image, you will only shutdown the VM and use the VHD associated with the VM as master image.

Create MCS Catalog

This information is a supplement to the guidance in the Create a Machine Catalog article. After creating master image, you are all set to create MCS catalog. Please follow the steps as described below to create MCS catalog.

  1. Launch the Studio from your Citrix Cloud client portal and navigate to Machine Catalogs in the left hand pane.

  2. Right click Machine Catalogs and click on Create Machine Catalog to launch the machine creation wizard.

  3. Click Next on the Introduction page.

    User-added image

  4. On the Operating System page Select Server OS or Desktop OS based on what type of catalog you want to create and click Next.

    User-added image

  5. On the Machine Management page, select Citrix Machine Creation Service (MCS) as the deployment technology and select the Microsoft Azure hosting resource and click Next.

    User-added image

Master Image Selection – This page provides a tree view which you can navigate to select the master image VHD. At the topmost level are all the resource groups in your subscription except those which represent the MCS catalog created by XenDesktop. When you select and expand a particular resource group, it shows the list of all storage accounts for the Azure Umanaged Disks in that resource group. If there are no storage accounts in that resource group, there will not be any child items under that resource group. If you have manually created number of resource groups and storage accounts to host your manually created VMs in your subscription, the master image page will show all those resource groups, storage accounts, containers and VHDs even though not all those VHDs are master images that you want to use for the provisioning. Select the storage account that has your master image. When you expand the storage account, it shows list of containers inside the storage account. Expand the container that has master image VHD and select the VHD that you want to use as master image for the catalog.

User-added image

In the case of Azure Unmanaged Disk, you need to know the VHD path in order to select it. If you have stood up a VM in Azure and prepared it to be used as a master image and you want to know the VHD path, follow the steps below:

  1. Select the resource group that has your master image VM.

  2. Select the master image VM and click Settings

  3. Click on Disks then Click OS Disks and copy the disk path.

    User-added image
    User-added image

  4. OS disk path is structured as https://<storage account name>.blob.core.window.net/<container name>/<image name>.vhd

  5. You can use the disk path obtained in the step above to navigate the tree view to select image.

In the case of Azure Managed disk, it will be available directly under the Resource Group that you had created or as a part of the Virtual Machine’s Resource Group, as show below:

Note: If you don’t shutdown the master image VM and select the corresponding VHD to create a catalog, the catalog creation will fail. So make sure if you are selecting the VHD which is attached to running VM instance, the VM is in Stopped(deallocated) state.

  1. Storage type selection – XenDesktop supports Locally Redundant Standard or Premium storage for provisioning VMs in Azure. Your master image VHD can be hosted in any type of storage account, but for the VMs to be provisioned in Azure, XenDesktop will create new storage accounts based on storage type you selected.

    User-added image

  2. XenDesktop will provision maximum 40 VMs in single storage account due to IOPS limitations in Azure. For example if you want to create 100 VM catalog, you will find 3 storage accounts created and VM distribution in each storage account will be 40, 40 and 20.

  3. VM instance size selection – XenDesktop will show only those VM instance sizes which are supported for the selected storage type in the previous step. Enter number of VMs and select the VM instance size of your choice and click Next.

    User-added image

  4. Network Card Selection – Select network card and the associated network. Only one network card is supported.

    User-added image

  5. Select resource location domain and enter machine naming scheme.

    User-added image

  6. Enter credentials for your resource location Active Directory.

    User-added image

  7. Review the catalog summary, enter the catalog name and click Finish to start provisioning.

    User-added image

  8. Once the provisioning is complete, you will find new resource group created in your Azure subscription which hosts, all the VMs, storage accounts and network adapters for the catalog you provisioned. The default power state for the VMs after provisioning is Stopped(deallocated).

    User-added image

Once the provisioning is complete, you will find new resource group created in your subscription that has VM RDSDesk-01 as per the naming scheme we provided, NIC corresponding to that VM and a storage account that XenDesktop created to host the OS disk and the identity disk for the VM. The VM will be hosted on the same network as that of the selected hosting resource during catalog creation and the default power state of the VM will be Shutdown(deallocated).

The resource group created by XenDesktop during the MCS provisioning will have following naming convention

citrix-xd-<ProvisioningSchemeUid>-<xxxxx>

To find out which resource group in the Azure portal corresponds to the catalog you created from studio, follow the steps below.

  1. Connect to your XenApp and XenDesktop service using Remote PowerShell SDK. Please visit this link to find our how to interact with your Citrix Cloud environment using Remote PowerShell SDK.
  2. Run command Get-ProvScheme -ProvisioningSchemeName <Catalog Name>
  3. Note down the ‘ProvisioningSchemeUid’ from the output of the above command.
  4. Go to the Azure portal and search for the resource group name that contains ‘ProvisioningSchemeUid’ you obtained in step 3.
  • Note:

    As a best practice you should always create a copy of your master image and use the copied image as input to the provisioning process. In future if you want to update the catalog, you can start the master image VM and make necessary changes, shut it down and again create a copy of the image which will be your update image. This helps you to use the master image VM to create multiple image updates.

    Remember to shutdown the master image VM from Azure portal before starting to create the catalog. The master image needs to be copied into catalog’s storage account once provisioning starts, so we need to make sure it is not in use by any VM, otherwise it will lead to image copy failure and eventually provisioning failure.

  • Make sure you have sufficient cores, NIC quota in your subscription to provision VMs. You are most likely going to run out of these two quotas. You may not be able to check your subscription quota limits,
  • If your master image VM is provisioned in the Premium storage account then just shutting down the VM from the portal isn’t enough. You also need to detach the disk from the VM to use it as master image in provisioning. But in Azure Resource Manager you can not detach the disk while the VM is still available. So you need to delete the VM from the portal, this will only delete the VM but keep the OS disk in the storage account. The NIC corresponding to the VM also needs to be deleted separately.
User-added image

Related:

Citrix UPS Printers are not visible via Control Panel, Devices And Printers


This is an known issue with printers provided by Citrix Universal Printer server on windows operating systems Windows Server 2019, Windows Server 2016, Windows 10, Windows Server 2012r2, Windows Server 2012.

Citrix is working with Microsoft to correct this interaction between Microsoft operating systems and Citrix universal print server print provider.


Citrix Documentation:

This issue has been documented in our XenApp/XenDesktop documentation since 7.5

  • Universal Print Server printers selected in the virtual desktop do not appear in the Devices and Printers window in Windows Control Panel. However, when users are working in applications, they can print using those printers. This issue occurs only on Windows Server 2012, Windows 2012 R2 , Windows 10 and Windows 8 platforms. [#335153]

Microsoft Documentation:

The Device Setup Manager service is discussed in the following article from Microsoft it applies to both Windows 8 and Windows 2012.

Device setup user experience in Windows 8

Microsoft released a hotfix for server 2012r2 which partially addressed some issues with 3rd party print provider visibility in newer windows releases.

However this was not a complete solution, and printers provided by Citrix Universal Print Server remained not visible.​

https://support.microsoft.com/en-us/help/2966038/printer-managed-by-custom-print-providers-is-not-visible-in-devices-an

Related:

  • No Related Posts

Supported Databases for XenApp and XenDesktop Components

Citrix is committed to ensuring that our products function with the latest Microsoft SQL databases. Citrix supplies best efforts to ensure compatibility with upcoming database releases. New versions of supported databases released after our products have been released, must work. However, Citrix recommends creating a test environment to ensure there are no unforeseen issues related to changes made to the new version or update of the third-party product. Individuals wishing to use the new release with current Citrix products must perform their own testing before using the platform. Citrix does not support any BETA versions of third-party products.

This document will be updated periodically as new information becomes available.

What has changed from the last release of the matrix

  • Updated support for Virtual Apps and Desktops (XenApp/XenDesktop) 7 1906
Supported Databases Virtual Apps and Desktops (XenApp/XenDesktop) 7.15LTSR / 1811 / 1903 / 1906 XenApp/XenDesktop 7.6 LTSR Provisioning Services 7.15 LTSR / 1811 / 1903 / 1906 Provisioning Services 7.6 LTSR XenApp 6.5 HRP07
SQL 2017
x64 Yes Yes Yes (1) Yes (1) Yes
Express Yes Yes Yes (1) Yes (1) Yes
SQL 2016 SP1, SP2
x64 Yes Yes Yes (1) Yes (1) Yes
Express Yes Yes Yes (1) Yes (1) Yes
SQL 2014 SP1, SP2, SP3
x86 Yes Yes Yes (1) Yes (1) Yes
x64 Yes Yes Yes (1) Yes (1) Yes
Express Yes Yes Yes Yes Yes
SQL 2012 SP1, SP2, SP3, SP4
x86 Yes Yes Yes (1) Yes (1) Yes
x64 Yes Yes Yes (1) Yes (1) Yes
Express Yes Yes Yes Yes Yes
SQL 2012
x86 Yes Yes Yes (1) Yes (1) Yes
x64 Yes Yes Yes (1) Yes (1) Yes
Express Yes (2) Yes (2) Yes Yes Yes
SQL 2008 R2 SP2, SP3
x86 Yes Yes Yes Yes Yes
x64 Yes Yes Yes Yes Yes
Express Yes Yes Yes Yes Yes

  1. PVS 7.7 onwards Always ON is supported. PVS 7.11 introduced Multi-subnet Failover
  2. Known issue using SQL 2012 and above with XenDesktop, Refer to article ‘CTX132438 – Unable to Create New XenDesktop Site Using SQL 2012 Server’

Note:

  • The x86 and x64 versions of SQL (version 2012 and later) have been validated with Always On, Clustered, Standalone and Mirrored modes.
  • The Express edition has been validated only as Standalone.

Related:

Citrix Webcam not supported in x64 application like Google Chrome or Microsoft Teams

Webcam redirection is not supported in 64-bit applications with XenApp / XenDesktop 7.16 or older. This was fixed on 7.17 and Receiver 4.11 for Windows.

Also, note downloading Google Chrome and installing – you may note that the application appears in the folder:

C:Program Files (x86)GoogleChromeApplication

User-added image
Which would normally indicate that application is 32bit; however, checking Task manager displays as 64bit application:

User-added image
Capturing a CDF trace and observe that similar information is logged on the VDA CDF trace when a 64-bit application attempts to use a webcam (aka Media capture)…

112496 0 2017/04/09 09:44:12:15668 3036 4020 -1 HostMMTransport IcaMMTransport::Connect 9 Error [Id=1] IcaMMTransport::Connect: Media capture is not supported for 64-bit applications.

Install *Google Chrome for business* available now as Chrome MSI 32-bit to resolve the issue.

Related:

  • No Related Posts

WITHDRAWN: Hotfix XS70E067 – For XenServer 7.0

This hotfix introduces an issue that prevents newer versions of XenCenter from connecting to XenServer hosts that have XS70E067 applied. As a result, the hotfix was withdrawn on Jun 7, 2019.

Important: If you have already downloaded XS70E067, do not install it on your XenServer 7.0 hosts.

If you have already installed XS70E067, you will experience the following issues:

  • XenCenter 7.1 and later does not connect to XenServer 7.0 hosts that have XS70E067 applied and reports the following error: “This pool contains servers earlier than Citrix Hypervisor 7.0. Please use an earlier version of XenCenter to manage this pool.” To work around this issue, use XenCenter 7.0.1 to connect to these hosts.
  • XenServer 7.0 hosts with XS70E067 applied cannot be upgraded to XenServer 7.1. Do not attempt to upgrade these hosts to a later version of XenServer.

Citrix is working on a hotfix to supersede XS70E067 that will include a fix for the issues introduced by XS70E067.

Related:

  • No Related Posts

Citrix MSI Log Analyzer

Description

The Citrix MSI Log Analyzer is designed to assist with the following scenarios:

  • When failure occurred during install or upgrade or uninstall of XenApp/XenDesktop
  • The Citrix MSI Log Analyzer analyzes the failure and provides helpful info for troubleshooting the issue
  • The Citrix MSI Log Analyzer will also try to point to a knowledge base article helpful to troubleshoot and resolve the issue

What’s New in v1.2.0.9

  • Added support for Storefront logs
  • Added support for uploading experience metrics through TLS 1.2/TLS 1.1.
  • Minor bug fixes and inputs from the feedback

Prerequisites

The user needs to be a Local Administrator on the target machine in order to run the tool.

How to use Citrix MSI Log Analyzer

The Citrix MSI Log Analyzer is a standalone executable file and does not require installation. Just download the tool to a local folder and execute the application.

Citrix MSI Log Analyzer offers various command line to deal with different use cases.

  1. To analyze the failure in the msi log file:

    CitrixMSILogAnalyzer.exe -msilogfile <msi log file path>



    Look for MSI log file under %TEMP%CitrixXenDesktop InstallerMSI Log files” folder and specify the absolute path of the failing msi log file in the above command line.

  2. To analyze the failure from the XenApp/XenDesktop Metainstaller log file::

    CitrixMSILogAnalyzer.exe -metainstallerlogfolder <metainstaller log folder path>

    Example: CitrixMSILogAnalyzer.exe -metainstallerlogfolder “C:UsersxxxxAppDataLocalTempCitrixXenDesktop Installer” where xxxx is the admin user name specific to the user environment

  3. To analyze Citrix XenApp/XenDesktop failure log file under temp folder

    CitrixMSILogAnalyzer.exe

    This option is useful to run the tool on the target machine where the MSI installation failure happened and one is not sure on where to look for msi failure log file.

  4. To view help:

    CitrixMSILogAnalyzer.exe -help

Note: In order to improve Citrix XenApp/XenDesktop and Citrix MSI Log Analyzer, the troubleshooting data not containing any identifiable information from the tool is uploaded to Citrix. This can be controlled using –upload [Yes | No]

Output from the tool

The output of the tool on the console provides:

1. Troubleshooting info of the actual error

2. CTX article to troubleshoot or resolve the issue

3. Log file saved under %TEMP% with prefix mLog_*.txt. The exact name and path is displayed in the output.

Delete Citrix MSI Log Analyzer

Delete the downloaded executable from the current directory. One may also cleanup mLog_*.txt files under %TEMP% directory

Contact Information:

Questions? Concerns? Send any feedback to:

https://podio.com/webforms/18778954/1263577

Disclaimer

These software applications are provided to you as is with no representations, warranties or conditions of any kind. You may use 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 software application 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 software application 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 software application. In no event should the code be used to support of 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 SOFTWARE APPLICATION, INCLUDING WITHOUT LIMITATION DIRECT, SPECIAL, INCIDENTAL, PUNITIVE, CONSEQUENTIAL OR OTHER DAMAGES, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. You agree to indemnify and defend Citrix against any and all claims arising from your use, modification or distribution of the code.

Related:

How to Configure Multiple License Types within a Single XenApp and XenDesktop Site

NOTE:

  • This feature does not allow you to use a mix of licenses for different Product Editions. For example, you can’t combine XenApp Platinum and XenApp Advanced licenses in the same site. You’d still need two sites for that.
  • Choice of Product Code and Edition combination can depend on the features you want to enable for your deployment’s sessions. There are some differences between XenApp and XenDesktop enabled features for the same Product Edition.
  • Changes to the Site licensing type could invalidate your custom licensing Delivery Group due to XenApp User/Device not being an accepted combination

Reference:

https://www.citrix.com/blogs/2017/07/07/introducing-multi-type-licensing-in-xenapp-xendesktop-7-14/

https://docs.citrix.com/en-us/xenapp-and-xendesktop/7-15-ltsr/manage-deployment/licensing/multi-type-licensing.html

https://www.citrix.com/products/citrix-virtual-apps-and-desktops/feature-matrix.html%20to

Related:

  • No Related Posts

Recommended Hotfixes for XenServer 7.x

Citrix Hypervisor, formerly XenServer, is powered by the Xen Project hypervisor.

This article contains the complete set of recommended updates/hotfixes for XenServer 7.x .

For List of XenServer Tools/Management Agent/Windows Driver Updates refer toCTX235403-Updates to Management Agent – For XenServer 7.0 and later​

For XenServer 6.x hotfixes, refer to CTX138115 – Recommended Hotfixes for XenServer 6.x

XenServer 7.6 XenServer 7.5 XenServer 7.1 CU2 XenServer 7.0

For more information, refer to the following Knowledge Center articles

Note: Citrix recommends updating the XenServer Console before updating any new hotfixes. All XenServer hotfixes can be applied at the same time and the hotfixes in the article are not relevant to the installation order

Hotfix XS76E003 –

For XenServer 7.6
All customers who are affected by the issues described in CTX246572 – Citrix XenServer Multiple Security Updates should install this hotfix.

This hotfix also includes the following previously released hotfixes:

Content live patchable** No
Hotfix XS75E003 –

For XenServer 7.5
All customers who are affected by the issues described in CTX236548 – Citrix XenServer Multiple Security Updates should install this hotfix.

Content live patchable** No
Hotfix XS75E005 –

For XenServer 7.5
All customers who are affected by the issues described in CTX236548 – Citrix XenServer Multiple Security Updates should install this hotfix.

Content live patchable** No
Hotfix XS75E008 –

For XenServer 7.5
All customers who are affected by the issues described in CTX246572 – Citrix XenServer Multiple Security Updates should install this hotfix.

This hotfix also includes the following previously released hotfixes:

Content live patchable** No

XenServer 7.1 Cumulative Update 2 (XS71ECU2) must be installed by all customers running XenServer 7.1 CU1 as , since March 12 2019 no further hotfixes will be produced for XenServer 7.1 CU1.

XenServer 7.1 Cumulative Update 2 and its subsequent hotfixes are available only to customers on the Customer Success Services program.

For more information about XenServer 7.1 CU2, see the Citrix XenServer 7.1 Cumulative Update 2 Release Notes.

XenCenter 7.1.3

This release of XenCenter is for customers who use XenCenter as the management console for XenServer 7.1 LTSR. XenCenter 7.1 CU2 is released as part of XenServer 7.1 Cumulative Update 2 and is available only to customers on the Customer Success Services program.

We recommend that you install this version of XenCenter before using XenCenter to update XenServer 7.1 CU1 hosts to XenServer 7.1 CU2.

XS71ECU2

XenServer 7.1 Cumulative Update 2 (XS71ECU2) must be installed by customers running XenServer 7.1 LTSR CU1. It includes all previously released XenServer 7.1 CU1 hotfixes. Installation of XS71ECU2 is required for all future functional hotfixes for XenServer 7.1 LTSR.

XenServer 7.1 Cumulative Update 2 and its subsequent hotfixes are available only to customers on the Customer Success Services program.

Citrix will continue to provide security updates to the base XenServer 7.1 CU1 product for a period of three months from the release date of the XenServer 7.1 Cumulative Update 2 (until March 12, 2019). After this three month period elapses, any new hotfixes released will only support XenServer 7.1 with CU2 applied.

For more information about XenServer 7.1 CU2, see the Citrix XenServer 7.1 Cumulative Update 2 Release Notes.

Content live patchable** No
Hotfix XS71ECU2001 – For XenServer 7.1 Cumulative Update 2

This hotfix resolves the following issue:

  • The XenServer host can experience a memory leak in dom0. This memory leak is triggered by invalid responses to FLOGI messages from connected FCoE equipment.
Content live patchable** Yes
Hotfix XS71ECU2003 – For XenServer 7.1 Cumulative Update 2

This hotfix resolves the following issues:

  • Depending on the guest OS and device, devices passed through to a guest might not function correctly due to missed interrupts.
Content live patchable** No
Hotfix XS71ECU2004 – For XenServer 7.1 Cumulative Update 2

This hotfix resolves the following issues:

  • If you attempt to reboot a Windows VM from XenServer at the same time as you attempt to reboot the Windows VM from within the VM, the reboot can fail with the following error: “You attempted an operation on a VM that needed to be in state ‘Running but was in state ‘Halted’.
  • Scheduled metadata backups can fail intermittently when the pool backup metadata VDI gets full. The default size of the pool backup metadata VDI has been increased to 500MiB.
  • A VM taking more than 30 seconds to shut down no longer leads to “Domain stuck in dying state after 30s.”
  • While applying a hotfix to a pool, if XAPI restarts on a pool member, it detaches the hotfix update from all hosts in the pool as part of clean-up operations. This can cause the hotfix to fail to apply to other pool members.
Content live patchable** No
Hotfix XS71ECU2007 – For XenServer 7.1 Cumulative Update 2

This hotfix resolves the following issues:

  • Improvements to VM performance and stability.
  • A race condition in XenBus can cause pauses in Windows VM operation, which lead to Timeout Detection and Recovery (TDR) events. The TDR can cause the VM to crash.
  • Under low resource situations, Xennet can consume all of the RAM on a Windows VM. This causes the VM to crash.
  • Windows VMs with the XenVBD driver installed can experience a high number of system interrupts when performing storage operations, especially if you are using fast storage and transferring large amounts of data.

This hotfix also includes the drivers required to support Windows Server 2019 VMs on XenServer 7.1 CU2.

Content live patchable** No
Hotfix XS71ECU2008 – For XenServer 7.1 Cumulative Update 2 All customers who are affected by the issues described in CTX251995 – Citrix XenServer Multiple Security Updates should install this hotfix.

This hotfix also includes the following previously released hotfixes:

Content live patchable** No

Apply the following hotfixes for XenServer 7.0 and restart XenServer when the hotfix installation is complete.

Hotfix XS70E001 –

For XenServer 7.0
This is a XenCenter update (a .exe file) and not a host side Hotfix. This package needs to be installed

on the Windows Machine Running XenCenter
Hotfix XS70E002 – For XenServer 7.0 All customers who are affected by the CVE-2016-2107 issue described in

CTX212736: Citrix XenServer Multiple Security Updates should install this hotfix.
Hotfix XS70E004 – For XenServer 7.0 Important: This is a critical hotfix for customers running XenServer 7.0. All XenServer 7.0

customers must apply this hotfix.
Hotfix XS70E009 – For XenServer 7.0

This hotfix resolves the following issue:

  • In rare circumstances when a XenServer host is enabling HA, or during a host reboot with HA enabled, the host can fail to establish HA communication with the other hosts. This is due to another process on the host using the listening port required by the HA software.
Update XS70EU001 – Management Agent for XenServer 7.0 The Management Agent update resolves the following issues:

  • Installation of Management Agent can fail after installing newer I/O drivers through Windows Update.
  • Failure to reboot a Windows VM after installing XenServer Tools can result in excessive log entries being written to xensource.log and xenstored-access.log until the VM is rebooted. If customers do not reboot the VM, or delay the reboot, excess logs can fill up the XenServer host log partition.
  • The Management Agent can crash and respawn on systems without a terminal services Windows Management Instrumentation (WMI) object causing high CPU usage and excessive logging in /var/log/daemon.
  • If the Management Agent auto update is enabled after installing XenServer Tools, and a new update is available, the initial auto-update can fail due to a race condition that can cause multiple update attempts to occur simultaneously.
Update XS70EU002 – Management Agent for XenServer 7.0 New versions of the I/O drivers, compatible with Microsoft Windows Server 2016 have been released.
Update XS70EU003 – Management Agent for XenServer 7.0
  • The default behavior of the Management Agent has been improved to enable customers to configure whether any I/O driver updates included in the Management Agent should be applied automatically. For more information, see section 4.3.1 Installing XenServer Tools in the XenServer 7.0 Virtual Machine User’s Guide.
  • This version (v7.1.844) of the Management Agent includes new versions of the I/O drivers that are compatible with Microsoft Windows Server 2016. These drivers have been released previously through the Microsoft Windows Server Update Service. For more information, see Update XS70EU002 – Windows I/O Drivers for XenServer 7.0.
Hotfix XS70E018 – For XenServer 7.0 This is a hotfix for customers running XenServer 7.0. All customers who are affected by the issues described in CTX220112: Citrix XenServer Multiple Security Updates should install this hotfix.
  • This is a hotfix for customers running XenServer 7.0. All customers who are affected by the issues described in CTX219378: Citrix XenServer Multiple Security Updates should install this hotfix.
  • This hotfix supports the improvements to XenServer’s Direct Inspect APIs.
Hotfix XS70E024 – For XenServer 7.0
  • When booting a vGPU provisioned Virtual Machine (VM) from network, an interaction between VGA BIOS and VGA emulation code in the vGPU device model can result in the corruption of the VM console in XenCenter.
Hotfix XS70E027 – For XenServer 7.0
  • When Installing XenServer or upgrading XenServer to a newer version, PBIS services get enabled (even when Role-based access control (RBAC) is not used) and display a lot of error messages. Also, this issue consumes a lot of control domain (dom0) resources.
Hotfix XS70E028 – For XenServer 7.0 This hotfix supports the following new guest operating systems.

  • Oracle Linux 6.8
  • Red Hat Enterprise Linux 6.8
  • CentOS 6.8
  • NeoKylin Linux Advanced Server 6.5 ( only 64 bit )
  • NeoKylin Linux Advanced Server 7.2 ( Only 64 bit )
  • SUSE Linux Enterprise Server 11 SP4
Hotfix XS70E037 – For XenServer 7.0

This hotfix addresses the following issue:

  • When attempting to use XenServer Conversion Manager (XCM) Console to connect to an XCM Virtual Appliance that runs on a slave host, the connection fails and the following message is displayed by the console: “There was a failure communicating with the plugin.” This hotfix ensures that the XCM Console can connect to a XCM Virtual Appliance that runs on any XenServer host.
Hotfix XS70E041 – For XenServer 7.0

This hotfix resolves the following issue:

  • When using SSH to connect to XenServer, a user might experience a memory leak in systemd on XenServer.
Hotfix XS70E048 – For XenServer 7.0 This is a hotfix for customers running XenServer 7.0. All customers who are affected by the issues described in CTX230138 – Citrix XenServer Multiple Security Updates should install this hotfix.

This hotfix also includes the following previously released hotfixes:

Hotfix XS70E052 – For XenServer 7.0 This is a hotfix for customers running XenServer 7.0. All customers who are affected by the issues described in CTX232655 – Citrix XenServer Multiple Security Updates should install this hotfix.This security hotfix addresses the vulnerabilities as described in the Security Bulletin above.
Hotfix XS70E061 – For XenServer 7.0

This is a hotfix for customers running XenServer 7.0.

All customers who are affected by the issues described in CTX236548 – Citrix XenServer Multiple Security Updates should install this hotfix.

Hotfix XS70E062 – For XenServer 7.0

This hotfix resolves the following issues:

  • Virtual machines (VMs) configured with in-guest software RAID may fail to cleanly shut down or restart.
  • After taking a disk-only snapshot for a VM running in the pool, users randomly fail to access the Virtual Hard Disk (VHD) when trying to unpause the VM, and the VM stops responding. This is caused by time racing in Linux Logical Volume Manager (LVM).
  • After rebooting, a XenServer host can fail to connect to iSCSI targets on Compellent arrays.
  • When Intellicache mirroring fails due to ENOSPC on shared storage, the VBD image list gets truncated to point to itself. This causes an infinite loop and can lead to the I/O datapath stopping and subsequently VMs freezing.
  • When a pool master node executes multi-step plugins on the pool member nodes after important events such as coalesce, the plugin continues to execute through all its steps even if one of the previous ones have failed. This can lead to complications such that the other VDI operations are permanently blocked with OTHER_OPERATION_IN_PROGRESS.
  • After deleting a snapshot on a pool member that is not the pool master, a coalesce operation may not succeed. In such cases, the coalesce process can constantly retry to complete the operation, resulting in the creation of multiple RefCounts that can consume a lot of space on the pool member.
  • The storage cleanup process initiated after a VDI destroy can conflict with ongoing VDI copy processes (including Storage XenMotion), causing subsequent operations on the SR to fail.

This hotfix also includes the following previously released hotfixes:

Hotfix XS70E063 – For XenServer 7.0

This hotfix resolves the following issues:

  • High Availability (HA) enabled VMs can take longer to restart after a HA failover.
  • In rare cases, when a XenServer host in a pool is restarted, it may not be able to rejoin the pool.
  • In rare cases, attempts to shut down a XenServer host in a pool may not succeed.
  • On HA-enabled pools, when a task is initiated after a XenServer host has failed, VMs running on the host can take longer (about 10 minutes) to restart. This issue occurs when a task is assigned to the host after it has failed, but before XAPI is aware of the host failure. In such cases, the task doesn’t get cancelled even when XAPI is notified about the failure, causing delays in restarting the VMs.
  • When migrating VMs that have Dynamic Memory Control (DMC) enabled, the VMs shutdown operation can unexpectedly fail. This is caused by reducing memory allocation before shutdown and this operation taking longer than expected.
  • On Nutanix hosts, the host’s memory-overhead is miscalculated after first boot. This is because XAPI calculates the available host RAM on startup assuming no domains other than the XenServer Control Domain are running. On first boot this is true but on subsequent boots, the Nutanix Controller VM (CVM) is started before XAPI.

This hotfix also includes the following previously released hotfixes:

Hotfix XS70E065 – For XenServer 7.0

This hotfix resolves the following issues:

  • A race condition caused Windows VMs to hang repeatedly and give an error with Event ID 129: “StorPort detected a SRB timeout, and issued a reset”.
  • XenVBD can consume 100% of a vCPU and can block other processes from using that vCPU.
  • If a restart is performed without clicking on the Yes or No buttons of the restart to complete installation dialog box, the dialog box continues to appear even after restarting the VM.

This hotfix also includes the following previously released hotfixes:

Hotfix XS70E066 – For XenServer 7.0 All customers who are affected by the issues described in CTX246572 – Citrix XenServer Multiple Security Updates should install this hotfix.

This security hotfix addresses the vulnerabilities as described in the Security Bulletin above.

This hotfix also includes the following previously released hotfixes:

Related:

  • No Related Posts