Storage

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 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 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 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.

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.

If you followed our Debian Installation section, you should already have an LVM partition, thus a physical volume:

> pvdisplay
  --- Physical volume ---
  PV Name               /dev/sda2
  VG Name               xenvg
  PV Size               464.83 GiB / not usable 0   
  Allocatable           yes 
  PE Size               4.00 MiB
  Total PE              118996
  Free PE               112322
  Allocated PE          6674
  PV UUID               4g97od-AZ1M-8sws-7ghY-YPaT-PsPR-mpO3iy

Along with a volume group:

> vgdisplay
  --- Volume group ---
  VG Name               xenvg
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  22
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                3
  Open LV               3
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               464.83 GiB
  PE Size               4.00 MiB
  Total PE              118996
  Alloc PE / Size       6674 / 26.07 GiB
  Free  PE / Size       112322 / 438.76 GiB
  VG UUID               yf4fNc-5Nke-5SCd-Jqo6-ie9c-gH7r-8dCE66

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.

> lvcreate --size 30G -n LocalStorage xenvg

To use an existing partition:

> fdisk -l

You should see your partition in a line such as:

Disk /dev/mapper/xenvg-LocalStorage: 32.2 GB, 32212254720 bytes

> xe sr-create type=ext name-label='Local Storage' device-config:device=/dev/mapper/xenvg-LocalStorage

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='Local Storage'

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

Find the UUID of the pool and storage repository:

> xe pool-list
> xe sr-list

Set the default SR

> xe pool-param-set uuid=<pool-uuid> default-SR=<sr-uuid>

1. First, you have to determine the Storage-Repository-UUID:

> xe sr-list

→ 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=your-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=your-PBD-uuid

4. Delete PBD:

> xe pbd-destroy uuid=your-PBD-uuid

5. Delete the association of your SR and the PBD:

> xe sr-forget uuid=your-SR-uuid

NOTE: at this stage the logical volume will still exist in the LVM partition.

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.