Advanced Notes for Virtual Machines

This article 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 make any changes to its boot behavior setting.

Persist (XenDesktop - Private Desktop Mode)

This is the default behavior 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 do this, shut down the VM, and then enter the following command:

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

Reset (XenDesktop - 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 will be lost when the VM is next booted.

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

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

Warning

After making the change to on-boot=reset, any data saved to the VDI will be discarded after the next shutdown/start or reboot

Making 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, this is accomplished 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, additional arguments to the mount command may be passed.

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

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

The unc_path argument should have back-slashes replaced by forward-slashes. For example:

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

If you are using NLTMv2 authentication for your CIFS ISO SR, ensure that you also specify the cache=none parameter. For example:

xe-mount-iso-sr //server1/myisos -t cifs -o username=johndoe/mydomain,sec=ntlmv2,cache=none

After mounting the share, any available ISOs will be available from the Install from ISO Library or DVD drive menu in XenCenter, or as CD images from the CLI commands.

The ISO should be attached to an appropriate Windows template.

Windows Volume Shadow Copy Service (VSS) provider

The Windows tools also include a XenServer VSS provider 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.

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.

Note

The VSS provider is automatically uninstalled when the PV drivers are uninstalled, and need to be activated again upon reinstallation. They can be uninstalled separately from the PV drivers by using uninstall-XenProvider.cmd in the same directory.

Connecting to a Windows VM Using Remote Desktop

There are two ways of viewing a Windows VM console, both of which support full keyboard and mouse interactivity.

1. Using XenCenter. This provides a standard graphical console and uses XenServer’s in-built VNC technology to provide remote access to your virtual machine console.

2. Connecting using Windows Remote Desktop. This 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 will be disabled. To enable it, you will need to install the XenServer PV Tools and follow the procedure below to enable it in each VM that you want to connect using Remote Desktop:

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. If you want 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 will now be able to 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, so make sure the settings for sleep and hibernation on the remote computer are set to Never.

Time Handling in Windows VMs

For Windows guests, time is initially driven from the control domain clock, and is updated during VM lifecycle operations such as suspend, reboot and so on. Citrix recommends running a reliable NTP service in the control domain and all Windows VMs.

If you manually set a VM to be 2 hours ahead of the control domain (for example, using a time-zone offset within the VM), then it will persist. If you subsequently change the control domain time (either manually or, if it is automatically corrected, by NTP), the VM will shift accordingly but maintain the 2 hour 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/resume operations or live relocation using XenMotion, it is important to have up-to-date XenServer PV Tools installed, as they notify the Windows kernel that a time synchronization is required after resuming (potentially on a different physical host).

Note

Customers who are running Windows VMs in XenDesktop environment MUST ensure that the host clock has the same source as their 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

Time handling, in Linux VMs time handling, in 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. For example, 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, make sure that you change the time-zone from the default UTC to your local value (see Linux VMs for specific distribution instructions).

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 is a convenient mode, as only the control domain needs to be running 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 wall clock behavior for PV Linux VMs:

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 wall clock 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 wallclock behavior

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

2. This 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 wallclock behavior

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

2. This 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, refer to the documentation for your VM operating system.

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

Installing HVM VMs from Reseller Option Kit (BIOS-locked) Media

HVM VMs can be:

• BIOS-generic: the VM has generic XenServer BIOS strings;

• BIOS-customized: the VM has a copy of the BIOS strings of a particular server in the pool;

• without BIOS strings: immediately after its creation. If a VM does not have BIOS strings set when it is started, the standard XenServer BIOS strings will be inserted into it, and the VM will become BIOS-generic.

To allow installation of Reseller Option Kit (BIOS-locked) OEM versions of Windows, onto a VM running on a XenServer host, the BIOS strings of the VM will need to be copied from the host with which the ROK media was supplied.

In order to install the BIOS-locked media that came with your host, you will need to follow the steps below:

Using XenCenter

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

Using the xe CLI

1. Run the vm-install copy-bios-strings-from command and specify the host-uuid as the host from which the strings should be 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 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 will confirm this:

   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.
   

   When you start the VM, it will be 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.

Preparing for Cloning a Windows VM Using Sysprep

Sysprep, for preparing Windows VM for cloning sysprepThe only supported way to clone a windows VM is by using the Windows utility sysprep to prepare the VM.

The sysprep utility modifies the local computer SID to make it unique to each computer. The sysprep binaries are located in the C:\Windows\System32\Sysprep folder.

Note

For older versions of Windows, the sysprep binaries are on the Windows product CDs in the \support\tools\deploy.cab file. These binaries must be copied to your Windows VM before using.

The steps that you need to take to clone Windows VMs are:

1. Create, install, and configure the Windows VM as desired.

2. Apply all relevant Service Packs and updates.

3. Install the XenServer PV Tools.

4. Install any applications and perform any other configuration.

5. Run sysprep. This will shut down the VM when it completes.

6. Using XenCenter convert the VM into a template.

7. Clone the newly created template into new VMs as required.

8. When the cloned VM starts, it will get a new SID and name, run a mini-setup to prompt for configuration values as necessary, and finally restart, before being available for use.

   Note

   The original, sys-prepped VM (the “source” VM) should not be restarted again after the sysprep stage, and should be converted to a template immediately afterwards to prevent this. If the source VM is restarted, sysprep must be run on it again before it can be safely used to make additional clones.

For more information on using sysprep, visit the following Microsoft website:

The Windows Automated Installation Kit (AIK)

Assigning a GPU to a Windows VM (for Use with XenDesktop)

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

While XenServer supports only one GPU for each VM, it automatically detects and groups together 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. Once 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 HA enabled, those VMs are overlooked by both features and 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 http://hcl.vmd.citrix.com to check the hardware compatibility list.

Before Assigning a GPU to a VM

Before you assign a GPU to a VM, you need to put the appropriate physical GPU(s) in your XenServer host and then restart the machine. Upon restart, XenServer automatically detects any physical GPU(s). To view all physical GPU(s) 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 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 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 a XenServer host without an available GPU in the appropriate GPU group, XenServer prints an error message.

To detach a Windows VM from a GPU 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 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.

Creating ISO Images

XenServer can use ISO images of CD-ROM or DVD-ROM disks as installation media and data sources for Windows or Linux VMs. This section describes how to make ISO images from CD/DVD media.Creating an ISO image

Creating an ISO on a Linux computer

1. Put the CD- or DVD-ROM disk into the drive. The disk should not be mounted. To check, run the command:

   mount
   

   If the disk is mounted, unmount the disk. Refer to your operating system documentation for assistance if required.

2. As root, run the command

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

   This will take some time. When the operation is completed successfully, you should see something like:

   1187972+0 records in
   1187972+0 records out
   

   Your ISO file is ready.

Creating an ISO on a Windows computer

1. 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.