Advanced notes for virtual machines

This section provides some advanced notes for Virtual Machines.

VM boot behavior

There are two options for the behavior of a Virtual Machine’s VDI when the VM is booted:

Note:

The VM must be shut down before you can change its boot behavior setting.

Persist (Citrix Virtual Desktops - Private Desktop Mode)

This behavior is the default on VM boot. The VDI is left in the state it was at the last shutdown.

Select this option if you plan to allow users to make permanent changes to their desktops. To select persist, shut down the VM, and then enter the following command:

xe vdi-param-set uuid=vdi_uuid on-boot=persist

Reset (Citrix Virtual Desktops - Shared Desktop Mode)

On VM boot, the VDI is reverted to the state it was in at the previous boot. Any changes made while the VM is running are lost when the VM is next booted.

Select this option if you plan to deliver standardized desktops that users cannot permanently change. To select reset, shut down the VM, and then enter the following command:

xe vdi-param-set uuid=vdi_uuid on-boot=reset

Warning:

After you change on-boot=reset, any data saved to the VDI is discarded after the next shutdown/start or reboot.

Make the ISO library available to XenServer hosts

To make an ISO library available to XenServer hosts, create an external NFS or SMB/CIFS share directory. The NFS or SMB/CIFS server must allow root access to the share. For NFS shares, allow access by setting the no_root_squash flag when you create the share entry in /etc/exports on the NFS server.

Then either use XenCenter to attach the ISO library, or connect to the host console and run the command:

xe-mount-iso-sr host:/volume

For advanced use, you can pass extra arguments to the mount command.

To make a Windows SMB/CIFS share available to the host, either use XenCenter, or connect to the host console and run the following command:

xe-mount-iso-sr unc_path -t cifs -o username=myname/myworkgroup

Replace back slashes in the unc_path argument with forward-slashes. For example:

xe-mount-iso-sr //server1/myisos -t cifs -o username=johndoe/mydomain

After mounting the share, any available ISOs are available from the Install from ISO Library or DVD drive list in XenCenter. These ISOs are also available as CD images from the CLI commands.

Attach the ISO to an appropriate Windows template.

Windows Volume Shadow Copy Service (VSS) provider

The Windows tools also include a VSS provider for XenServer that is used to quiesce the guest filesystem in preparation for a VM snapshot. The VSS provider is installed as part of the PV driver installation, but is not enabled by default.

To enable the Windows XenServer VSS provider:

  1. Install the Windows PV drivers.

  2. Navigate to the directory where the drivers are installed (by default c:\Program Files\Citrix\XenTools, or the value of HKEY_LOCAL_MACHINE\Software\Citrix\XenTools\Install_dir in the Windows Registry).

  3. Double-click the install-XenProvider.cmd command to activate the VSS provider.

Notes:

  • The VSS provider is automatically uninstalled when the PV drivers are uninstalled. Enable the VSS provider again when it is installed again. They can be uninstalled separately from the PV drivers by using uninstall-XenProvider.cmd in the same directory.
  • Using VSS snapshots on GFS2 SRs is not supported.

Connect to a Windows VM by using Remote Desktop

You can use one of the following ways of viewing a Windows VM console, both of which support full use of the keyboard and mouse.

  • Using XenCenter. This method provides a standard graphical console and uses the VNC technology built in to XenServer to provide remote access to your virtual machine console.

  • Connecting using Windows Remote Desktop. This method uses the Remote Desktop Protocol technology

In XenCenter on the Console tab, there is a Switch to Remote Desktop button. This button disables the standard graphical console within XenCenter, and switches to using Remote Desktop.

If you do not have Remote Desktop enabled in the VM, this button is disabled. To enable it, install the XenServer Tools. Follow the procedure below to enable it in each VM that you want to connect using Remote Desktop.

To enable Remote Desktop on a Windows VM:

  1. Open System by clicking the Start button, right-click on Computer, and then select Properties.

  2. Click Remote settings. If you’re prompted for an administrator password, type the password you created during the VM setup.

  3. In the Remote Desktop area, click the check box labeled Allow connections from computers running any version of Remote Desktop (Windows 7).

  4. To select any non-administrator users that can connect to this Windows VM, click the Select Remote Users button and provide the user names. Users with Administrator privileges on the Windows domain can connect by default.

You can now connect to this VM using Remote Desktop. For more information, see the Microsoft Knowledge Base article, Connect to another computer using Remote Desktop Connection.

Note:

You cannot connect to a VM that is asleep or hibernating. Set the settings for sleep and hibernation on the remote computer to Never.

Time handling in Windows VMs

For Windows guests, initially the control domain clock drives the time. The time updates during VM lifecycle operations such as suspend and reboot. Citrix recommends running a reliable NTP service in the control domain and all Windows VMs.

