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.

The following example illustrates the SR creation on a local non-shared Filesystem (ext).

If you follow the 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
...

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

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

→ 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=<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=<pbd_uuid>

4. Delete PBD:

> xe pbd-destroy uuid=<pbd_uuid>

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

> xe sr-forget uuid=<sr_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!

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.