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

Tip:

Use this boot behavior if you are hosting Citrix Virtual Desktops that are static or dedicated machines.

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
<!--NeedCopy-->

Reset

Tip:

Use this boot behavior if you are hosting Citrix Virtual Desktops that are shared or randomly allocated machines.

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:

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
<!--NeedCopy-->

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
<!--NeedCopy-->

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
<!--NeedCopy-->

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.

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 VM Tools for Windows. 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.

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.We recommend 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 live migration, ensure that you have up-to-date XenServer VM Tools for Windows installed. XenServer VM Tools for Windows 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

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.

Hardware clocks in 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 this XenServer time handling behavior.

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

There are two types of VM: 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

You can customize the BIOS in two ways: Copy-Host BIOS strings and User-Defined BIOS strings.

Note:

After you first start a VM, you cannot change its BIOS strings. Ensure that the BIOS strings are correct before starting the VM for the first time.

Copy-Host BIOS strings

The VM has a copy of the BIOS strings of a particular host 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
   <!--NeedCopy-->
   

   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
   <!--NeedCopy-->
   

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
   <!--NeedCopy-->
   

   For example:

   xe vm-is-bios-customized uuid=7cd98710-bf56-2045-48b7-e4ae219799db
       This VM is BIOS-customized.
   <!--NeedCopy-->
   

   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 a 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
   <!--NeedCopy-->
   

   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
   <!--NeedCopy-->
   

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
   <!--NeedCopy-->
   

   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
   <!--NeedCopy-->
   

   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 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 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
<!--NeedCopy-->

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
   <!--NeedCopy-->
   

   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
   <!--NeedCopy-->
   

   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
   <!--NeedCopy-->
   

3. Detach the GPU from the VM by entering the following:

   xe vgpu-destroy uuid=uuid_of_vgpu
   <!--NeedCopy-->
   

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
   <!--NeedCopy-->
   

   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
   <!--NeedCopy-->
   

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

   1187972+0 records in
   1187972+0 records out
   <!--NeedCopy-->
   

   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.