storage.html.in 26.9 KB
Newer Older
1 2 3
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
4 5 6
  <body>
    <h1 >Storage Management</h1>
    <p>
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
      Libvirt provides storage management on the physical host through
      storage pools and volumes.
    </p>
    <p>
      A storage pool is a quantity of storage set aside by an
      administrator, often a dedicated storage administrator, for use
      by virtual machines.  Storage pools are divided into storage
      volumes either by the storage administrator or the system
      administrator, and the volumes are assigned to VMs as block
      devices.
    </p>
    <p>
      For example, the storage administrator responsible for an NFS
      server creates a share to store virtual machines' data.  The
      system administrator defines a pool on the virtualization host
      with the details of the share
      (e.g. nfs.example.com:/path/to/share should be mounted on
      /vm_data).  When the pool is started, libvirt mounts the share
      on the specified directory, just as if the system administrator
      logged in and executed 'mount nfs.example.com:/path/to/share
      /vmdata'.  If the pool is configured to autostart, libvirt
      ensures that the NFS share is mounted on the directory specified
      when libvirt is started.
    </p>
    <p>
      Once the pool is started, the files in the NFS share are
      reported as volumes, and the storage volumes' paths may be
      queried using the libvirt APIs.  The volumes' paths can then be
      copied into the section of a VM's XML definition describing the
      source storage for the VM's block devices.  In the case of NFS,
      an application using the libvirt APIs can create and delete
      volumes in the pool (files in the NFS share) up to the limit of
      the size of the pool (the storage capacity of the share).  Not
      all pool types support creating and deleting volumes.  Stopping
      the pool (somewhat unfortunately referred to by virsh and the
      API as "pool-destroy") undoes the start operation, in this case,
      unmounting the NFS share.  The data on the share is not modified
      by the destroy operation, despite the name.  See man virsh for
      more details.
    </p>
    <p>
      A second example is an iSCSI pool.  A storage administrator
      provisions an iSCSI target to present a set of LUNs to the host
      running the VMs.  When libvirt is configured to manage that
      iSCSI target as a pool, libvirt will ensure that the host logs
      into the iSCSI target and libvirt can then report the available
      LUNs as storage volumes.  The volumes' paths can be queried and
      used in VM's XML definitions as in the NFS example.  In this
      case, the LUNs are defined on the iSCSI server, and libvirt
      cannot create and delete volumes.
    </p>
    <p>
      Storage pools and volumes are not required for the proper
      operation of VMs.  Pools and volumes provide a way for libvirt
      to ensure that a particular piece of storage will be available
      for a VM, but some administrators will prefer to manage their
      own storage and VMs will operate properly without any pools or
      volumes defined.  On systems that do not use pools, system
      administrators must ensure the availability of the VMs' storage
      using whatever tools they prefer, for example, adding the NFS
      share to the host's fstab so that the share is mounted at boot
      time.
    </p>
    <p>
      If at this point the value of pools and volumes over traditional
      system administration tools is unclear, note that one of the
      features of libvirt is its remote protocol, so it's possible to
      manage all aspects of a virtual machine's lifecycle as well as
      the configuration of the resources required by the VM.  These
      operations can be performed on a remote host entirely within the
      libvirt API.  In other words, a management application using
      libvirt can enable a user to perform all the required tasks for
      configuring the host for a VM: allocating resources, running the
      VM, shutting it down and deallocating the resources, without
      requiring shell access or any other control channel.
    </p>
    <p>
      Libvirt supports the following storage pool types:
    </p>
86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104
    <ul>
      <li>
        <a href="#StorageBackendDir">Directory backend</a>
      </li>
      <li>
        <a href="#StorageBackendFS">Local filesystem backend</a>
      </li>
      <li>
        <a href="#StorageBackendNetFS">Network filesystem backend</a>
      </li>
      <li>
        <a href="#StorageBackendLogical">Logical backend</a>
      </li>
      <li>
        <a href="#StorageBackendDisk">Disk backend</a>
      </li>
      <li>
        <a href="#StorageBackendISCSI">iSCSI backend</a>
      </li>
