File: storage.html

package info (click to toggle)
libvirt 5.6.0-2
  • links: PTS, VCS
  • area: main
  • in suites: bullseye
  • size: 240,844 kB
  • sloc: ansic: 584,521; xml: 176,725; sh: 9,912; python: 4,731; perl: 4,343; makefile: 3,321; ml: 465
file content (949 lines) | stat: -rw-r--r-- 36,395 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
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
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
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
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
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
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
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
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
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
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
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
  <!--
        This file is autogenerated from storage.html.in
        Do not edit this file. Changes will be lost.
      -->
  <!--
        This page was generated at Tue Jul 30 02:04:27 UTC 2019.
      -->
  <head>
    <meta charset="UTF-8"/>
    <meta name="viewport" content="width=device-width, initial-scale=1"/>
    <link rel="stylesheet" type="text/css" href="main.css"/>
    <link rel="apple-touch-icon" sizes="180x180" href="/apple-touch-icon.png"/>
    <link rel="icon" type="image/png" sizes="32x32" href="/favicon-32x32.png"/>
    <link rel="icon" type="image/png" sizes="16x16" href="/favicon-16x16.png"/>
    <link rel="manifest" href="/manifest.json"/>
    <meta name="theme-color" content="#ffffff"/>
    <title>libvirt: Storage Management</title>
    <meta name="description" content="libvirt, virtualization, virtualization API"/>
    <script type="text/javascript" src="js/main.js">
      <!--// forces non-empty element-->
    </script>
  </head>
  <body onload="pageload()">
    <div id="body">
      <div id="content">
        <h1>Storage Management</h1>
        <p>
      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>
        <ul>
          <li>
            <a href="#StorageBackendDir">Directory pool</a>
          </li>
          <li>
            <a href="#StorageBackendFS">Filesystem pool</a>
          </li>
          <li>
            <a href="#StorageBackendNetFS">Network filesystem pool</a>
          </li>
          <li>
            <a href="#StorageBackendLogical">Logical volume pool</a>
          </li>
          <li>
            <a href="#StorageBackendDisk">Disk pool</a>
          </li>
          <li>
            <a href="#StorageBackendISCSI">iSCSI pool</a>
          </li>
          <li>
            <a href="#StorageBackendISCSIDirect">iSCSI direct pool</a>
          </li>
          <li>
            <a href="#StorageBackendSCSI">SCSI pool</a>
          </li>
          <li>
            <a href="#StorageBackendMultipath">Multipath pool</a>
          </li>
          <li>
            <a href="#StorageBackendRBD">RBD pool</a>
          </li>
          <li>
            <a href="#StorageBackendSheepdog">Sheepdog pool</a>
          </li>
          <li>
            <a href="#StorageBackendGluster">Gluster pool</a>
          </li>
          <li>
            <a href="#StorageBackendZFS">ZFS pool</a>
          </li>
          <li>
            <a href="#StorageBackendVstorage">Vstorage pool</a>
          </li>
        </ul>
        <h2>
          <a id="StorageBackendDir">Directory pool</a>
          <a class="headerlink" href="#StorageBackendDir" title="Permalink to this headline">¶</a>
        </h2>
        <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>qcow2</code>, <code>vmdk</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;
&lt;/pool&gt;</pre>
        <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>
          <li><code>qed</code>: QEMU Enhanced Disk image format</li>
          <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
      the <code>qemu-img</code> tool is present. The others are
      dependent on support of the <code>qemu-img</code> tool.

    </p>
        <h2>
          <a id="StorageBackendFS">Filesystem pool</a>
          <a class="headerlink" href="#StorageBackendFS" title="Permalink to this headline">¶</a>
        </h2>
        <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;
&lt;/pool&gt;</pre>
        <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>
          <li>
            <code>ocfs2</code>
          </li>
        </ul>
        <h3>Valid volume format types</h3>
        <p>
      The valid volume types are the same as for the <code>directory</code>
      pool type.
    </p>
        <h2>
          <a id="StorageBackendNetFS">Network filesystem pool</a>
          <a class="headerlink" href="#StorageBackendNetFS" title="Permalink to this headline">¶</a>
        </h2>
        <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
      point. It will default to using <code>auto</code> as the
      protocol, which generally tries a mount via NFS first.
    </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;
    &lt;format type='nfs'/&gt;
  &lt;/source&gt;
  &lt;target&gt;
    &lt;path&gt;/var/lib/virt/images&lt;/path&gt;
  &lt;/target&gt;
&lt;/pool&gt;</pre>
        <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>
          <li><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
        directly mount subdirectories within a volume.  (To bypass the
        file system completely, see
        the <a href="#StorageBackendGluster">gluster</a> pool.)
      </li>
          <li><code>cifs</code> - use the SMB (samba) or CIFS file system.
        The mount will use "-o guest" to mount the directory anonymously.
      </li>
        </ul>
        <h3>Valid volume format types</h3>
        <p>
      The valid volume types are the same as for the <code>directory</code>
      pool type.
    </p>
        <h2>
          <a id="StorageBackendLogical">Logical volume pool</a>
          <a class="headerlink" href="#StorageBackendLogical" title="Permalink to this headline">¶</a>
        </h2>
        <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;