If you manually set a VM to be two hours ahead of the control domain, then it persists. You might set the VM ahead by using a time-zone offset within the VM. If you later change the control domain time (either manually or by NTP), the VM shifts accordingly but maintains the two hours offset. Changing the control domain time-zone does not affect VM time-zones or offset. XenServer uses the hardware clock setting of the VM to synchronize the VM. XenServer does not use the system clock setting of the VM.

When performing suspend and resume operations or using XenMotion, ensure that you have up-to-date XenServer Tools installed. XenServer Tools notify the Windows kernel that a time synchronization is required after resuming (potentially on a different physical host).

Note: If you are running Windows VMs in Citrix Virtual Desktops environment, you must ensure that the host clock has the same source as the Active Directory (AD) domain. Failure to synchronize the clocks can cause the VMs to display an incorrect time and cause the Windows PV drivers to crash.

Time handling in Linux VMs

The time handling behavior of Linux VMs in XenServer depends on whether the VM is a PV guest or an HVM guest.

In addition to the behavior defined by XenServer, operating system settings and behaviors can affect the time handling behavior of your Linux VMs. Some Linux operating systems might periodically synchronize their system clock and hardware clock, or the operating system might use its own NTP service by default. For more information, see the documentation for the operating system of your Linux VM.

Note:

When installing a new Linux VM, ensure that you change the time-zone from the default UTC to your local value. For specific distribution instructions, see Linux Release Notes.

Time handling in PV Linux VMs

There are two wall-clock behaviors for paravirtualized Linux distributions – dependent and independent.

Dependent wall-clock: The system clocks in PV Linux VMs are synchronized to the clock running on the control domain, and cannot be independently altered. This mode is convenient, as only the control domain has to run the Network Time Protocol (NTP) service to keep accurate time across all VMs.

Independent wall-clock: System clocks in PV Linux VMs are not synchronized to the clock running on the control domain and can be altered. When the VM starts, the control domain time is used to set the initial time of the system clock.

Some PV Linux VMs can use the independent_wallclock setting to change the wall-clock behavior of the VM.

The following table lists wallclock behavior for PV Linux VMs:

Guest OS Default wall-clock behavior Is independent_wallclock setting available?
CentOS 5.x (32-/64-bit) Dependent Yes
CentOS 6.x (32-/64-bit) Independent  
Red Hat Enterprise Linux 5.x (32-/64-bit) Dependent Yes
Red Hat Enterprise Linux 6.x (32-/64-bit) Independent  
Oracle Linux 5.x (32-/64-bit) Dependent Yes
Oracle Linux 6.x (32-/64-bit) Independent  
Scientific Linux 6.x (32-/64-bit) Independent  
SLES 11 SP3, SP4 (32-/64-bit) Independent Yes (No-op)
SLES 12 SP1, SP2 (64-bit) Independent Yes (No-op)
SLED 11 SP3, SP4 (64-bit) Independent Yes (No-op)
SLED 12 SP1, SP2 (64-bit) Independent Yes (No-op)
Debian 6 (32-/64-bit) Independent  
Debian 7 (32-/64-bit) Independent  
Ubuntu 12.04 (32-/64-bit) Independent  
NeoKylin Linux Advanced Server 6.5 (64-bit) Independent  
Asianux Server 4.2 (64-bit) Dependent Yes
Asianux Server 4.4 (64-bit) Dependent Yes
Asianux Server 4.5 (64-bit) Dependent Yes
GreatTurbo Enterprise Server 12.2 (64-bit) Dependent Yes
NeoKylin Linux Security OS V5.0 (64-bit) Dependent Yes

For PV Linux VMs where the independent_wallclock setting is available, you can use this setting to define whether the VM has dependent or independent wallclock behavior.

Important:

Citrix recommends using the independent_wallclock setting to enable independent wall-clock behavior and running a reliable NTP service on the Linux VMs and the XenServer host.

To set individual Linux VMs to have independent wall-clock behavior:

  1. From a root prompt on the VM, run the command: echo 1 > /proc/sys/xen/independent_wallclock

  2. This setting can be persisted across reboots by changing the /etc/sysctl.conf configuration file and adding:

    ## Set independent wall clock time
    xen.independent_wallclock=1
    
  3. As a third alternative, independent_wallclock=1 can also be passed as a boot parameter to the VM.

To set individual Linux VMs to have dependent wall-clock behavior:

  1. From a root prompt on the VM, run the command: echo 0 > /proc/sys/xen/independent_wallclock

  2. This setting can be persisted across reboots by changing the /etc/sysctl.conf configuration file and adding:

    ## Set independent wall clock time
    xen.independent_wallclock=0
    
  3. As a third alternative, independent_wallclock=0 can also be passed as a boot parameter to the VM.