105 106 107
      <li>
        <a href="#StorageBackendSCSI">SCSI backend</a>
      </li>
108 109 110
      <li>
        <a href="#StorageBackendMultipath">Multipath backend</a>
      </li>
111 112 113
      <li>
        <a href="#StorageBackendRBD">RBD (RADOS Block Device) backend</a>
      </li>
114 115 116
      <li>
        <a href="#StorageBackendSheepdog">Sheepdog backend</a>
      </li>
E
Eric Blake 已提交
117 118 119
      <li>
        <a href="#StorageBackendGluster">Gluster backend</a>
      </li>
R
Roman Bogorodskiy 已提交
120 121 122
      <li>
        <a href="#StorageBackendZFS">ZFS backend</a>
      </li>
123 124
    </ul>

125
    <h2><a name="StorageBackendDir">Directory pool</a></h2>
126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142
    <p>
      A pool with a type of <code>dir</code> 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 <code>qcow</code>,<code>qcow2</code>,<code>vmdk</code>,
      <code>cow</code>, etc as supported  by the <code>qemu-img</code>
      program. If the directory does not exist at the time the pool is
      defined, the <code>build</code> operation can be used to create it.
    </p>

    <h3>Example pool input definition</h3>
    <pre>
      &lt;pool type="dir"&gt;
        &lt;name&gt;virtimages&lt;/name&gt;
        &lt;target&gt;
          &lt;path&gt;/var/lib/virt/images&lt;/path&gt;
        &lt;/target&gt;
143
      &lt;/pool&gt;</pre>
144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162

    <h3>Valid pool format types</h3>
    <p>
      The directory pool does not use the pool format type element.
    </p>

    <h3>Valid volume format types</h3>
    <p>
      One of the following options:
    </p>
    <ul>
      <li><code>raw</code>: a plain file</li>
      <li><code>bochs</code>: Bochs disk image format</li>
      <li><code>cloop</code>: compressed loopback disk image format</li>
      <li><code>cow</code>: User Mode Linux disk image format</li>
      <li><code>dmg</code>: Mac disk image format</li>
      <li><code>iso</code>: CDROM disk image format</li>
      <li><code>qcow</code>: QEMU v1 disk image format</li>
      <li><code>qcow2</code>: QEMU v2 disk image format</li>
163
      <li><code>qed</code>: QEMU Enhanced Disk image format</li>
164 165 166 167 168 169 170 171 172 173 174 175 176 177
      <li><code>vmdk</code>: VMWare disk image format</li>
      <li><code>vpc</code>: VirtualPC disk image format</li>
    </ul>
    <p>
      When listing existing volumes all these formats are supported
      natively. When creating new volumes, only a subset may be
      available. The <code>raw</code> type is guaranteed always
      available. The <code>qcow2</code> type can be created if
      either <code>qemu-img</code> or <code>qcow-create</code> tools
      are present. The others are dependent on support of the
      <code>qemu-img</code> tool.

    </p>

178
    <h2><a name="StorageBackendFS">Filesystem pool</a></h2>
179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198
    <p>
      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.
    </p>

    <h3>Example pool input</h3>
    <pre>
      &lt;pool type="fs"&gt;
        &lt;name&gt;virtimages&lt;/name&gt;
        &lt;source&gt;
          &lt;device path="/dev/VolGroup00/VirtImages"/&gt;
        &lt;/source&gt;
        &lt;target&gt;
          &lt;path&gt;/var/lib/virt/images&lt;/path&gt;
        &lt;/target&gt;
199
      &lt;/pool&gt;</pre>
