52
Note:
You can use the BRAND_CONSOLE; Repair Storage Repository function to retry the PBD creation and
plugging portions of the sr-create operation. This can be valuable in cases where the LUN zoning was
incorrect for one or more hosts in a pool when the SR was created. Correct 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