HP BL680c XenServer Administrator's Guide 4.1.0 - Page 17

Storage

Get HP BL680c - ProLiant - G5 PDF manuals and user guides
UPC - 884420396314
View all HP BL680c manuals
Add to My Manuals
Save this manual to your list of manuals

Page 17 highlights

Chapter 3. Storage This chapter discusses the framework for storage abstractions. It describes the way physical storage hardware of various kinds is mapped to VMs, and the software objects used by the XenServer Host API to perform storage-related tasks. Detailed sections on each of the supported storage types include procedures for creating storage for VMs using the CLI, with type-specific device configuration options, and some best practices for managing storage in XenServer Host environments. Finally, the virtual disk QoS (quality of service) settings available to XenServer Host Enterprise Edition are described. 3.1. Overview 3.1.1. Storage repositories (SRs) XenServer Host defines a container called a storage repository (SR) to describe a particular storage target, in which Virtual Disk Images (VDIs) are stored. A VDI is a disk abstraction which contains the contents of a virtual disk. The interface to storage hardware allows VDIs to be supported on a large number of SR types. With built-in support for IDE, SATA, SCSI and SAS drives locally connected, and iSCSI, NFS and Fibre Channel remotely connected, the XenServer Host SR is very flexible. The SR and VDI abstractions allows advanced storage features such as sparse provisioning, VDI snapshots, and fast cloning to be exposed on storage targets that support them. For storage subsystems that do not inherently support advanced operations directly, a software stack is provided based on Microsoft's Virtual Hard Disk (VHD) specification which implements these features. Each XenServer Host host can use multiple SRs and different SR types simultaneously. These SRs can be shared, or dedicated between hosts. As mentioned previously in Chapter 2, XenServer Hosts and resource pools, shared storage is pooled between multiple hosts within a defined resource pool. A Shared SR must be network accessible to each host, and thus must be an iSCSI, NFS, NetApp or Fibre Channel SR. Finally, all hosts in a single resource pool must have at least one shared SR in common. 3.1.2. Virtual Disk Images (VDI) There are three basic VDI types, VHD, Logical Volume Manager (LVM) and Netapp managed LUNs. Both VHD and LVM types can exist on local dedicated storage or remote shared storage. Netapp storage types must reside on a Network Appliance filer running version 7.0 or greater of Ontap. • The VHD format can be used on either a local disk with an ext3 filesystem or on an NFS share. VDIs stored in VHD format 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 physical storage as required. If a 100GB VDI is allocated for a new VM and an OS is installed, the VDI file will physically be only the size of the OS data that has been written to the disk, plus some minor metadata overhead. VHD files may also be chained, allowing two VDIs to share common data. In cases where a VHD-backed VM is cloned, the resulting VMs share the common on-disk data at the time of cloning. Each proceeds to make its own changes in an isolated copy-on-write version of the VDI. This feature allows VHD-based VMs to be quickly cloned from templates, facilitating very fast provisioning and deployment of new VMs. Since VHD-based images involve extra metadata to provide 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. 11

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
11
Chapter 3. Storage
This chapter discusses the framework for storage abstractions. It describes the way physical storage hard-
ware of various kinds is mapped to VMs, and the software objects used by the XenServer Host API to per-
form storage-related tasks. Detailed sections on each of the supported storage types include procedures
for creating storage for VMs using the CLI, with type-specific device configuration options, and some best
practices for managing storage in XenServer Host environments. Finally, the virtual disk QoS (quality of
service) settings available to XenServer Host Enterprise Edition are described.
3.1. Overview
3.1.1. Storage repositories (SRs)
XenServer Host defines a container called a storage repository (SR) to describe a particular storage target,
in which Virtual Disk Images (VDIs) are stored. A VDI is a disk abstraction which contains the contents of
a virtual disk.
The interface to storage hardware allows VDIs to be supported on a large number of SR types. With built-in
support for IDE, SATA, SCSI and SAS drives locally connected, and iSCSI, NFS and Fibre Channel remotely
connected, the XenServer Host SR is very flexible. The SR and VDI abstractions allows advanced storage
features such as sparse provisioning, VDI snapshots, and fast cloning to be exposed on storage targets
that support them. For storage subsystems that do not inherently support advanced operations directly, a
software stack is provided based on Microsoft's Virtual Hard Disk (VHD) specification which implements
these features.
Each XenServer Host host can use multiple SRs and different SR types simultaneously. These SRs can be
shared, or dedicated between hosts. As mentioned previously in Chapter 2,
XenServer Hosts and resource
pools
, shared storage is pooled between multiple hosts within a defined resource pool. A Shared SR must
be network accessible to each host, and thus must be an iSCSI, NFS, NetApp or Fibre Channel SR. Finally,
all hosts in a single resource pool must have at least one shared SR in common.
3.1.2. Virtual Disk Images (VDI)
There are three basic VDI types, VHD, Logical Volume Manager (LVM) and Netapp managed LUNs. Both
VHD and LVM types can exist on local dedicated storage or remote shared storage. Netapp storage types
must reside on a Network Appliance filer running version 7.0 or greater of Ontap.
•
The VHD format can be used on either a local disk with an ext3 filesystem or on an NFS share. VDIs
stored in VHD format 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 physical storage as
required. If a 100GB VDI is allocated for a new VM and an OS is installed, the VDI file will physically be
only the size of the OS data that has been written to the disk, plus some minor metadata overhead.
VHD files may also be chained, allowing two VDIs to share common data. In cases where a VHD-backed
VM is cloned, the resulting VMs share the common on-disk data at the time of cloning. Each proceeds
to make its own changes in an isolated copy-on-write version of the VDI. This feature allows VHD-based
VMs to be quickly cloned from templates, facilitating very fast provisioning and deployment of new VMs.
Since VHD-based images involve extra metadata to provide 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 con-
suming additional disk space.