200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239

    <h3>Valid pool format types</h3>
    <p>
      The filesystem pool supports the following formats:
    </p>
    <ul>
      <li><code>auto</code> - automatically determine format</li>
      <li>
        <code>ext2</code>
      </li>
      <li>
        <code>ext3</code>
      </li>
      <li>
        <code>ext4</code>
      </li>
      <li>
        <code>ufs</code>
      </li>
      <li>
        <code>iso9660</code>
      </li>
      <li>
        <code>udf</code>
      </li>
      <li>
        <code>gfs</code>
      </li>
      <li>
        <code>gfs2</code>
      </li>
      <li>
        <code>vfat</code>
      </li>
      <li>
        <code>hfs+</code>
      </li>
      <li>
        <code>xfs</code>
      </li>
240 241 242
      <li>
        <code>ocfs2</code>
      </li>
243 244 245 246 247 248 249 250 251
    </ul>

    <h3>Valid volume format types</h3>
    <p>
      The valid volume types are the same as for the <code>directory</code>
      pool type.
    </p>


252
    <h2><a name="StorageBackendNetFS">Network filesystem pool</a></h2>
253 254 255 256 257
    <p>
      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
258 259
      point. It will default to using <code>auto</code> as the
      protocol, which generally tries a mount via NFS first.
260 261 262 263 264 265 266 267 268
    </p>

    <h3>Example pool input</h3>
    <pre>
      &lt;pool type="netfs"&gt;
        &lt;name&gt;virtimages&lt;/name&gt;
        &lt;source&gt;
          &lt;host name="nfs.example.com"/&gt;
          &lt;dir path="/var/lib/virt/images"/&gt;
269
          &lt;format type='nfs'/&gt;
270 271 272 273
        &lt;/source&gt;
        &lt;target&gt;
          &lt;path&gt;/var/lib/virt/images&lt;/path&gt;
        &lt;/target&gt;
274
      &lt;/pool&gt;</pre>
275 276 277 278 279 280 281 282 283 284

    <h3>Valid pool format types</h3>
    <p>
      The network filesystem pool supports the following formats:
    </p>
    <ul>
      <li><code>auto</code> - automatically determine format</li>
      <li>
        <code>nfs</code>
      </li>
285
      <li>
286 287 288
        <code>glusterfs</code> - use the glusterfs FUSE file system.
        For now, the <code>dir</code> specified as the source can only
        be a gluster volume name, as gluster does not provide a way to
E
Eric Blake 已提交
289 290 291
        directly mount subdirectories within a volume.  (To bypass the
        file system completely, see
        the <a href="#StorageBackendGluster">gluster</a> pool.)
292 293
      </li>
      <li>
294
        <code>cifs</code> - use the SMB (samba) or CIFS file system
295
      </li>
296 297 298 299 300 301 302 303 304
    </ul>

    <h3>Valid volume format types</h3>
    <p>
      The valid volume types are the same as for the <code>directory</code>
      pool type.
    </p>


305
    <h2><a name="StorageBackendLogical">Logical volume pools</a></h2>
306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326
    <p>
      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.
    </p>

    <h3>Example pool input</h3>
    <pre>
      &lt;pool type="logical"&gt;
        &lt;name&gt;HostVG&lt;/name&gt;
        &lt;source&gt;
          &lt;device path="/dev/sda1"/&gt;
          &lt;device path="/dev/sdb1"/&gt;
          &lt;device path="/dev/sdc1"/&gt;
        &lt;/source&gt;
        &lt;target&gt;
          &lt;path&gt;/dev/HostVG&lt;/path&gt;
        &lt;/target&gt;
327
      &lt;/pool&gt;</pre>
328 329 330

    <h3>Valid pool format types</h3>
    <p>
331
      The logical volume pool supports the following formats:
332
    </p>
333 334 335 336 337 338
    <ul>
      <li><code>auto</code> - automatically determine format</li>
      <li>
        <code>lvm2</code>
      </li>
    </ul>
339 340 341 342 343 344 345

    <h3>Valid volume format types</h3>
    <p>
      The logical volume pool does not use the volume format type element.
    </p>


346
    <h2><a name="StorageBackendDisk">Disk volume pools</a></h2>
347 348
    <p>
      This provides a pool based on a physical disk. Volumes are created