HVM Linux VMs

Hardware clocks in HVM Linux VMs are not synchronized to the clock running on the control domain and can be altered. When the VM first starts, the control domain time is used to set the initial time of the hardware clock and system clock.

If you change the time on the hardware clock, this change is persisted when the VM reboots.

System clock behavior depends on the operating system of the VM. For more information, see the documentation for your VM operating system.

You cannot change the XenServer time handling behavior for HVM Linux VMs.

Install HVM VMs from Reseller Option Kit (BIOS-locked) media

There are two types of HVM VMs: BIOS-generic and BIOS-customized. To enable installation of Reseller Option Kit (BIOS-locked) OEM versions of Windows onto a VM, copy the BIOS strings of the VM from the host with which the media was supplied. Alternatively, advanced users can set user-defined values to the BIOS strings.

BIOS-generic

The VM has generic XenServer BIOS strings.

Note:

If a VM doesn’t have BIOS strings set when it starts, the standard XenServer BIOS strings are inserted into it and the VM becomes BIOS-generic.

BIOS-customized

For HVM VMs you can customize the BIOS in two ways: Copy-Host BIOS strings and User-Defined BIOS strings.

Copy-Host BIOS strings

The VM has a copy of the BIOS strings of a particular server in the pool. To install the BIOS-locked media that came with your host, follow the procedures given below.

Using XenCenter:

  1. Click the Copy host BIOS strings to VM check box in the New VM Wizard.

Using the CLI:

  1. Run the vm-install copy-bios-strings-from command. Specify the host-uuid as the host from which the strings are copied (that is, the host that the media was supplied with):

    xe vm-install copy-bios-strings-from=host uuid \
       template=template name sr-name-label=name of sr \
       new-name-label=name for new VM
    

    This command returns the UUID of the newly created VM.

    For example:

    xe vm-install copy-bios-strings-from=46dd2d13-5aee-40b8-ae2c-95786ef4 \
       template="win7sp1" sr-name-label=Local\ storage  \
       new-name-label=newcentos
    7cd98710-bf56-2045-48b7-e4ae219799db
    
  2. If the relevant BIOS strings from the host have been successfully copied into the VM, the command vm-is-bios-customized confirms this success:

    xe vm-is-bios-customized uuid=VM uuid
    

    For example:

    xe vm-is-bios-customized \
      uuid=7cd98710-bf56-2045-48b7-e4ae219799db
    This VM is BIOS-customized.
    

    Note:

    When you start the VM, it is started on the physical host from which you copied the BIOS strings.

Warning:

It is your responsibility to comply with any EULAs governing the use of any BIOS-locked operating systems that you install.

User-defined BIOS strings

The user has option to set custom values in selected BIOS strings using CLI/API. To install the media in HVM VM with customized BIOS, follow the procedure given below.

Using the CLI:

  1. Run the vm-install command (without copy-bios-strings-from):

    xe vm-install template=template name sr-name-label=name of sr \
      new-name-label=name for new VM
    

    This command returns the UUID of the newly created VM.

    For example:

    xe vm-install template="win7sp1" sr-name-label=Local\ storage  \
      new-name-label=newcentos
    7cd98710-bf56-2045-48b7-e4ae219799db
    
  2. To set user-defined BIOS strings, run the following command before starting the VM for the first time:

    xe vm-param-set uuid=VM_UUID bios-strings:bios-vendor=VALUE \
    bios-strings:bios-version=VALUE bios-strings:system-manufacturer=VALUE \
    bios-strings:system-product-name=VALUE bios-strings:system-version=VALUE \
    bios-strings:system-serial-number=VALUE bios-strings:enclosure-asset-tag=VALUE
    

    For example:

    xe vm-param-set uuid=7cd98710-bf56-2045-48b7-e4ae219799db \
    bios-strings:bios-vendor="vendor name" \
    bios-strings:bios-version=2.4 \
    bios-strings:system-manufacturer="manufacturer name" \
    bios-strings:system-product-name=guest1 \
    bios-strings:system-version=1.0 \
    bios-strings:system-serial-number="serial number" \
    bios-strings:enclosure-asset-tag=abk58hr
    

    Notes:

    • Once the user-defined BIOS strings are set in a single CLI/API call, they cannot be modified.

    • You can decide on the number of parameters you want to provide to set the user-defined BIOS strings.

Warning:

It is your responsibility to:

  • Comply with any EULAs and standards for the values being set in VM’s BIOS.

  • Ensure that the values you provide for the parameters are working parameters. Providing incorrect parameters can lead to boot/media installation failure.

