Known issues for CU2

Advisories and known issues in CU2

This article details advisories and minor issues with this release and any workarounds that you can apply.

General

  • After migrating Container Managed VMs between pools, the Container Management functionality stops working for the VMs. This is because Container Management is implemented using a pool-specific key. To work around this issue, the VM-specific preparation step for “Container Management” needs to be repeated on the new pool. This means:
    • For CoreOS, the Cloud Config Drive needs to be updated by changing the Config Drive configuration in the VM preferences.
    • For RHEL/CentOS/OL 7 and Ubuntu, the xscontainer-prepare-vm needs to be re-run. Note that even if the preparation-step is repeated, the old XenServer pool might keep access to the VMs.
  • Renaming a container does not trigger the Container Managment view to update. Additionally on Ubuntu 14.04 the pause or unpause of a container from outside XenCenter does not trigger the view to update. This means that XenServer might not show the current (renamed/paused/unpaused) container-status. The underlying cause is that the view only gets refreshed following Docker event notifications. As a work around the refresh can be triggered manually by performing an action (i.e. start, stop) on an unrelated container that is running on the same VM. (EXT-118)

  • XenServer’s use of new hardware security features might reduce the overall performance of 32-bit PV VMs. Customers impacted by this issue can either:

    • Run a 64-bit version of the PV Linux VM, or
    • Boot Xen with the no-smep no-smap option. Note that we do not recommend this option as it can reduce the depth of security of the host. (CA-214564)
  • On some systems, the XenServer host fails to boot when 4096 MB or more memory is assigned to dom0. To work around this issue, edit the boot parameters on the host to include dma_bits=32 in the Xen command line

    1. Interrupt the Xen boot process to get to the boot options screen.
    2. Select to edit the configuration.
    3. Add dma_bits=32 to the Xen boot options.
    4. Continue the boot process.
    5. After the XenServer host successfully boots, run the following command to ensure that the boot parameter is always used:

      /opt/xensource/libexec/xen-cmdline --set-xen dma_bits=32
      

Conversion Manager

  • When you import a Windows VM from an ESXi server to XenServer, the IPv4/IPv6 network settings can be lost. To retain the network settings, customers should reconfigure the IPv4/IPv6 settings after completing the conversion. (CA-90730)

Dom0

  • In some cases, booting a XenServer host from FCoE SAN using software FCoE stack can cause the host to become unresponsive due to a temporary link disruption in the host initialization phase. If the host appears to be in an unresponsive state for a long time, reboot the host to work around this issue. (CA-233299)

  • Customers should not assign more than 32GB of memory to Dom0, as otherwise intermittent VM freezes might occur during start of VMs. (CA-236674)

  • Due to changes in the Dom0 file system, restore via XenCenter or “xe host-restore” might fail when users upgrade from XenServer 6.x to 7.x. This action is therefore not supported. (CA-302538)

Guests

  • The console screen on HVM Linux guests can go blank after a period (typically ten minutes) of inactivity. You can work around this issue by adding consoleblank=0 to the kernel boot parameters of the guest. Consult your guest OS documentation for information about updating the kernel boot parameters. (CA-148381)

  • Suspending or migrating a Linux VM with outstanding xenstore transactions can hang due to an issue in the VM’s Linux kernel. If your VM experiences this hang, force the VM to shut down and restart it. (CP-30551)

Networking

  • XenServer does not prevent users from unplugging a NIC used by the FCoE SR. (CA-178651)

Storage Manager

  • When starting VMs with at least one VBD, and either High Availability (HA) or redo log enabled, an extra number of login calls from SM to XAPI causes longer start time than expected. (CA-287884) (CA-287879)

Toolstack

  • If a pool’s CPU feature set changes while a VM is running (for example, when a new host is added to an existing pool, or when the VM is migrated to a host in another pool), the VM will continue to use the feature set which was applied when it was started. To update the VM to use the pool’s new feature set, the VM must be powered off and then started. Rebooting the VM, for example, by clicking ‘Reboot’ in XenCenter, does not cause the VM to update its feature set. (CA-188042)

  • In scenarios with poor or interrupted network connectivity between the XenServer host and the Licensing virtual machine, too many licenses might be checked out from the License Server. (CA-293005)

XenCenter

  • Modifying the font size or DPI on the computer on which XenCenter is running can result in the user interface displaying incorrectly. The default font size is 96 DPI; Windows 8 and Windows 10 refer to this as 100%. (CA-45514) (CAR-1940)

  • When XenCenter is installed on Windows Server 2008 SP2, it can fail to connect to a XenServer host with the message “Could not create SSL/TLS secure channel”. To resolve this issue, ensure that one of the following Windows Updates is installed on the Windows Server 2008 SP2 system: KB4056564 or KB4019276. For more information, see http://support.microsoft.com/kb/4019276. (CA-298456)

  • When applying automated updates on a XS 7.1 CU1, XenCenter will automatically install XS71ECU2 with all roll-up hotfixes applied. This will bring the hosts to the XenServer 7.1 CU2 but not XenCenter. To avoid this happening, users need to upgrade their XenCenter version to 7.1 CU2 before applying automated updates on a XenServer 7.1 CU1 host. (CA-304656)

Driver Disks

  • Driver disks built for XenServer 7.1 with the BASE_REQUIRES value in the makefile set to the default of product-version=7.1.0 do not install on XenServer 7.1 CU2. To ensure that your driver disks can be installed on XenServer 7.1 CU2 (CA-260318):

    • For updates that contain kernel device drivers, set BASE_REQUIRES := kernel-uname-r=4.4.0+10
    • For other updates, set BASE_REQUIRES := platform-version=2.2.0

Windows PV Tools

  • After upgrading a XenServer host from a previous version to XenServer 7.1 CU2, Windows VMs with XenServer Tools installed might incorrectly report as not having the XenServer Tools installed, or display some of the functionalities as unavailable. To work around this issue, install XenServer Tools issued with XenServer 7.1 CU2. (CA-209186)
Version

Known issues for CU2