P
Philipp Hahn 已提交
349
      by adding partitions to the disk. Disk pools have constraints
350 351 352 353 354 355 356 357 358 359 360 361 362 363 364
      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.
    </p>

    <h3>Example pool input</h3>
    <pre>
      &lt;pool type="disk"&gt;
        &lt;name&gt;sda&lt;/name&gt;
        &lt;source&gt;
          &lt;device path='/dev/sda'/&gt;
        &lt;/source&gt;
        &lt;target&gt;
          &lt;path&gt;/dev&lt;/path&gt;
        &lt;/target&gt;
365
      &lt;/pool&gt;</pre>
366 367 368 369 370 371 372 373

    <h3>Valid pool format types</h3>
    <p>
      The disk volume pool accepts the following pool format types, representing
      the common partition table types:
    </p>
    <ul>
      <li>
374
        <code>dos</code>
375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393
      </li>
      <li>
        <code>dvh</code>
      </li>
      <li>
        <code>gpt</code>
      </li>
      <li>
        <code>mac</code>
      </li>
      <li>
        <code>bsd</code>
      </li>
      <li>
        <code>pc98</code>
      </li>
      <li>
        <code>sun</code>
      </li>
394 395 396
      <li>
        <code>lvm2</code>
      </li>
397 398
    </ul>
    <p>
399
      The <code>dos</code> or <code>gpt</code> formats are recommended for
400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435
      best portability - the latter is needed for disks larger than 2TB.
    </p>

    <h3>Valid volume format types</h3>
    <p>
      The disk volume pool accepts the following volume format types, representing
      the common partition entry types:
    </p>
    <ul>
      <li>
        <code>none</code>
      </li>
      <li>
        <code>linux</code>
      </li>
      <li>
        <code>fat16</code>
      </li>
      <li>
        <code>fat32</code>
      </li>
      <li>
        <code>linux-swap</code>
      </li>
      <li>
        <code>linux-lvm</code>
      </li>
      <li>
        <code>linux-raid</code>
      </li>
      <li>
        <code>extended</code>
      </li>
    </ul>


436
    <h2><a name="StorageBackendISCSI">iSCSI volume pools</a></h2>
437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456
    <p>
      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 <code>/dev/disk/by-path</code> or <code>/dev/disk/by-id</code>
      for the target path. These provide persistent stable naming for LUNs
    </p>

    <h3>Example pool input</h3>
    <pre>
      &lt;pool type="iscsi"&gt;
        &lt;name&gt;virtimages&lt;/name&gt;
        &lt;source&gt;
          &lt;host name="iscsi.example.com"/&gt;
          &lt;device path="demo-target"/&gt;
        &lt;/source&gt;
        &lt;target&gt;
          &lt;path&gt;/dev/disk/by-path&lt;/path&gt;
        &lt;/target&gt;
457
      &lt;/pool&gt;</pre>
458 459 460

    <h3>Valid pool format types</h3>
    <p>
461
      The iSCSI volume pool does not use the pool format type element.
462 463 464 465
    </p>

    <h3>Valid volume format types</h3>
    <p>
466
      The iSCSI volume pool does not use the volume format type element.
467
    </p>
468

469
    <h2><a name="StorageBackendSCSI">SCSI volume pools</a></h2>
470 471 472 473 474 475
    <p>
      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 <code>/dev/disk/by-path</code> or <code>/dev/disk/by-id</code>
      for the target path. These provide persistent stable naming for LUNs
476
      <span class="since">Since 0.6.2</span>
477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500
    </p>

    <h3>Example pool input</h3>
    <pre>
      &lt;pool type="scsi"&gt;
        &lt;name&gt;virtimages&lt;/name&gt;
        &lt;source&gt;
          &lt;adapter name="host0"/&gt;
        &lt;/source&gt;
        &lt;target&gt;
          &lt;path&gt;/dev/disk/by-path&lt;/path&gt;
        &lt;/target&gt;
      &lt;/pool&gt;</pre>

    <h3>Valid pool format types</h3>
    <p>
      The SCSI volume pool does not use the pool format type element.
    </p>

    <h3>Valid volume format types</h3>
    <p>
      The SCSI volume pool does not use the volume format type element.
    </p>