Assign a GPU to a Windows VM (for use with Citrix Virtual Desktops)

XenServer enables you to assign a physical GPU in the XenServer host to a Windows VM running on the same host. This GPU Pass-Through feature benefits graphics power users, such as CAD designers, who require high performance graphics capabilities. It is supported only for use with Citrix Virtual Desktops.

While XenServer supports only one GPU for each VM, it automatically detects and groups identical physical GPUs across hosts in the same pool. Once assigned to a group of GPUs, a VM may be started on any host in the pool that has an available GPU in the group. When attached to a GPU, a VM has certain features that are no longer available, including XenMotion live migration, VM snapshots with memory, and suspend/resume.

Assigning a GPU to a VM in a pool does not interfere with the operation of other VMs in the pool. However, VMs with GPUs attached are considered non-agile. If VMs with GPUs attached are members of a pool with high availability enabled, both features overlook these VMs. The VMs cannot be migrated automatically.

GPU Pass-Through is available to Windows VMs only. It can be enabled using XenCenter or the xe CLI.

Requirements

GPU Pass-Through is supported for specific machines and GPUs. In all cases, the IOMMU chipset feature (known as VT-d for Intel models) must be available and enabled on the XenServer host. Before enabling the GPU Pass-Through feature, visit the Hardware Compatibility List.

Before assigning a GPU to a VM

Before you assign a GPU to a VM, put the appropriate physical GPUs in your XenServer host and then restart the machine. Upon restart, XenServer automatically detects any physical GPUs. To view all physical GPUs across hosts in the pool, use the xe pgpu-list command.

Ensure that the IOMMU chipset feature is enabled on the host. To do so, enter the following:

xe host-param-get uuid=uuid_of_host param-name=chipset-info param-key=iommu

If the value printed is false, IOMMU is not enabled, and GPU Pass-Through is not available using the specified XenServer host.

To assign a GPU to a Windows VM by using XenCenter:

  1. Shut down the VM that you want to assign a GPU.

  2. Open the VM properties: right-click the VM and select Properties.

  3. Assign a GPU to the VM: Select GPU from the list of VM properties, and then select a GPU type. Click OK.

  4. Start the VM.

To assign a GPU to a Windows VM by using the xe CLI:

  1. Shut down the VM that you want to assign a GPU group by using the xe vm-shutdown command.

  2. Find the UUID of the GPU group by entering the following:

    xe gpu-group-list
    

    This command prints all GPU groups in the pool. Note the UUID of the appropriate GPU group.

  3. Attach the VM to a GPU group by entering the following:

    xe vpgu-create gpu-group-uuid=uuid_of_gpu_group vm-uuid=uuid_of_vm
    

    To ensure that the GPU group has been attached, run the xe vgpu-list command.

  4. Start the VM by using the xe vm-start command.

  5. Once the VM starts, install the graphics card drivers on the VM.

    Installing the drivers is essential, as the VM has direct access to the hardware on the host. Drivers are provided by your hardware vendor.

Note:

If you try to start a VM with GPU Pass-Through on the host without an available GPU in the appropriate GPU group, XenServer prints an error.

To detach a Windows VM from a GPU by using XenCenter:

  1. Shut down the VM.

  2. Open the VM properties: right-click the VM and select Properties.

  3. Detach the GPU from the VM: Select GPU from the list of VM properties, and then select None as the GPU type. Click OK.

  4. Start the VM.

To detach a Windows VM from a GPU by using the xe CLI:

  1. Shut down the VM by using the xe vm-shutdown command.

  2. Find the UUID of the vGPU attached to the VM by entering the following:

    xe vgpu-list vm-uuid=uuid_of_vm
    
  3. Detach the GPU from the VM by entering the following:

    xe vgpu-destroy uuid=uuid_of_vgpu
    
  4. Start the VM by using the xe vm-start command.

Create ISO images

XenServer can use ISO images as installation media and data sources for Windows or Linux VMs. This section describes how to make ISO images from CD/DVD media.

To create an ISO on a Linux system:

  1. Put the CD- or DVD-ROM disk into the drive. Ensure that the disk is not mounted. To check, run the command:

    mount

    If the disk is mounted, unmount the disk. See your operating system documentation for assistance if necessary.

  2. As root, run the command

    dd if=/dev/cdrom of=/path/cdimg_filename.iso
    

    This command takes some time. When the operation is completed successfully, you see something like:

    1187972+0 records in
    1187972+0 records out
    

    Your ISO file is ready.

To create an ISO on a Windows system:

Windows computers do not have an equivalent operating system command to create an ISO. Most CD-burning tools have a means of saving a CD as an ISO file.