Filter
Top Products
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.