501
    <h2><a name="StorageBackendMultipath">Multipath pools</a></h2>
502 503 504 505 506 507 508 509 510
    <p>
      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.<br/>
      <br/>
      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.
511
      <span class="since">Since 0.7.1</span>
512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532
    </p>

    <h3>Example pool input</h3>
    <pre>
      &lt;pool type="mpath"&gt;
        &lt;name&gt;virtimages&lt;/name&gt;
        &lt;target&gt;
          &lt;path&gt;/dev/mapper&lt;/path&gt;
        &lt;/target&gt;
      &lt;/pool&gt;</pre>

    <h3>Valid pool format types</h3>
    <p>
      The Multipath volume pool does not use the pool format type element.
    </p>

    <h3>Valid volume format types</h3>
    <p>
      The Multipath volume pool does not use the volume format type element.
    </p>

533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586
    <h2><a name="StorageBackendRBD">RBD pools</a></h2>
    <p>
      This storage driver provides a pool which contains all RBD
      images in a RADOS pool.  RBD (RADOS Block Device) is part
      of the Ceph distributed storage project.<br/>
      This backend <i>only</i> supports Qemu with RBD support. Kernel RBD
      which exposes RBD devices as block devices in /dev is <i>not</i>
      supported. RBD images created with this storage backend
      can be accessed through kernel RBD if configured manually, but
      this backend does not provide mapping for these images.<br/>
      Images created with this backend can be attached to Qemu guests
      when Qemu is build with RBD support (Since Qemu 0.14.0). The
      backend supports cephx authentication for communication with the
      Ceph cluster. Storing the cephx authentication key is done with
      the libvirt secret mechanism. The UUID in the example pool input
      refers to the UUID of the stored secret.
      <span class="since">Since 0.9.13</span>
    </p>

    <h3>Example pool input</h3>
    <pre>
      &lt;pool type="rbd"&gt;
        &lt;name&gt;myrbdpool&lt;/name&gt;
        &lt;source&gt;
          &lt;name&gt;rbdpool&lt;/name&gt;
            &lt;host name='1.2.3.4' port='6789'/&gt;
            &lt;host name='my.ceph.monitor' port='6789'/&gt;
            &lt;host name='third.ceph.monitor' port='6789'/&gt;
            &lt;auth username='admin' type='ceph'&gt;
              &lt;secret uuid='2ec115d7-3a88-3ceb-bc12-0ac909a6fd87'/&gt;
            &lt;/auth&gt;
        &lt;/source&gt;
      &lt;/pool&gt;</pre>

    <h3>Example volume output</h3>
    <pre>
       &lt;volume&gt;
         &lt;name&gt;myvol&lt;/name&gt;
         &lt;key&gt;rbd/myvol&lt;/key&gt;
         &lt;source&gt;
         &lt;/source&gt;
         &lt;capacity unit='bytes'&gt;53687091200&lt;/capacity&gt;
         &lt;allocation unit='bytes'&gt;53687091200&lt;/allocation&gt;
         &lt;target&gt;
           &lt;path&gt;rbd:rbd/myvol&lt;/path&gt;
           &lt;format type='unknown'/&gt;
           &lt;permissions&gt;
             &lt;mode&gt;00&lt;/mode&gt;
             &lt;owner&gt;0&lt;/owner&gt;
             &lt;group&gt;0&lt;/group&gt;
           &lt;/permissions&gt;
         &lt;/target&gt;
       &lt;/volume&gt;</pre>

N
Nehal J Wani 已提交
587
    <h3>Example disk attachment</h3>
