NFS SRs
Shares on NFS servers (that support any version of NFSv4 or NFSv3) can be used immediately as an SR for virtual disks. VDIs are stored in the Microsoft VHD format only. Also, as these SRs can be shared, VDIs stored on shared SRs allow:
-
VMs to be started on any XenServer® hosts in a resource pool
-
VMs migrate between XenServer hosts in a resource pool using live migration (without noticeable downtime)
Important:
- For NFSv4, only the authentication type
AUTH_SYSis supported.- It is highly recommended for both NFS storage that a dedicated storage network be used, using at least two bonded links, ideally to independent network switches with redundant power supplies.
VDIs stored on file-based SRs are thinly provisioned. The image file is allocated as the VM writes data into the disk. This approach has the considerable benefit that the VM image files take up only as much space on the storage as is required. For example, if a 100 GB VDI is allocated for a VM and an OS is installed, the VDI file only reflects the size of the OS data written to the disk rather than the entire 100 GB.
VHD files can also be chained, allowing two VDIs to share common data. In cases where a file-based VM is cloned, the resulting VMs share the common on-disk data at the time of cloning. Each VM proceeds to make its own changes in an isolated copy-on-write version of the VDI. This feature allows file-based VMs to be quickly cloned from templates, facilitating fast provisioning and deployment of new VMs. The maximum supported length of VHD chains is 30.
File-based SRs and VHD implementations in XenServer assume that they have full control over the SR directory on the file server. Administrators must not modify the contents of the SR directory, as this action can risk corrupting the contents of VDIs.
XenServer has been tuned for enterprise-class storage that uses non-volatile RAM to provide fast acknowledgments of write requests while maintaining a high degree of data protection from failure.
Warning:
As VDIs on file-based SRs are created as thin-provisioned VDIs, administrators must ensure that the file-based SRs have enough disk space for all required VDIs. XenServer hosts do not enforce that the space required for VDIs on file-based SRs is present.
Ensure that you monitor the free space on your SR. If the SR usage grows to 100%, further writes from VMs fail. These failed writes can cause the VM to freeze or crash.
The following device-config parameters are used with NFS SRs:
| Parameter Name | Description | Required? |
|---|---|---|
server |
IP address or host name of the NFS server | Yes |
serverpath |
Path, including the NFS mount point, to the NFS server that hosts the SR | Yes |
nfsversion |
Specifies the version of NFS to use. If you specify nfsversion="4", the SR uses NFS v4.0, v4.1 or v4.2, depending on what is available. If you want to select a more specific version of NFS, you can specify nfsversion="4.0" and so on. Only one value can be specified for nfsversion. |
No |
useUDP |
Configure the SR to use UDP rather than the default TCP. | No |
Create a shared NFS SR (NFS)
Note:
If you attempt to attach a read-only NFS SR, this action fails with the following error message: “SR_BACKEND_FAILURE_461 - The file system for SR cannot be written to.”
To create an NFS SR, you must provide the host name or IP address of the NFS server. You can create the SR on any valid destination path; use the sr-probe command to display a list of valid destination paths exported by the server.
In scenarios where XenServer is used with lower-end storage, it cautiously waits for all writes to be acknowledged before passing acknowledgments on to VMs. This approach incurs a noticeable performance cost, and might be solved by setting the storage to present the SR mount point as an asynchronous mode export. Asynchronous exports acknowledge writes that are not actually on disk. Consider the risks of failure carefully in these situations.
Note:
The NFS server must be configured to export the specified path to all hosts in the pool. If this configuration is not done, the creation of the SR and the plugging of the PBD record fails.
The XenServer NFS implementation uses TCP by default. If your situation allows, you can configure the implementation to use UDP in scenarios where there might be a performance benefit. To do this configuration, when creating an SR, specify the device-config parameter useUDP=true.
If you are creating an SR for IP-based storage (including NFS), you can configure one of the following as the storage network: the NIC that handles the management traffic or a new NIC for the storage traffic. To assign an IP address to a NIC, see Configure a dedicated storage NIC.
xe CLI
For example, to create a shared NFS SR on 192.168.1.10:/export1, using any version 4 of NFS that is made available by the filer, use the following command:
xe sr-create content-type=user \
name-label="shared NFS SR" shared=true \
device-config:server=192.168.1.10 device-config:serverpath=/export1 type=nfs \
device-config:nfsversion="4"
<!--NeedCopy-->
To create a non-shared NFS SR on 192.168.1.10:/export1, using specifically NFS version 4.0, run the following command:
xe sr-create host-uuid=host_uuid content-type=user \
name-label="Non-shared NFS SR" \
device-config:server=192.168.1.10 device-config:serverpath=/export1 type=nfs \
device-config:nfsversion="4.0"
<!--NeedCopy-->
In XenCenter®
- Open the New Storage Repository wizard: click New Storage on the toolbar.
- Select NFS as the physical storage type, then click Next.
- On the Name page, enter the name of the new SR. By default, the wizard generates a description of the SR. This description includes a summary of the configuration options that you select as you progress through the wizard. To enter your own description, clear the Auto-generate description based on SR settings check box and type in the Description box. Click Next to continue.
- On the Location page, specify the NFS storage target details:
- Share Name The IP address or DNS name of the server and the path. For example, server:/path where server is the DNS name or IP address of the server computer, and path is the directory used to contain the SR. The NFS server must be configured to export the specified path to all servers in the pool.
- Advanced Options You can enter any additional configuration options here.
-
NFS Version Select the NFS version used by the SR.
Note:
If the underlying storage array does not support NFSv4, NFSv3 is used to mount the share.
- Click Scan to have the wizard scan for existing NFS SRs in the location you specified.
- The New Storage Repository wizard lists any existing SRs which are not already attached. You can select an SR from the list and attach it as the new storage repository. click Reattach an existing SR and select the SR from the list, then click Finish.
- If no existing SRs are found, simply click Finish to complete the new SR configuration and close the wizard.