Citrix, Inc.
851 West Cypress Creek Road
Fort Lauderdale, FL 33309
United States of America
Disclaimers
This document is furnished "AS IS." Citrix, Inc. disclaims all warranties regarding the contents of this
document, including, but not limited to, implied warranties of merchantability and fitness for any particular
purpose. This document may contain technical or other inaccuracies or typographical errors. Citrix, Inc.
reserves the right to revise the information in this document at any time without notice. This document and
the software described in this document constitute confidential information of Citrix, Inc. and its licensors,
and are furnished under a license from Citrix, Inc.
Citrix Systems, Inc., the Citrix logo, Citrix XenServer and Citrix XenCenter, are trademarks of Citrix Systems,
Inc. in the United States and other countries. All other products or services mentioned in this document are
trademarks or registered trademarks of their respective companies.
Trademarks
Citrix ®
XenServer ®
XenCenter ®
1.0 Edition
Table of Contents
About this document ................................................................................... 1
C. Troubleshooting VM problems ............................................................. 50
VM crashes .............................................................................................................................. 50
Controlling Linux VM Crashdump Behaviour ............................................................................. 50
Controlling Windows VM Crashdump Behaviour ........................................................................ 51
Troubleshooting boot problems on Linux VMs .................................................................................. 51
Index ............................................................................................................ 52
vi
About this document
Overview
This document is a guide to creating Virtual Machines with XenServer™, the platform virtualization solution
from Citrix®. It describes the various methods of getting VMs up and running on XenServer hosts for each
of the supported operating systems.
This section summarizes the rest of the guide so that you can find the information you need. The following
topics are covered:
• General information about creating VMs
• Creating Windows VMs
• Creating Linux VMs
• Updating VMs
• Creating and using ISO images of vendor media for installing VMs
• Setting up a network repository of vendor media for installing VMs
• Troubleshooting problems with VMs
How this Guide relates to other documentation
This document is primarily aimed at system administrators who need to set up deployments of XenServer
VMs. Other documentation shipped with this release includes:
• XenServer Installation Guide provides step-by-step instructions on installing XenServer hosts and the
XenCenter management console;
• XenServer Administrator's Guide describes the tasks involved in configuring a XenServer deployment -how to set up storage, networking and resource pools, and how to administer XenServer hosts using the
xe command line interface (CLI).
• XenServer Software Development Kit Guide presents an overview of the XenServer SDK -- a selection
of code samples that demonstrate how to write applications that interface with XenServer hosts.
• XenAPI Specification provides a programmer's reference guide to the XenServer API.
• Release notes provide a list of known issues that affect this release.
1
Creating VMs
This chapter provides an overview of how VMs are created and lists virtual memory and virtual disk size
minimums, describes the differences in virtual device support for the members of the XenServer product
family. This chapter also discusses physical to virtual conversion (P2V), cloning templates, and importing
previously-exported VMs.
Overview
VMs are created from templates. A template is a "gold image" that contains all the various configuration
settings to instantiate a specific VM. XenServer ships with a base set of templates, which range from generic
"raw" VMs that can boot an OS vendor installation CD or run an installation from a network repository to
complete pre-configured OS instances.
Different operating systems require slightly different settings in order to run at their best. XenServer
templates are tuned to maximize operating system performance.
The Linux templates create Pure Virtual (PV) guests, as opposed to the HVM guests created by the Windows
and Other Install Media templates. Other Install Media template Linux installations are not supported.
There are three basic methods by which VMs are created using templates:
• using a complete pre-configured template.
• Installing from a CD or an ISO image onto the appropriate template.
• Installing from vendor media on a network installation server directly onto a template.
See Installing Linux VMs to find out which methods are supported for which Linux flavor operating systems.
Windows VMs can be installed from a CD or an ISO image.
Creating VMs by installing Windows operating systems onto the appropriate templates is described in
Installing Windows VMs.
Creating VMs by installing Linux operating systems onto the appropriate templates is described in Installing
Linux VMs.
Additionally, VMs can be created by:
• using the physical-to-virtual (P2V) and virtual-to-virtual (V2V) conversion tool XenConvert
• importing an existing, exported VM
• converting an existing VM to a template
These methods are described in this chapter.
Virtual memory and disk size limits
In general, when installing VMs, be sure to follow the memory and disk space guidelines of the operating
system and any relevant applications that you want to run when allocating resources such as memory and
disk space.
Note that individual versions of the operating systems may also impose their own maximum limits on the
amount of memory supported (for example, for licensing reasons).
Warning:
2
When configuring guest memory, please be careful not to exceed the maximum amount of physical memory
addressable by your operating system. Setting a memory maximum that's greater than the operating system
supported limit may lead to stability problems within your guest.
Operating SystemMinimum RAMMaximum
RAM
Windows 7 32-bit1GB4GBMinimum
Windows 7 64-bit2GB32GBMinimum
Windows Server 2008 R2512MB32GBMinimum
Windows Server 2008 32-bit/64bit
Windows Vista 32-bit1GB4GB16GB
Windows Server 2003256MB32GB2GB
Windows XP SP2/3256MB32GB1.5GB
Windows 2000 SP4256MB32GB2GB
512MB32GBMinimum
Disk space
16GB, 40GB
or more
recommended
20GB
32GB
10GB, 40GB
or more
recommended
CentOS 4.5, 4.6, 4.7256MB16GB800MB
CentOS 5.0, 5.1, 5.2, 5.3, 5.4512MB16GB800MB
Red Hat Enterprise Linux 4.5,
4.6, 4.7, 4.8
Red Hat Enterprise Linux 5.0,
5.1, 5.2, 5.3, 5.4
SUSE Linux Enterprise Server 9
SP2/3/4
SUSE Linux Enterprise Server
10 SP1/2, 11
Oracle Enterprise Linux 5.0, 5.1,
5.2, 5.3, 5.4
Debian Lenny128MB32GB4GB
Note:
Some 32-bit Windows operating systems can support more than 4 GB of RAM through the use of a special
mode - physical address extension (PAE) mode. Administrators wishing to reconfigure a VM with greater
256MB16GB800MB
512MB16GB800MB
256MB32GB1GB
512MB32GB1.5GB
512MB16GB800MB
3
than 4 GB of RAM must use the xe CLI, and not XenCenter, as the CLI does not impose any upper bounds for
memory-static-max. For more information on how to set the memory static max, please refer to the
Dynamic Memory Control chapter, in the XenServer Administrator's Guide.
XenServer product family virtual device support
The current version of the XenServer product family has the following general limitations on virtual devices
for VMs. Note that specific guest operating systems may have lower limits for certain features. These
limitations are noted in the individual guest installation section.
Virtual deviceLinux VMsWindows VMs
Number of virtual CPUs32
*
8
Number of virtual disks7 (including virtual CD-ROM)7 (including virtual CD-ROM)
Number of virtual CD-ROM drives11
Number of virtual NICs7
*
A maximum of 8 VCPUs are supported by XenCenter.
†
except for SLES 10 SP1 and RHEL 4.x, which support 3. RHEL 5.0/5.1/5.2 support 3, but can support 7 when the kernel is patched with the Citrix
Tools for Virtual Machines. The same applies for Oracle and CentOS 5.0/5.1/5.2
†
7
Physical to Virtual Conversion (P2V)
Physical to Virtual Conversion(P2V) is the process by which an existing Windows operating system on a
physical server -- its filesystem, configuration, and so on -- is turned into a virtualized instance of the same
operating system and filesystem, transferred, instantiated, and started as a VM on the XenServer host.
For existing physical instances of Windows servers, use XenConvert. XenConvert runs on the physical
Windows machine and converts it live into a VHD-format disk image or an XVA template suitable for
importing into a XenServer host. The physical host does not need to be restarted during this process,
and device drivers are automatically modified to make them able to run in a virtual environment. For more
information, please refer to the XenConvert documentation for installation and usage guidelines.
Cloning an existing VM
You can make a copy of an existing VM by cloning from a template. Templates are ordinary VMs which are
intended to be used as master copies to instantiate VMs from. A VM can be customized and converted into
a template, but be sure to follow the appropriate preparation procedure for the VM (see the section called
“Preparing to clone a Windows VM” for Windows and the section called “Preparing to clone a Linux VM” for
Linux). Templates cannot be used as normal VMs.
XenServer has two mechanisms for cloning VMs: a full copy, or a faster Copy-on-Write (CoW) mode which
only writes modified blocks to disk. The CoW mode is only supported for file-backed VMs. CoW is designed
to save disk space and allow fast clones, but will slightly slow down normal disk performance. A template
can be fast-cloned multiple times without slowdown, but if a template is cloned into a VM and the clone
converted back into a template, disk performance can linearly decrease depending on the number of times
this has happened. In this event, the vm-copy CLI command can be used to perform a full copy of the disks
and restore expected levels of disk performance.
Resource pools introduce some complexities around creating custom templates and cloning them. If you
create a template on a server in a pool, and all virtual disks of the source VM are on shared storage
4
repositories, the operation of cloning that template will be forwarded to any server in the pool that can see
those shared SRs. However, if you create the template from a source VM that has any virtual disks on a
local SR, then the clone operation can only execute on the server that can access that SR.
Importing an exported VM
You can create a VM by importing an existing exported VM. Like cloning, exporting and importing a VM is
way to create additional VMs of a certain configuration. You might, for example, have a special-purpose
server configuration that you use many times. Once you have set up a VM the way you want it, you can
export it, and import it later to create another copy of your specially-configured VM. You can also use export
and import to move a VM to a XenServer host that in another resource pool.
When importing a VM, you can choose to preserve the MAC address on any virtual network interfaces
associated with it. If you choose to generate a new MAC address, be sure to follow the appropriate
preparation procedure for the imported VM. See the section called “Preparing to clone a Windows VM” for
Windows and the section called “Preparing to clone a Linux VM” for Linux.
Importing an exported VM may take some time, depending on the size of the VM and the speed and
bandwidth of the network connection between the XenServer host and XenCenter.
When VMs are imported XenServer re-attaches the VM VIFs to any network that has the same name as the
network on the server that the VM was exported from. If no matching network can be found a new private
network is created and the VM VIFs are attached to that.
Exporting a VM
An existing VM can be exported using XenCenter or the CLI. This section describes using the CLI. For
details on exporting using XenCenter, see the XenCenter online Help.
The following procedure assumes that you have multiple XenServer hosts and that you are administering
them using the CLI on a separate machine (that is, a machine that is not one of the XenServer hosts)
where you can maintain a library of export files. Citrix recommends not exporting a VM to a XenServer
host filesystem.
Be sure to include the .xva extension when specifying the export filename. If the exported VM does not
have this extension and you attempt to import it using XenCenter, it might fail to recognize the file as a valid
XVA file.
3.The export process might take some time to complete. When finished, the command prompt returns.
Importing a VM
An exported VM file can be imported using XenCenter or the CLI. This section describes using the CLI. For
details on importing using XenCenter, see the XenCenter online Help.
5
The following procedure assumes that you are administering the XenServer host using the CLI on a separate
machine (that is, a machine that is not one of your XenServer hosts) where you maintain a library of export
files.
To import a VM using the CLI
1.To import the VM to the default SR on the target XenServer host:
2.The import process might take some time to complete. When finished, the command prompt returns
the UUID of the newly-imported VM.
VM Block Devices
In the para-virtualized (PV) Linux case, block devices are passed through as PV devices. XenServer does
not attempt to emulate SCSI or IDE, but instead provides a more suitable interface in the virtual environment
in the form of xvd* devices. It is also sometimes possible (depending on the OS) to get an sd* device using
the same mechanism, where the PV driver inside the VM takes over the SCSI device namespace. This is not
desirable so it is best to use xvd* where possible for PV guests (this is the default for Debian and RHEL).
For Windows or other fully virtualized guests, XenServer emulates an IDE bus in the form of an hd* device.
When using Windows, installing the Citrix Tools for Virtual Machines installs a special PV driver that works
in a similar way to Linux, except in a fully virtualized environment.
6
Installing Windows VMs
XenServer allows you to install Windows 2000 SP4, Windows Server 2003 (32-/64- bit), Windows Server
2008, Windows XP SP2/3, Windows Vista and Windows 7 as a VM. Installing Windows VMs on a XenServer
host requires hardware virtualization support (Intel VT or AMD-V).
The process of installing a Windows VM can be broken down into two main steps:
• installing the Windows operating system
• installing the paravirtualized device drivers known as the Citrix Tools for Virtual Machines
Windows VMs are installed by cloning an appropriate template using either XenCenter or the CLI. The
templates for individual guests have predefined platform flags set which define the configuration of the
virtual hardware. For example, all Windows VMs are installed with the ACPI Hardware Abstraction Layer
(HAL) mode enabled. If you subsequently change one of these VMs to have multiple virtual CPUs, Windows
automatically switches the HAL to multi-processor mode.
The available Windows templates are:
• Windows Server 2008 (x86), optimized for Citrix XenApp
can be used to install all editions of Windows Server 2008 (x86). This template is specially tuned to
optimize XenApp performance.
• Windows Server 2008 (x64), optimized for Citrix XenApp
can be used to install all editions of Windows Server 2008 (x64). This template is specially tuned to
optimize XenApp performance.
• Windows Server 2008 R2 (x64), optimized for Citrix XenApp
can be used to install all editions of Windows Server 2008 R2 64-bit. This template is specially tuned to
optimize XenApp performance.
• Windows Server 2003 (x86), optimized for Citrix XenApp
can be used to install Windows Server 2003 32-bit SP0, SP1, SP2, and R2. The Server, Enterprise,
Data Centre, and SBS editions are supported. This template is specially tuned to optimize XenApp
performance.
• Windows Server 2003 (x64), optimized for Citrix XenApp
can be used to install Windows Server 2003 64-bit. The Server, Enterprise, Data Centre, and SBS editions
are supported. This template is specially tuned to optimize XenApp performance.
• Windows Server 2008
can be used to install Windows Server 2008 32-bit.
• Windows Server 2008 x64
can be used to install Windows Server 2008 64-bit.
• Windows Server 2008 R2 x64
can be used to install Windows Server 2008 R2, 64-bit.
• Windows Server 2003
can be used to install Windows Server 2003 32-bit SP0, SP1, SP2, and R2. The Server, Enterprise, Data
Centre, and SBS editions are supported.
• Windows Server 2003 x64
can be used to install Windows Server 2003 64-bit. The Server, Enterprise, Data Centre, and SBS editions
are supported.
• Windows 2000 SP4 (x86)
can be used to install Windows 2000 Server SP 4, 32-bit. Earlier service packs are not supported.
7
• Windows 7 (x86)
can be used to install Windows 7, 32-bit.
• Windows 7 (x64)
can be used to install Windows 7, 64-bit.
• Windows Vista (x86)
can be used to install Windows Vista 32-bit. The Enterprise edition is supported.
• Windows XP SP3 (x86)
can be used to install Windows XP Service Pack 3, 32-bit. Earlier service packs are not supported.
• Windows XP SP2 (x86)
can be used to install Windows XP Service Pack 2, 32-bit. Earlier service packs are not supported.
The Windows VM can be installed either from an install CD in a physical CD-ROM drive on the XenServer
host, or from an ISO image of your Windows media. See Appendix A, Creating ISO images for information
on how to make an ISO image from a Windows install CD and make it available for use.
Making the ISO 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
Additional arguments to the mount command may be passed in, for advanced use.
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 command:
After mounting the share, any ISOs in it should be available by name from the CD pulldown list in XenCenter,
or as CD images from the CLI commands. The ISO should be attached to an appropriate Windows template.
Copying ISOs to local storage
In XenServer 3.2 and earlier, ISOs could be copied directly to the control domain into the /opt/
xensource/packages/iso directory. In XenServer 5.6 hosts, this directory is reserved for use of the
built-in ISO images, and is not intended for general use. This directory is considered to be identical across
hosts in a resource pool, and CD images may fail to attach if the contents are modified.
4.Copy the ISO images into this directory, taking care not to fill up the control domain filesystem.
5.Verify that the ISO image is available for use by using the xe vdi-list command, or by checking in
XenCenter.
Warning:
Be extremely careful with copying ISOs directly onto the control domain filesystem, as it has limited space
available. A network share is a much safer mechanism for storing large numbers of ISO images. If the control
domain does fill up, unpredictable behavior will result.
Windows PV drivers
The Citrix paravirtualized network and SCSI drivers (Citrix Tools for Virtual Machines) provide high
performance I/O services without the overhead of traditional device emulation. During the installation of
a Windows operating system, XenServer uses traditional device emulation to present a standard IDE
controller and a standard network card to the VM. This allows Windows to complete its installation using
built-in drivers, but with reduced performance due to the overhead inherent in emulation of the controller
drivers.
After Windows is installed, install the Citrix high-speed PV drivers. These are on an ISO available to the
virtual CD-ROM drive of the Virtual Machine. These drivers replace the emulated devices and provide highspeed transport between Windows and the XenServer product family software.
Note:
While a Windows VM functions without them, performance is significantly hampered unless these drivers
are installed. Running Windows VMs without these drivers is not supported. Some features, such as live
relocation across physical hosts, will only work with the PV drivers installed and active.
Attach the Windows PV drivers ISO to the VM by using the Install Tools menu in XenCenter, or by directly
attaching the built-in xs-tools.iso ISO image on the VM using the CLI. Once the ISO is attached, double-
click on the xensetup.exe installer executable and follow the on-screen prompts.
Note:
To silently install the Citrix Tools for Virtual Machines and prevent the system from rebooting afterwards,
use the /S and /norestart options:
<install_dir>/xensetup.exe /S /norestart
The Windows PV drivers are installed by default in the C:\Program Files\Citrix\XenTools directory
on the VM.
The Citrix Tools for Virtual Machines can also be installed on a provisioned Windows machine by running
the executable windows-pvdrivers-xensetup.exe, located in the client_install/ directory of the
installation CD.
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.
9
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.
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.
Remote Desktop
The graphical console for Windows can be either a standard console using an emulated graphics card, or
an RDP connection.
For Windows VMs, there is a Switch to Remote Desktop button on the Console tab in XenCenter. Clicking
it disables the standard graphical console, and switches to using Remote Desktop instead.
The button will be disabled if you do not have Remote Desktop enabled in the VM. To enable it, install the
PV drivers and follow the procedure to enable Remote Desktop:
To enable Remote Desktop on a Windows VM
1.From the Start menu, select Control Panel.
2.From the Control Panel window, select System.
3.In the System Properties dialog box, select the Remote tab.
4.In the Remote Desktop section of this dialog box, check the check box labeled Allow users to connect
remotely to this computer (Windows XP) or Enable Remote Desktop on this computer (Windows
2003 Server).
5.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 usernames. Users with Administrator privileges on the
Windows domain can connect by default.
Preparing to clone a Windows VM
Use the Windows utility sysprep to prepare a Windows VM for cloning. This is the only supported way to
clone a Windows VM.
Computers running Windows operating systems are uniquely identified by a Security ID (SID). When cloning
a Windows VM, it is important to take steps to ensure the uniqueness of the SID. Cloning an installation
without taking the recommended system preparation steps can lead to duplicate SIDs and other problems.
Because the SID identifies the computer or domain as well as the user, it is critical that it is unique. Refer
to the Microsoft KnowledgeBase article 162001, "Do not disk duplicate installed versions of Windows," for
more information.
sysprep modifies the local computer SID to make it unique to each computer. The sysprep binaries are on
the Windows product CDs in the \support\tools\deploy.cab file.
The steps that you need to take to clone Windows VMs are:
10
Cloning Windows VMs
1.Create, install, and configure the Windows VM as desired.
2.Apply all relevant Service Packs and updates.
3.Install the Citrix Tools for Virtual Machines.
4.Install any applications and perform any other configuration.
5.Copy the contents of \support\tools\deploy.cab from the Windows product CD to a new
\sysprep folder in the VM.
6.Run sysprep. This will shut down the VM when it completes.
7.Using XenCenter convert the VM into a template.
8.Clone the newly created template into new VMs as required.
9.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, sysprepped 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, refer to the Microsoft TechNet page Windows System Preparation
Tool.
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 highly recommends running a reliable NTP service
in the control domain and all Windows VMs.
So if you manually set a VM to be 2 hours ahead of the control domain (e.g. using a time-zone offset within
the VM), then it will remember that. 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. Note
that changing the control domain time-zone does not affect VM time-zones or offset. It is only the hardware
clock setting which is used by XenServer to synchronize the guests.
When performing suspend/resume operations or live relocation using XenMotion, it is important to have
up-to-date Windows PV drivers installed, as they notify the Windows kernel that a time synchronization is
required after resuming (potentially on a different physical host).
Installing a VM from Reseller Option Kit (BIOS-locked) Media
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:
Installing a BIOS-locked VM
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 (i.e. the host that the media was supplied with):
11
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>
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.
Note:
When you start the VM, it will be started on the physical host from which you copied the BIOS strings.
A VM 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 host in the pool;
• without BIOS strings: immediately after its creation.
Warning:
It is your responsibility to comply with any EULAs governing the use of any BIOS-locked operating systems
that you install.
Release Notes
There are many versions and variations of Windows with different levels of support for the features provided
by XenServer. This section lists notes and errata for the known differences.
General Windows Issues
• When installing Windows VMs, start off with no more than three virtual disks. Once the VM and Citrix
Tools for Virtual Machines tools have been installed you can add additional virtual disks. The boot device
should always be one of the initial disks so that the VM can successfully boot without the Citrix Tools
for Virtual Machines.
• Multiple VCPUs are exposed as CPU sockets to Windows guests, and are subject to the licensing
limitations present in the VM. The number of CPUs present in the guest can be confirmed by checking
Device Manager. The number of CPUs actually being used by Windows can be seen in the Task Manager.
• The disk enumeration order in a Windows guest may differ from the order in which they were initially
added. This is because of interaction between the PV drivers and the PnP subsystem in Windows. For
12
Loading...
+ 40 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.