588 589 590 591 592 593 594 595 596 597 598 599 600 601 602
    <p>RBD images can be attached to Qemu guests when Qemu is built
    with RBD support. Information about attaching a RBD image to a
    guest can be found
    at <a href="formatdomain.html#elementsDisks">format domain</a>
    page.</p>

    <h3>Valid pool format types</h3>
    <p>
      The RBD pool does not use the pool format type element.
    </p>

    <h3>Valid volume format types</h3>
    <p>
      The RBD pool does not use the volume format type element.
    </p>
603

604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662
    <h2><a name="StorageBackendSheepdog">Sheepdog pools</a></h2>
    <p>
      This provides a pool based on a Sheepdog Cluster.
      Sheepdog is a distributed storage system for QEMU/KVM.
      It provides highly available block level storage volumes that
      can be attached to QEMU/KVM virtual machines.

      The cluster must already be formatted.

      <span class="since">Since 0.9.13</span>
    </p>

    <h3>Example pool input</h3>
    <pre>
      &lt;pool type="sheepdog"&gt;
        &lt;name&gt;mysheeppool&lt;/name&gt;
        &lt;source&gt;
          &lt;name&gt;mysheeppool&lt;/name&gt;
          &lt;host name='localhost' port='7000'/&gt;
        &lt;/source&gt;
      &lt;/pool&gt;</pre>

    <h3>Example volume output</h3>
    <pre>
       &lt;volume&gt;
         &lt;name&gt;myvol&lt;/name&gt;
         &lt;key&gt;sheep/myvol&lt;/key&gt;
         &lt;source&gt;
         &lt;/source&gt;
         &lt;capacity unit='bytes'&gt;53687091200&lt;/capacity&gt;
         &lt;allocation unit='bytes'&gt;53687091200&lt;/allocation&gt;
         &lt;target&gt;
           &lt;path&gt;sheepdog:myvol&lt;/path&gt;
           &lt;format type='unknown'/&gt;
           &lt;permissions&gt;
             &lt;mode&gt;00&lt;/mode&gt;
             &lt;owner&gt;0&lt;/owner&gt;
             &lt;group&gt;0&lt;/group&gt;
           &lt;/permissions&gt;
         &lt;/target&gt;
       &lt;/volume&gt;</pre>

    <h3>Example disk attachment</h3>
    <p>Sheepdog images can be attached to Qemu guests.
    Information about attaching a Sheepdog image to a
    guest can be found
    at the <a href="formatdomain.html#elementsDisks">format domain</a>
    page.</p>

    <h3>Valid pool format types</h3>
    <p>
      The Sheepdog pool does not use the pool format type element.
    </p>

    <h3>Valid volume format types</h3>
    <p>
      The Sheepdog pool does not use the volume format type element.
    </p>

E
Eric Blake 已提交
663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716
    <h2><a name="StorageBackendGluster">Gluster pools</a></h2>
    <p>
      This provides a pool based on native Gluster access.  Gluster is
      a distributed file system that can be exposed to the user via
      FUSE, NFS or SMB (see the <a href="#StorageBackendNetfs">netfs</a>
      pool for that usage); but for minimal overhead, the ideal access
      is via native access (only possible for QEMU/KVM compiled with
      libgfapi support).

      The cluster and storage volume must already be running, and it
      is recommended that the volume be configured with <code>gluster
      volume set $volname storage.owner-uid=$uid</code>
      and <code>gluster volume set $volname
      storage.owner-gid=$gid</code> for the uid and gid that qemu will
      be run as.  It may also be necessary to
      set <code>rpc-auth-allow-insecure on</code> for the glusterd
      service, as well as <code>gluster set $volname
      server.allow-insecure on</code>, to allow access to the gluster
      volume.

      <span class="since">Since 1.2.0</span>
    </p>

    <h3>Example pool input</h3>
    <p>A gluster volume corresponds to a libvirt storage pool.  If a
      gluster volume could be mounted as <code>mount -t glusterfs
      localhost:/volname /some/path</code>, then the following example
      will describe the same pool without having to create a local
      mount point.  Remember that with gluster, the mount point can be
      through any machine in the cluster, and gluster will
      automatically pick the ideal transport to the actual bricks
      backing the gluster volume, even if on a different host than the
      one named in the <code>host</code> designation.
      The <code>&lt;name&gt;</code> element is always the volume name
      (no slash).  The pool source also supports an
      optional <code>&lt;dir&gt;</code> element with
      a <code>path</code> attribute that lists the absolute name of a
      subdirectory relative to the gluster volume to use instead of
      the top-level directory of the volume.</p>
    <pre>
      &lt;pool type="gluster"&gt;
        &lt;name&gt;myglusterpool&lt;/name&gt;
        &lt;source&gt;
          &lt;name&gt;volname&lt;/name&gt;
          &lt;host name='localhost'/&gt;
          &lt;dir path='/'/&gt;
        &lt;/source&gt;
      &lt;/pool&gt;</pre>

    <h3>Example volume output</h3>
    <p>Libvirt storage volumes associated with a gluster pool
      correspond to the files that can be found when mounting the
      gluster volume.  The <code>name</code> is the path relative to
      the effective mount specified for the pool; and
