Storage Management

This page describes the backends for the storage management capabilities in libvirt.

• Directory backend
• Local filesystem backend
• Network filesystem backend
• Logical backend
• Disk backend
• iSCSI backend
• SCSI backend
• Multipath backend

Directory pool

A pool with a type of dir provides the means to manage files within a directory. The files can be fully allocated raw files, sparsely allocated raw files, or one of the special disk formats such as qcow,qcow2,vmdk, cow, etc as supported by the qemu-img program. If the directory does not exist at the time the pool is defined, the build operation can be used to create it.

Example pool input definition

      <pool type="dir">
        <name>virtimages</name>
        <target>
          <path>/var/lib/virt/images</path>
        </target>
      </pool>

Valid pool format types

The directory pool does not use the pool format type element.

Valid volume format types

One of the following options:

• raw: a plain file
• bochs: Bochs disk image format
• cloop: compressed loopback disk image format
• cow: User Mode Linux disk image format
• dmg: Mac disk image format
• iso: CDROM disk image format
• qcow: QEMU v1 disk image format
• qcow2: QEMU v2 disk image format
• vmdk: VMWare disk image format
• vpc: VirtualPC disk image format

When listing existing volumes all these formats are supported natively. When creating new volumes, only a subset may be available. The raw type is guaranteed always available. The qcow2 type can be created if either qemu-img or qcow-create tools are present. The others are dependent on support of the qemu-img tool.

Filesystem pool

This is a variant of the directory pool. Instead of creating a directory on an existing mounted filesystem though, it expects a source block device to be named. This block device will be mounted and files managed in the directory of its mount point. It will default to allowing the kernel to automatically discover the filesystem type, though it can be specified manually if required.

Example pool input

      <pool type="fs">
        <name>virtimages</name>
        <source>
          <device path="/dev/VolGroup00/VirtImages"/>
        </source>
        <target>
          <path>/var/lib/virt/images</path>
        </target>
      </pool>

Valid pool format types

The filesystem pool supports the following formats:

• auto - automatically determine format
• ext2
• ext3
• ext4
• ufs
• iso9660
• udf
• gfs
• gfs2
• vfat
• hfs+
• xfs

Valid volume format types

The valid volume types are the same as for the directory pool type.

Network filesystem pool

This is a variant of the filesystem pool. Instead of requiring a local block device as the source, it requires the name of a host and path of an exported directory. It will mount this network filesystem and manage files within the directory of its mount point. It will default to using NFS as the protocol.

Example pool input

      <pool type="netfs">
        <name>virtimages</name>
        <source>
          <host name="nfs.example.com"/>
          <dir path="/var/lib/virt/images"/>
        </source>
        <target>
          <path>/var/lib/virt/images</path>
        </target>
      </pool>

Valid pool format types

The network filesystem pool supports the following formats:

• auto - automatically determine format
• nfs

Valid volume format types

The valid volume types are the same as for the directory pool type.

Logical volume pools

This provides a pool based on an LVM volume group. For a pre-defined LVM volume group, simply providing the group name is sufficient, while to build a new group requires providing a list of source devices to serve as physical volumes. Volumes will be allocated by carving out chunks of storage from the volume group.

Example pool input

      <pool type="logical">
        <name>HostVG</name>
        <source>
          <device path="/dev/sda1"/>
          <device path="/dev/sdb1"/>
          <device path="/dev/sdc1"/>
        </source>
        <target>
          <path>/dev/HostVG</path>
        </target>
      </pool>

Valid pool format types

The logical volume pool does not use the pool format type element.

Valid volume format types

The logical volume pool does not use the volume format type element.

Disk volume pools

This provides a pool based on a physical disk. Volumes are created by adding partitions to the disk. Disk pools are have constraints on the size and placement of volumes. The 'free extents' information will detail the regions which are available for creating new volumes. A volume cannot span across 2 different free extents.

Example pool input

      <pool type="disk">
        <name>sda</name>
        <source>
          <device path='/dev/sda'/>
        </source>
        <target>
          <path>/dev</path>
        </target>
      </pool>

Valid pool format types

The disk volume pool accepts the following pool format types, representing the common partition table types:

• dos
• dvh
• gpt
• mac
• bsd
• pc98
• sun

The dos or gpt formats are recommended for best portability - the latter is needed for disks larger than 2TB.

Valid volume format types

The disk volume pool accepts the following volume format types, representing the common partition entry types:

• none
• linux
• fat16
• fat32
• linux-swap
• linux-lvm
• linux-raid
• extended

iSCSI volume pools

This provides a pool based on an iSCSI target. Volumes must be pre-allocated on the iSCSI server, and cannot be created via the libvirt APIs. Since /dev/XXX names may change each time libvirt logs into the iSCSI target, it is recommended to configure the pool to use /dev/disk/by-path or /dev/disk/by-id for the target path. These provide persistent stable naming for LUNs

Example pool input

      <pool type="iscsi">
        <name>virtimages</name>
        <source>
          <host name="iscsi.example.com"/>
          <device path="demo-target"/>
        </source>
        <target>
          <path>/dev/disk/by-path</path>
        </target>
      </pool>

Valid pool format types

The iSCSI volume pool does not use the pool format type element.

Valid volume format types

The iSCSI volume pool does not use the volume format type element.

SCSI volume pools

This provides a pool based on a SCSI HBA. Volumes are preexisting SCSI LUNs, and cannot be created via the libvirt APIs. Since /dev/XXX names aren't generally stable, it is recommended to configure the pool to use /dev/disk/by-path or /dev/disk/by-id for the target path. These provide persistent stable naming for LUNs Since 0.6.2

Example pool input

      <pool type="scsi">
        <name>virtimages</name>
        <source>
          <adapter name="host0"/>
        </source>
        <target>
          <path>/dev/disk/by-path</path>
        </target>
      </pool>

Valid pool format types

The SCSI volume pool does not use the pool format type element.

Valid volume format types

The SCSI volume pool does not use the volume format type element.

Multipath pools

This provides a pool that contains all the multipath devices on the host. Volume creating is not supported via the libvirt APIs. The target element is actually ignored, but one is required to appease the libvirt XML parser.

Configuring multipathing is not currently supported, this just covers the case where users want to discover all the available multipath devices, and assign them to guests. Since 0.7.1

Example pool input

      <pool type="mpath">
        <name>virtimages</name>
        <target>
          <path>/dev/mapper</path>
        </target>
      </pool>

Valid pool format types

The Multipath volume pool does not use the pool format type element.

Valid volume format types

The Multipath volume pool does not use the volume format type element.