&lt;/pool&gt;</pre>
        <h3>Valid pool format types</h3>
        <p>
      The logical volume pool supports only the <code>lvm2</code> format,
      although not supplying a format value will result in automatic
      selection of the<code>lvm2</code> format.
    </p>
        <h3>Valid volume format types</h3>
        <p>
      The logical volume pool does not use the volume format type element.
    </p>
        <h2>
          <a id="StorageBackendDisk">Disk pool</a>
          <a class="headerlink" href="#StorageBackendDisk" title="Permalink to this headline">¶</a>
        </h2>
        <p>
      This provides a pool based on a physical disk. Volumes are created
      by adding partitions to the disk. Disk pools 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 two different free extents.
      It will default to using <code>dos</code> as the pool source format.
    </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;
&lt;/pool&gt;</pre>
        <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>
            <code>dos</code>
          </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>
          <li>
            <code>lvm2</code>
          </li>
        </ul>
        <p>
      The formats <code>dos</code> ("msdos" in parted terminology,
      good for BIOS systems) or <code>gpt</code> (good for UEFI
      systems) are recommended for best portability - the latter is
      needed for disks larger than 2TB. Note that the <code>lvm2</code>
      format refers to the physical volume format (i.e. the whole
      disk is a physical volume - not the usual usage of LVM where
      physical volumes are partitions). This is not really
      a partition table and such pool cannot be built by libvirt,
      only detected.
    </p>
        <p>
      Building a pool of a certain format depends on its availability
      in <code>parted</code>.
    </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>
        <h2>
          <a id="StorageBackendISCSI">iSCSI pool</a>
          <a class="headerlink" href="#StorageBackendISCSI" title="Permalink to this headline">¶</a>
        </h2>
        <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>
        <p>
      The libvirt iSCSI storage backend does not resolve the provided
      host name or IP address when finding the available target IQN's
      on the host; therefore, defining two pools to use the same IQN
      on the same host will fail the duplicate source pool checks.
    </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="iqn.2013-06.com.example:iscsi-pool"/&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 iSCSI volume pool does not use the pool format type element.
    </p>
        <h3>Valid volume format types</h3>
        <p>
      The iSCSI volume pool does not use the volume format type element.
    </p>
        <h2>
          <a id="StorageBackendISCSIDirect">iSCSI direct pool</a>
          <a class="headerlink" href="#StorageBackendISCSIDirect" title="Permalink to this headline">¶</a>
        </h2>
        <p>
      This is a variant of the iSCSI pool. Instead of using iscsiadm, it uses
      libiscsi.
      It requires a host, a path which is the target IQN, and an initiator IQN.
    </p>
        <h3>Example pool input</h3>
        <pre>
&lt;pool type="iscsi-direct"&gt;
  &lt;name&gt;virtimages&lt;/name&gt;
  &lt;source&gt;
    &lt;host name="iscsi.example.com"/&gt;
    &lt;device path="iqn.2013-06.com.example:iscsi-pool"/&gt;
    &lt;initiator&gt;
      &lt;iqn name="iqn.2013-06.com.example:iscsi-initiator"/&gt;
    &lt;/initiator&gt;
  &lt;/source&gt;
&lt;/pool&gt;</pre>
        <h3>Valid pool format types</h3>
        <p>
      The iSCSI direct volume pool does not use the pool format type element.
    </p>
        <h3>Valid volume format types</h3>
        <p>
      The iSCSI direct volume pool does not use the volume format type element.
    </p>
        <h2>
          <a id="StorageBackendSCSI">SCSI pool</a>
          <a class="headerlink" href="#StorageBackendSCSI" title="Permalink to this headline">¶</a>
        </h2>
        <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
      <span class="since">Since 0.6.2</span>
    </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>
        <h2>
          <a id="StorageBackendMultipath">Multipath pool</a>
          <a class="headerlink" href="#StorageBackendMultipath" title="Permalink to this headline">¶</a>
        </h2>
        <p>
      This provides a pool that contains all the multipath devices on the
      host. Therefore, only one Multipath pool may be configured per 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.
      <span class="since">Since 0.7.1</span>
    </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>
        <h2>
          <a id="StorageBackendRBD">RBD pool</a>
          <a class="headerlink" href="#StorageBackendRBD" title="Permalink to this headline">¶</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.<br/>
      The port attribute for a Ceph monitor does not have to be provided.
      If not provided librados will use the default Ceph monitor port.
      <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'/&gt;
    &lt;host name='my.ceph.monitor'/&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>
        <h3>Example disk attachment</h3>
        <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>
      Only raw volumes are supported.
    </p>
        <h2>
          <a id="StorageBackendSheepdog">Sheepdog pool</a>
          <a class="headerlink" href="#StorageBackendSheepdog" title="Permalink to this headline">¶</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>
        <h2>
          <a id="StorageBackendGluster">Gluster pool</a>
          <a class="headerlink" href="#StorageBackendGluster" title="Permalink to this headline">¶</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
      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>
        <pre>