717 718 719 720
      the <code>key</code> is a string that identifies a single volume
      uniquely. Currently the <code>key</code> attribute consists of the
      URI of the volume but it may be changed to a UUID of the volume
      in the future.</p>
E
Eric Blake 已提交
721 722 723
    <pre>
       &lt;volume&gt;
         &lt;name&gt;myfile&lt;/name&gt;
724
         &lt;key&gt;gluster://localhost/volname/myfile&lt;/key&gt;
E
Eric Blake 已提交
725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748
         &lt;source&gt;
         &lt;/source&gt;
         &lt;capacity unit='bytes'&gt;53687091200&lt;/capacity&gt;
         &lt;allocation unit='bytes'&gt;53687091200&lt;/allocation&gt;
       &lt;/volume&gt;</pre>

    <h3>Example disk attachment</h3>
    <p>Files within a gluster volume can be attached to Qemu guests.
    Information about attaching a Gluster image to a
    guest can be found
    at the <a href="formatdomain.html#elementsDisks">format domain</a>
    page.</p>

    <h3>Valid pool format types</h3>
    <p>
      The Gluster pool does not use the pool format type element.
    </p>

    <h3>Valid volume format types</h3>
    <p>
      The valid volume types are the same as for the <code>directory</code>
      pool type.
    </p>

R
Roman Bogorodskiy 已提交
749 750 751 752
    <h2><a name="StorageBackendZFS">ZFS pools</a></h2>
    <p>
      This provides a pool based on the ZFS filesystem. It is currently
      supported on FreeBSD only.
753
    </p>
R
Roman Bogorodskiy 已提交
754

755 756 757 758
    <p>A pool could either be created manually using the <code>zpool create</code>
      command and its name specified in the source section or <span class="since">
      since 1.2.9</span> source devices could be specified to create a pool using
      libvirt.
R
Roman Bogorodskiy 已提交
759 760
    </p>

761 762 763 764
    <p>Please refer to the ZFS documentation for details on a pool creation.</p>

    <p><span class="since">Since 1.2.8</span></p>.

R
Roman Bogorodskiy 已提交
765 766 767 768 769 770
    <h3>Example pool input</h3>
    <pre>
      &lt;pool type="zfs"&gt;
        &lt;name&gt;myzfspool&lt;/name&gt;
        &lt;source&gt;
          &lt;name&gt;zpoolname&lt;/name&gt;
771 772
          &lt;device path="/dev/ada1"/&gt;
          &lt;device path="/dev/ada2"/&gt;
R
Roman Bogorodskiy 已提交
773
        &lt;/source&gt;
774
      &lt;/pool&gt;</pre>
R
Roman Bogorodskiy 已提交
775 776 777 778 779 780 781 782 783 784 785

    <h3>Valid pool format types</h3>
    <p>
      The ZFS volume pool does not use the pool format type element.
    </p>

    <h3>Valid pool format types</h3>
    <p>
      The ZFS volume pool does not use the volume format type element.
    </p>

786 787
  </body>
</html>