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.
-
Install the Windows PV drivers.
-
Navigate to the directory where the drivers are installed (by default
c:\Program Files\Citrix\XenTools
, or the value ofHKEY_LOCAL_MACHINE\Software\Citrix\XenTools\Install_dir
in the Windows Registry). -
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.
-
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.
-
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:
-
Open System by clicking the Start button, right-click on Computer, and then select Properties
-
Click Remote settings. If you’re prompted for an administrator password, type the password you created during the VM setup.
-
In the Remote Desktop area, click the check box labeled Allow connections from computers running any version of Remote Desktop (Windows 7).
-
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:
Guest OS | Default wall clock behavior |
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 5.x (32-/64-bit) | Dependent | Yes |
Scientific Linux 6.x (32-/64-bit) | Independent | |
SLES 11 SP3, 11 SP4 (32-/64-bit) | Dependent | Yes |
SLES 12 SP1, 12 SP2 (64-bit) | Dependent | Yes |
SLED 11 SP3, 11 SP4 (64-bit) | Dependent | Yes |
SLED 12 SP1, 12 SP2 (64-bit) | Dependent | Yes |
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 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
-
From a root prompt on the VM, run the command:
echo 1 > /proc/sys/xen/independent_wallclock
-
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
-
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
-
From a root prompt on the VM, run the command:
echo 0 > /proc/sys/xen/independent_wallclock
-
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
-
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.
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.
In order to install the BIOS-locked media that came with your host, you will need to follow the steps below:
Using XenCenter
- Click the Copy host BIOS strings to VM check box in the New VM Wizard.
Using the xe CLI
-
Run the
vm-install copy-bios-strings-from
command and specify thehost-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
-
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:
-
Create, install, and configure the Windows VM as desired.
-
Apply all relevant Service Packs and updates.
-
Install the XenServer PV Tools.
-
Install any applications and perform any other configuration.
-
Run
sysprep
. This will shut down the VM when it completes. -
Using XenCenter convert the VM into a template.
-
Clone the newly created template into new VMs as required.
-
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
-
Shut down the VM that you want to assign a GPU.
-
Open the VM properties: right-click the VM and select Properties.
-
Assign a GPU to the VM: Select GPU from the list of VM properties, and then select a GPU type. Click OK.
-
Start the VM.
To assign a GPU to a Windows VM using the xe CLI
-
Shut down the VM that you want to assign a GPU group by using the
xe vm-shutdown
command. -
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.
-
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. -
Start the VM by using the
xe vm-start
command. -
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
-
Shut down the VM.
-
Open the VM properties: right-click the VM and select Properties.
-
Detach the GPU from the VM: Select GPU from the list of VM properties, and then select None as the GPU type. Click OK.
-
Start the VM.
To detach a Windows VM from a GPU using the xe CLI
-
Shut down the VM by using the
xe vm-shutdown
command. -
Find the UUID of the vGPU attached to the VM by entering the following:
xe vgpu-list vm-uuid=uuid_of_vm
-
Detach the GPU from the VM by entering the following:
xe vgpu-destroy uuid=uuid_of_vgpu
-
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
-
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.
-
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
- 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.
In this article
- VM Boot Behavior
- Making the ISO Library Available to XenServer hosts
- Windows Volume Shadow Copy Service (VSS) provider
- Connecting to a Windows VM Using Remote Desktop
- Time Handling in Windows VMs
- Time Handling in Linux VMs
- Installing HVM VMs from Reseller Option Kit (BIOS-locked) Media
- Preparing for Cloning a Windows VM Using Sysprep
- Assigning a GPU to a Windows VM (for Use with XenDesktop)
- Creating ISO Images