&lt;volume&gt;
  &lt;name&gt;myfile&lt;/name&gt;
  &lt;key&gt;gluster://localhost/volname/myfile&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;/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>
        <h2>
          <a id="StorageBackendZFS">ZFS pool</a>
          <a class="headerlink" href="#StorageBackendZFS" title="Permalink to this headline">¶</a>
        </h2>
        <p>
      This provides a pool based on the ZFS filesystem. Initially it was developed
      for FreeBSD, and <span class="since">since 1.3.2</span> experimental support
      for <a href="http://zfsonlinux.org/">ZFS on Linux</a> version 0.6.4 or newer
      is available.
    </p>
        <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.
    </p>
        <p>Please refer to the ZFS documentation for details on a pool creation.</p>
        <p>
          <span class="since">Since 1.2.8</span>
        </p>
        <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;
    &lt;device path="/dev/ada1"/&gt;
    &lt;device path="/dev/ada2"/&gt;
  &lt;/source&gt;
&lt;/pool&gt;</pre>
        <h3>Valid pool format types</h3>
        <p>
      The ZFS volume pool does not use the pool format type element.
    </p>
        <h3>Valid volume format types</h3>
        <p>
      The ZFS volume pool does not use the volume format type element.
    </p>
        <h2>
          <a id="StorageBackendVstorage">Vstorage pool</a>
          <a class="headerlink" href="#StorageBackendVstorage" title="Permalink to this headline">¶</a>
        </h2>
        <p>
      This provides a pool based on Virtuozzo storage. Virtuozzo Storage is
      a highly available distributed software-defined storage with built-in
      replication and disaster recovery. More detailed information about
      Virtuozzo storage and its management can be found here:

      <a href="https://openvz.org/Virtuozzo_Storage">Virtuozzo Storage</a>).
    </p>
        <p>Please refer to the Virtuozzo Storage documentation for details
      on storage management and usage.</p>
        <h3>Example pool input</h3>
        <p>In order to create storage pool with Virtuozzo Storage backend you
    have to provide cluster name and be authorized within the cluster.</p>
        <pre>
&lt;pool type="vstorage"&gt;
  &lt;name&gt;myvstoragepool&lt;/name&gt;
  &lt;source&gt;
    &lt;name&gt;clustername&lt;/name&gt;
  &lt;/source&gt;
  &lt;target&gt;
    &lt;path&gt;/mnt/clustername&lt;/path&gt;
  &lt;/target&gt;
&lt;/pool&gt;</pre>
        <h3>Valid pool format types</h3>
        <p>
      The Vstorage volume 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 directory pool.</p>
      </div>
    </div>
    <div id="nav">
      <div id="home">
        <a href="index.html">Home</a>
      </div>
      <div id="jumplinks">
        <ul>
          <li>
            <a href="downloads.html">Download</a>
          </li>
          <li>
            <a href="contribute.html">Contribute</a>
          </li>
          <li>
            <a href="docs.html">Docs</a>
          </li>
        </ul>
      </div>
      <div id="search">
        <form id="simplesearch" action="https://www.google.com/search" enctype="application/x-www-form-urlencoded" method="get">
          <div>
            <input id="searchsite" name="sitesearch" type="hidden" value="libvirt.org"/>
            <input id="searchq" name="q" type="text" size="12" value=""/>
            <input name="submit" type="submit" value="Go"/>
          </div>
        </form>
        <div id="advancedsearch">
          <span>
            <input type="radio" name="what" id="whatwebsite" checked="checked" value="website"/>
            <label for="whatwebsite">Website</label>
          </span>
          <span>
            <input type="radio" name="what" id="whatwiki" value="wiki"/>
            <label for="whatwiki">Wiki</label>
          </span>
          <span>
            <input type="radio" name="what" id="whatdevs" value="devs"/>
            <label for="whatdevs">Developers list</label>
          </span>
          <span>
            <input type="radio" name="what" id="whatusers" value="users"/>
            <label for="whatusers">Users list</label>
          </span>
        </div>
      </div>
    </div>
    <div id="footer">
      <div id="contact">
        <h3>Contact</h3>
        <ul>
          <li>
            <a href="contact.html#email">email</a>
          </li>
          <li>
            <a href="contact.html#irc">irc</a>
          </li>
        </ul>
      </div>
      <div id="community">
        <h3>Community</h3>
        <ul>
          <li>
            <a href="https://twitter.com/hashtag/libvirt">twitter</a>
          </li>
          <li>
            <a href="http://stackoverflow.com/questions/tagged/libvirt">stackoverflow</a>
          </li>
          <li>
            <a href="http://serverfault.com/questions/tagged/libvirt">serverfault</a>
          </li>
        </ul>
      </div>
      <div id="conduct">
            Participants in the libvirt project agree to abide by <a href="governance.html#codeofconduct">the project code of conduct</a></div>
      <br class="clear"/>
    </div>
  </body>
</html>