====== Storage ======
----
===== Terminology =====
----
==== Storage Repositories (SR) ====
----
Xen 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. The Xen Cloud Platform SR has built-in support for IDE, SATA, SCSI and SAS drives locally connected, and iSCSI, NFS, SAS and Fibre Channel remotely connected. The SR and VDI abstractions allow 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 Xen Cloud Platform host can use multiple SRs and different SR types simultaneously. These SRs can be shared between hosts or dedicated to particular hosts. Shared storage is pooled between multiple hosts within a defined resource pool. A shared SR must be network accessible to each host. All hosts in a single resource pool must have at least one shared SR in common.
----
==== Virtual Disk Images (VDI) ====
----
Virtual Disk Images are a storage abstraction that is presented to a VM. VDIs are the fundamental unit of virtualized storage in Xen Cloud Platform. Similar to SRs, VDIs are persistent, on-disk objects that exist independently of Xen Cloud Platform hosts.
The actual on-disk representation of the data differs by the SR type and is managed by a separate storage plugin interface for each SR, called the SM API.
----
==== Physical Block Devices (PBD) ====
----
Physical Block Devices represent the interface between a physical server and an attached SR. PBDs are connector objects that allow a given SR to be mapped to a Xen Cloud Platform host. PBDs store the device configuration fields that are used to connect to and interact with a given storage target. For example, NFS device configuration includes the IP address of the NFS server and the associated path that the Xen Cloud Platform host mounts. PBD objects manage the run-time attachment of a given SR to a given Xen Cloud Platform host.
----
==== Virtual Block Devices (VBD) ====
----
Virtual Block Devices are connector objects (similar to the PBD described above) that allows mappings between VDIs and VMs. In addition to providing a mechanism for attaching (also called plugging) a VDI into a VM, VBDs allow for the fine-tuning of parameters regarding QoS (quality of service), statistics, and the bootability of a given VDI.
----
==== Xen Storage Objects ====
----
{{ :hypervisor:toolstack:xen-storage.png?direct&200 }}
----
==== Virtual Disk Data Formats ====
----
There are three main types of mapping of physical storage to a VDI:
* **File-based VHD on a Filesystem**; VM images are stored as thin-provisioned VHD format files on either a local non-shared Filesystem (EXT type SR) or a shared NFS target (NFS type SR)
* **Logical Volume-based VHD on a LUN**; The default XenServer blockdevice-based storage inserts a Logical Volume manager on a disk, either a locally attached device (LVM type SR) or a SAN attached LUN over either Fibre Channel (LVMoHBA type SR), iSCSI (LVMoISCSI type SR) or SAS (LVMoHBA type Sr). VDIs are represented as volumes within the Volume manager and stored in VHD format to allow thin provisioning of reference nodes on snapshot and clone.
* **LUN per VDI**; LUNs are directly mapped to VMs as VDIs by SR types that provide an array-specific plugin (Netapp, Equallogic or StorageLink type SRs). The array storage abstraction therefore matches the VDI storage abstraction for environments that manage storage provisioning at an array level.
----
===== Create a Storage Repository =====
----
The following example illustrates the SR creation on a local non-shared Filesystem (ext).
If you follow the [[sample:base|Sample Configuration]] section of this wiki, you will have a LVM partition, thus a physical volume to use:
> sudo pvdisplay
--- Physical volume ---
PV Name /dev/sde5
VG Name Xvg0
PV Size 12.82 GiB / not usable 3.00 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 3282
Free PE 5
Allocated PE 3277
PV UUID sJOaJc-vZzX-1d8O-2R5i-jmi5-Gkj4-S4rxdJ
Along with a volume group:
> sudo vgdisplay
--- Volume group ---
VG Name Xvg0
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 7
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 1
Max PV 0
Cur PV 1
Act PV 1
VG Size 12.82 GiB
PE Size 4.00 MiB
Total PE 3282
Alloc PE / Size 3277 / 12.80 GiB
Free PE / Size 5 / 20.00 MiB
VG UUID Skt7yP-fl4B-IxvG-VUA4-KcJH-1Mho-2QASh8
In case you don't please setup a physical volume with an LVM partition, and a volume group. Explanations on how to achieve this is outside the scope of this document but you can already refer to [[https://7terminals.com/articles/step-by-step-guide-to-setting-up-xen-and-xenapi-xcp-on-ubuntu-12-04-and-managing-it-with-xencenter/]] for a start.
If you do not already have a device to use as repository, create a logical volume on volume group.
> sudo lvcreate --size 13G -n Xsr0 Xvg0
To use an existing partition:
> fdisk -l
You should see your partition in a line such as:
...
Disk /dev/mapper/Xvg0-Xsr0: 13.7 GB, 13744734208 bytes
...
==== Register the logical volume for use with XAPI ====
> xe sr-create type=ext name-label='X-Local-SR' device-config:device=/dev/mapper/Xvg0-Xsr0
This will take a while if the volume is large, it will return the SR UUID.
Display the storage repository:
> xe sr-list name-label='X-Local-SR'
===== Configure an ISO Repository for Use With XAPI =====
An ISO Repository contains ISOs (disk images) with operational systems to perform the installations.\\
The following example makes a storage repository called LocalISOs:
> [sudo] mkdir -p /var/opt/xen/LocalISORepository/
> xe sr-create name-label=LocalISORepository type=iso shared=true device-config:location=/var/opt/xen/LocalISORepository/ device-config:legacy_mode=true content-type=iso
This should display the ISO Repository:
> xe sr-list name-label=LocalISORepository
uuid ( RO) : bc1e7543-add5-cfdc-60ab-915d887c15e5
name-label ( RW): Local ISO Repository
name-description ( RW):
host ( RO): h150-vhyper
type ( RO): iso
content-type ( RO): iso
To scan the repository for newly added iso:
> xe sr-scan uuid=d8ce6a0a-57e0-efb5-42d7-1c2a8db8dc9a
===== Setting Default SR =====
Find the UUID of the pool and storage repository:
> xe pool-list
> xe sr-list
Set the default SR
> xe pool-param-set uuid= default-SR=
===== Delete a Storage Repository =====
1. First, you have to determine the Storage-Repository-UUID:
> xe sr-list
-> Copy / write down / take note of SR-UUID of the SR to delete
2. Find the corresponding Physical Block Device (PBD):
> xe pbd-list sr-uuid=
-> Copy / write down / take note of PBD-UUID of the PBD to unplug and delete
3. Unplug the PBD:
> xe pbd-unplug uuid=
4. Delete PBD:
> xe pbd-destroy uuid=
5. Delete the association of your SR and the PBD:
> xe sr-forget uuid=
NOTE: at this stage the SR data will still exist in the LVM partition, you could also use the //**xe sr-destroy**// command to totally wipe out the SR, loosing everything that was on it!
===== Using NFS =====
NFS servers are a common form of shared filesystem infrastructure, and can be used as a storage repository substrate for virtual disks. As NFS storage repositories are shared, the virtual disks stored in them allow VMs to be started on any server in a resource pool and to be migrated between them using XenMotion. When you configure an NFS storage repository, you simply provide the hostname or IP address of the NFS server and the path to a directory that will be used to contain the storage repository (if this resource is on another machine, it is not our case). The NFS server must be configured to export the specified path to all servers in the pool.