Citrix Systems 5.6 Manual Do Utilizador

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.

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