Citrix Systems 6 User Manual

Page of 207
48
the zoning for the affected hosts and use the Repair Storage Repository function instead of
removing and re-creating the SR.
NFS VHD
The NFS VHD type stores disks as VHD files on a remote NFS filesystem.
NFS  is  a  ubiquitous  form  of  storage  infrastructure  that  is  available  in  many  environments.  XenServer  allows
existing NFS servers that support NFS V3 over TCP/IP to be used immediately as a storage repository for virtual
disks (VDIs). VDIs are stored in the Microsoft VHD format only. Moreover, as NFS SRs can be shared, VDIs stored
in a shared SR allow VMs to be started on any XenServer hosts in a resource pool and be migrated between them
using XenMotion with no noticeable downtime.
Creating an NFS SR requires the hostname or IP address of the NFS server. The sr-probe command provides a
list of valid destination paths exported by the server on which the SR can be created. The NFS server must be
configured to export the specified path to all XenServer hosts in the pool, or the creation of the SR and the
plugging of the PBD record will fail.
As mentioned at the beginning of this chapter, VDIs stored on NFS are sparse. The image file is allocated as the
VM writes data into the disk. This has the considerable benefit that VM image files take up only as much space
on the NFS storage as is required. If a 100GB VDI is allocated for a new VM and an OS is installed, the VDI file will
only reflect the size of the OS data that has been written to the disk rather than the entire 100GB.
VHD files may also be chained, allowing two VDIs to share common data. In cases where a NFS-based VM is
cloned, the resulting VMs will share the common on-disk data at the time of cloning. Each will proceed to make
its own changes in an isolated copy-on-write version of the VDI. This feature allows NFS-based VMs to be quickly
cloned from templates, facilitating very fast provisioning and deployment of new VMs.
Note:
The maximum supported length of VHD chains is 30.
As VHD-based images require extra metadata to support sparseness and chaining, the format is not as high-
performance as LVM-based storage. In cases where performance really matters, it is well worth forcibly allocating
the sparse regions of an image file. This will improve performance at the cost of consuming additional disk space.
XenServer's NFS and VHD implementations assume that they have full control over the SR directory on the NFS
server. Administrators should not modify the contents of the SR directory, as this can risk corrupting the contents
of VDIs.
XenServer  has  been  tuned  for  enterprise-class  storage  that  use  non-volatile  RAM  to  provide  fast
acknowledgments of write requests while maintaining a high degree of data protection from failure. XenServer
has been tested extensively against Network Appliance FAS270c and FAS3020c storage, using Data OnTap 7.2.2.
In  situations  where  XenServer  is  used  with  lower-end  storage,  it  will  cautiously  wait  for  all  writes  to  be
acknowledged before passing acknowledgments on to guest VMs. This will incur a noticeable performance cost,
and might be remedied 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, and so administrators should consider
the risks of failure carefully in these situations.
The  XenServer  NFS  implementation  uses  TCP  by  default.  If  your  situation  allows,  you  can  configure  the
implementation to use UDP in situations where there may be a performance benefit. To do this, specify the
device-config
 parameter 
useUDP=true
 at SR creation time.
Warning:
Since VDIs on NFS SRs are created as sparse, administrators must ensure that there is enough
disk space on the NFS SRs for all required VDIs. XenServer hosts do not enforce that the space
required for VDIs on NFS SRs is actually present.