aboutsummaryrefslogtreecommitdiff
path: root/docs/qemu-block-drivers.texi
blob: 2c7ea49c32d1181d0a7d3387fa2fa8389366032a (plain)
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
@c man begin SYNOPSIS
QEMU block driver reference manual
@c man end

@set qemu_system qemu-system-x86_64

@c man begin DESCRIPTION

@node disk_images_formats
@subsection Disk image file formats

QEMU supports many image file formats that can be used with VMs as well as with
any of the tools (like @code{qemu-img}). This includes the preferred formats
raw and qcow2 as well as formats that are supported for compatibility with
older QEMU versions or other hypervisors.

Depending on the image format, different options can be passed to
@code{qemu-img create} and @code{qemu-img convert} using the @code{-o} option.
This section describes each format and the options that are supported for it.

@table @option
@item raw

Raw disk image format. This format has the advantage of
being simple and easily exportable to all other emulators. If your
file system supports @emph{holes} (for example in ext2 or ext3 on
Linux or NTFS on Windows), then only the written sectors will reserve
space. Use @code{qemu-img info} to know the real size used by the
image or @code{ls -ls} on Unix/Linux.

Supported options:
@table @code
@item preallocation
Preallocation mode (allowed values: @code{off}, @code{falloc}, @code{full}).
@code{falloc} mode preallocates space for image by calling posix_fallocate().
@code{full} mode preallocates space for image by writing data to underlying
storage.  This data may or may not be zero, depending on the storage location.
@end table

@item qcow2
QEMU image format, the most versatile format. Use it to have smaller
images (useful if your filesystem does not supports holes, for example
on Windows), zlib based compression and support of multiple VM
snapshots.

Supported options:
@table @code
@item compat
Determines the qcow2 version to use. @code{compat=0.10} uses the
traditional image format that can be read by any QEMU since 0.10.
@code{compat=1.1} enables image format extensions that only QEMU 1.1 and
newer understand (this is the default). Amongst others, this includes
zero clusters, which allow efficient copy-on-read for sparse images.

@item backing_file
File name of a base image (see @option{create} subcommand)
@item backing_fmt
Image format of the base image
@item encryption
This option is deprecated and equivalent to @code{encrypt.format=aes}

@item encrypt.format

If this is set to @code{luks}, it requests that the qcow2 payload (not
qcow2 header) be encrypted using the LUKS format. The passphrase to
use to unlock the LUKS key slot is given by the @code{encrypt.key-secret}
parameter. LUKS encryption parameters can be tuned with the other
@code{encrypt.*} parameters.

If this is set to @code{aes}, the image is encrypted with 128-bit AES-CBC.
The encryption key is given by the @code{encrypt.key-secret} parameter.
This encryption format is considered to be flawed by modern cryptography
standards, suffering from a number of design problems:

@itemize @minus
@item The AES-CBC cipher is used with predictable initialization vectors based
on the sector number. This makes it vulnerable to chosen plaintext attacks
which can reveal the existence of encrypted data.
@item The user passphrase is directly used as the encryption key. A poorly
chosen or short passphrase will compromise the security of the encryption.
@item In the event of the passphrase being compromised there is no way to
change the passphrase to protect data in any qcow images. The files must
be cloned, using a different encryption passphrase in the new file. The
original file must then be securely erased using a program like shred,
though even this is ineffective with many modern storage technologies.
@end itemize

The use of this is no longer supported in system emulators. Support only
remains in the command line utilities, for the purposes of data liberation
and interoperability with old versions of QEMU. The @code{luks} format
should be used instead.

@item encrypt.key-secret

Provides the ID of a @code{secret} object that contains the passphrase
(@code{encrypt.format=luks}) or encryption key (@code{encrypt.format=aes}).

@item encrypt.cipher-alg

Name of the cipher algorithm and key length. Currently defaults
to @code{aes-256}. Only used when @code{encrypt.format=luks}.

@item encrypt.cipher-mode

Name of the encryption mode to use. Currently defaults to @code{xts}.
Only used when @code{encrypt.format=luks}.

@item encrypt.ivgen-alg

Name of the initialization vector generator algorithm. Currently defaults
to @code{plain64}. Only used when @code{encrypt.format=luks}.

@item encrypt.ivgen-hash-alg

Name of the hash algorithm to use with the initialization vector generator
(if required). Defaults to @code{sha256}. Only used when @code{encrypt.format=luks}.

@item encrypt.hash-alg

Name of the hash algorithm to use for PBKDF algorithm
Defaults to @code{sha256}. Only used when @code{encrypt.format=luks}.

@item encrypt.iter-time

Amount of time, in milliseconds, to use for PBKDF algorithm per key slot.
Defaults to @code{2000}. Only used when @code{encrypt.format=luks}.

@item cluster_size
Changes the qcow2 cluster size (must be between 512 and 2M). Smaller cluster
sizes can improve the image file size whereas larger cluster sizes generally
provide better performance.

@item preallocation
Preallocation mode (allowed values: @code{off}, @code{metadata}, @code{falloc},
@code{full}). An image with preallocated metadata is initially larger but can
improve performance when the image needs to grow. @code{falloc} and @code{full}
preallocations are like the same options of @code{raw} format, but sets up
metadata also.

@item lazy_refcounts
If this option is set to @code{on}, reference count updates are postponed with
the goal of avoiding metadata I/O and improving performance. This is
particularly interesting with @option{cache=writethrough} which doesn't batch
metadata updates. The tradeoff is that after a host crash, the reference count
tables must be rebuilt, i.e. on the next open an (automatic) @code{qemu-img
check -r all} is required, which may take some time.

This option can only be enabled if @code{compat=1.1} is specified.

@item nocow
If this option is set to @code{on}, it will turn off COW of the file. It's only
valid on btrfs, no effect on other file systems.

Btrfs has low performance when hosting a VM image file, even more when the guest
on the VM also using btrfs as file system. Turning off COW is a way to mitigate
this bad performance. Generally there are two ways to turn off COW on btrfs:
a) Disable it by mounting with nodatacow, then all newly created files will be
NOCOW. b) For an empty file, add the NOCOW file attribute. That's what this option
does.

Note: this option is only valid to new or empty files. If there is an existing
file which is COW and has data blocks already, it couldn't be changed to NOCOW
by setting @code{nocow=on}. One can issue @code{lsattr filename} to check if
the NOCOW flag is set or not (Capital 'C' is NOCOW flag).

@end table

@item qed
Old QEMU image format with support for backing files and compact image files
(when your filesystem or transport medium does not support holes).

When converting QED images to qcow2, you might want to consider using the
@code{lazy_refcounts=on} option to get a more QED-like behaviour.

Supported options:
@table @code
@item backing_file
File name of a base image (see @option{create} subcommand).
@item backing_fmt
Image file format of backing file (optional).  Useful if the format cannot be
autodetected because it has no header, like some vhd/vpc files.
@item cluster_size
Changes the cluster size (must be power-of-2 between 4K and 64K). Smaller
cluster sizes can improve the image file size whereas larger cluster sizes
generally provide better performance.
@item table_size
Changes the number of clusters per L1/L2 table (must be power-of-2 between 1
and 16).  There is normally no need to change this value but this option can be
used for performance benchmarking.
@end table

@item qcow
Old QEMU image format with support for backing files, compact image files,
encryption and compression.

Supported options:
@table @code
@item backing_file
File name of a base image (see @option{create} subcommand)
@item encryption
This option is deprecated and equivalent to @code{encrypt.format=aes}

@item encrypt.format
If this is set to @code{aes}, the image is encrypted with 128-bit AES-CBC.
The encryption key is given by the @code{encrypt.key-secret} parameter.
This encryption format is considered to be flawed by modern cryptography
standards, suffering from a number of design problems enumerated previously
against the @code{qcow2} image format.

The use of this is no longer supported in system emulators. Support only
remains in the command line utilities, for the purposes of data liberation
and interoperability with old versions of QEMU.

Users requiring native encryption should use the @code{qcow2} format
instead with @code{encrypt.format=luks}.

@item encrypt.key-secret

Provides the ID of a @code{secret} object that contains the encryption
key (@code{encrypt.format=aes}).

@end table

@item luks

LUKS v1 encryption format, compatible with Linux dm-crypt/cryptsetup

Supported options:
@table @code

@item key-secret

Provides the ID of a @code{secret} object that contains the passphrase.

@item cipher-alg

Name of the cipher algorithm and key length. Currently defaults
to @code{aes-256}.

@item cipher-mode

Name of the encryption mode to use. Currently defaults to @code{xts}.

@item ivgen-alg

Name of the initialization vector generator algorithm. Currently defaults
to @code{plain64}.

@item ivgen-hash-alg

Name of the hash algorithm to use with the initialization vector generator
(if required). Defaults to @code{sha256}.

@item hash-alg

Name of the hash algorithm to use for PBKDF algorithm
Defaults to @code{sha256}.

@item iter-time

Amount of time, in milliseconds, to use for PBKDF algorithm per key slot.
Defaults to @code{2000}.

@end table

@item vdi
VirtualBox 1.1 compatible image format.
Supported options:
@table @code
@item static
If this option is set to @code{on}, the image is created with metadata
preallocation.
@end table

@item vmdk
VMware 3 and 4 compatible image format.

Supported options:
@table @code
@item backing_file
File name of a base image (see @option{create} subcommand).
@item compat6
Create a VMDK version 6 image (instead of version 4)
@item hwversion
Specify vmdk virtual hardware version. Compat6 flag cannot be enabled
if hwversion is specified.
@item subformat
Specifies which VMDK subformat to use. Valid options are
@code{monolithicSparse} (default),
@code{monolithicFlat},
@code{twoGbMaxExtentSparse},
@code{twoGbMaxExtentFlat} and
@code{streamOptimized}.
@end table

@item vpc
VirtualPC compatible image format (VHD).
Supported options:
@table @code
@item subformat
Specifies which VHD subformat to use. Valid options are
@code{dynamic} (default) and @code{fixed}.
@end table

@item VHDX
Hyper-V compatible image format (VHDX).
Supported options:
@table @code
@item subformat
Specifies which VHDX subformat to use. Valid options are
@code{dynamic} (default) and @code{fixed}.
@item block_state_zero
Force use of payload blocks of type 'ZERO'.  Can be set to @code{on} (default)
or @code{off}.  When set to @code{off}, new blocks will be created as
@code{PAYLOAD_BLOCK_NOT_PRESENT}, which means parsers are free to return
arbitrary data for those blocks.  Do not set to @code{off} when using
@code{qemu-img convert} with @code{subformat=dynamic}.
@item block_size
Block size; min 1 MB, max 256 MB.  0 means auto-calculate based on image size.
@item log_size
Log size; min 1 MB.
@end table
@end table

@subsubsection Read-only formats
More disk image file formats are supported in a read-only mode.
@table @option
@item bochs
Bochs images of @code{growing} type.
@item cloop
Linux Compressed Loop image, useful only to reuse directly compressed
CD-ROM images present for example in the Knoppix CD-ROMs.
@item dmg
Apple disk image.
@item parallels
Parallels disk image format.
@end table


@node host_drives
@subsection Using host drives

In addition to disk image files, QEMU can directly access host
devices. We describe here the usage for QEMU version >= 0.8.3.

@subsubsection Linux

On Linux, you can directly use the host device filename instead of a
disk image filename provided you have enough privileges to access
it. For example, use @file{/dev/cdrom} to access to the CDROM.

@table @code
@item CD
You can specify a CDROM device even if no CDROM is loaded. QEMU has
specific code to detect CDROM insertion or removal. CDROM ejection by
the guest OS is supported. Currently only data CDs are supported.
@item Floppy
You can specify a floppy device even if no floppy is loaded. Floppy
removal is currently not detected accurately (if you change floppy
without doing floppy access while the floppy is not loaded, the guest
OS will think that the same floppy is loaded).
Use of the host's floppy device is deprecated, and support for it will
be removed in a future release.
@item Hard disks
Hard disks can be used. Normally you must specify the whole disk
(@file{/dev/hdb} instead of @file{/dev/hdb1}) so that the guest OS can
see it as a partitioned disk. WARNING: unless you know what you do, it
is better to only make READ-ONLY accesses to the hard disk otherwise
you may corrupt your host data (use the @option{-snapshot} command
line option or modify the device permissions accordingly).
@end table

@subsubsection Windows

@table @code
@item CD
The preferred syntax is the drive letter (e.g. @file{d:}). The
alternate syntax @file{\\.\d:} is supported. @file{/dev/cdrom} is
supported as an alias to the first CDROM drive.

Currently there is no specific code to handle removable media, so it
is better to use the @code{change} or @code{eject} monitor commands to
change or eject media.
@item Hard disks
Hard disks can be used with the syntax: @file{\\.\PhysicalDrive@var{N}}
where @var{N} is the drive number (0 is the first hard disk).

WARNING: unless you know what you do, it is better to only make
READ-ONLY accesses to the hard disk otherwise you may corrupt your
host data (use the @option{-snapshot} command line so that the
modifications are written in a temporary file).
@end table


@subsubsection Mac OS X

@file{/dev/cdrom} is an alias to the first CDROM.

Currently there is no specific code to handle removable media, so it
is better to use the @code{change} or @code{eject} monitor commands to
change or eject media.

@node disk_images_fat_images
@subsection Virtual FAT disk images

QEMU can automatically create a virtual FAT disk image from a
directory tree. In order to use it, just type:

@example
@value{qemu_system} linux.img -hdb fat:/my_directory
@end example

Then you access access to all the files in the @file{/my_directory}
directory without having to copy them in a disk image or to export
them via SAMBA or NFS. The default access is @emph{read-only}.

Floppies can be emulated with the @code{:floppy:} option:

@example
@value{qemu_system} linux.img -fda fat:floppy:/my_directory
@end example

A read/write support is available for testing (beta stage) with the
@code{:rw:} option:

@example
@value{qemu_system} linux.img -fda fat:floppy:rw:/my_directory
@end example

What you should @emph{never} do:
@itemize
@item use non-ASCII filenames ;
@item use "-snapshot" together with ":rw:" ;
@item expect it to work when loadvm'ing ;
@item write to the FAT directory on the host system while accessing it with the guest system.
@end itemize

@node disk_images_nbd
@subsection NBD access

QEMU can access directly to block device exported using the Network Block Device
protocol.

@example
@value{qemu_system} linux.img -hdb nbd://my_nbd_server.mydomain.org:1024/
@end example

If the NBD server is located on the same host, you can use an unix socket instead
of an inet socket:

@example
@value{qemu_system} linux.img -hdb nbd+unix://?socket=/tmp/my_socket
@end example

In this case, the block device must be exported using qemu-nbd:

@example
qemu-nbd --socket=/tmp/my_socket my_disk.qcow2
@end example

The use of qemu-nbd allows sharing of a disk between several guests:
@example
qemu-nbd --socket=/tmp/my_socket --share=2 my_disk.qcow2
@end example

@noindent
and then you can use it with two guests:
@example
@value{qemu_system} linux1.img -hdb nbd+unix://?socket=/tmp/my_socket
@value{qemu_system} linux2.img -hdb nbd+unix://?socket=/tmp/my_socket
@end example

If the nbd-server uses named exports (supported since NBD 2.9.18, or with QEMU's
own embedded NBD server), you must specify an export name in the URI:
@example
@value{qemu_system} -cdrom nbd://localhost/debian-500-ppc-netinst
@value{qemu_system} -cdrom nbd://localhost/openSUSE-11.1-ppc-netinst
@end example

The URI syntax for NBD is supported since QEMU 1.3.  An alternative syntax is
also available.  Here are some example of the older syntax:
@example
@value{qemu_system} linux.img -hdb nbd:my_nbd_server.mydomain.org:1024
@value{qemu_system} linux2.img -hdb nbd:unix:/tmp/my_socket
@value{qemu_system} -cdrom nbd:localhost:10809:exportname=debian-500-ppc-netinst
@end example

@node disk_images_sheepdog
@subsection Sheepdog disk images

Sheepdog is a distributed storage system for QEMU.  It provides highly
available block level storage volumes that can be attached to
QEMU-based virtual machines.

You can create a Sheepdog disk image with the command:
@example
qemu-img create sheepdog:///@var{image} @var{size}
@end example
where @var{image} is the Sheepdog image name and @var{size} is its
size.

To import the existing @var{filename} to Sheepdog, you can use a
convert command.
@example
qemu-img convert @var{filename} sheepdog:///@var{image}
@end example

You can boot from the Sheepdog disk image with the command:
@example
@value{qemu_system} sheepdog:///@var{image}
@end example

You can also create a snapshot of the Sheepdog image like qcow2.
@example
qemu-img snapshot -c @var{tag} sheepdog:///@var{image}
@end example
where @var{tag} is a tag name of the newly created snapshot.

To boot from the Sheepdog snapshot, specify the tag name of the
snapshot.
@example
@value{qemu_system} sheepdog:///@var{image}#@var{tag}
@end example

You can create a cloned image from the existing snapshot.
@example
qemu-img create -b sheepdog:///@var{base}#@var{tag} sheepdog:///@var{image}
@end example
where @var{base} is an image name of the source snapshot and @var{tag}
is its tag name.

You can use an unix socket instead of an inet socket:

@example
@value{qemu_system} sheepdog+unix:///@var{image}?socket=@var{path}
@end example

If the Sheepdog daemon doesn't run on the local host, you need to
specify one of the Sheepdog servers to connect to.
@example
qemu-img create sheepdog://@var{hostname}:@var{port}/@var{image} @var{size}
@value{qemu_system} sheepdog://@var{hostname}:@var{port}/@var{image}
@end example

@node disk_images_iscsi
@subsection iSCSI LUNs

iSCSI is a popular protocol used to access SCSI devices across a computer
network.

There are two different ways iSCSI devices can be used by QEMU.

The first method is to mount the iSCSI LUN on the host, and make it appear as
any other ordinary SCSI device on the host and then to access this device as a
/dev/sd device from QEMU. How to do this differs between host OSes.

The second method involves using the iSCSI initiator that is built into
QEMU. This provides a mechanism that works the same way regardless of which
host OS you are running QEMU on. This section will describe this second method
of using iSCSI together with QEMU.

In QEMU, iSCSI devices are described using special iSCSI URLs

@example
URL syntax:
iscsi://[<username>[%<password>]@@]<host>[:<port>]/<target-iqn-name>/<lun>
@end example

Username and password are optional and only used if your target is set up
using CHAP authentication for access control.
Alternatively the username and password can also be set via environment
variables to have these not show up in the process list

@example
export LIBISCSI_CHAP_USERNAME=<username>
export LIBISCSI_CHAP_PASSWORD=<password>
iscsi://<host>/<target-iqn-name>/<lun>
@end example

Various session related parameters can be set via special options, either
in a configuration file provided via '-readconfig' or directly on the
command line.

If the initiator-name is not specified qemu will use a default name
of 'iqn.2008-11.org.linux-kvm[:<uuid>'] where <uuid> is the UUID of the
virtual machine. If the UUID is not specified qemu will use
'iqn.2008-11.org.linux-kvm[:<name>'] where <name> is the name of the
virtual machine.

@example
Setting a specific initiator name to use when logging in to the target
-iscsi initiator-name=iqn.qemu.test:my-initiator
@end example

@example
Controlling which type of header digest to negotiate with the target
-iscsi header-digest=CRC32C|CRC32C-NONE|NONE-CRC32C|NONE
@end example

These can also be set via a configuration file
@example
[iscsi]
  user = "CHAP username"
  password = "CHAP password"
  initiator-name = "iqn.qemu.test:my-initiator"
  # header digest is one of CRC32C|CRC32C-NONE|NONE-CRC32C|NONE
  header-digest = "CRC32C"
@end example


Setting the target name allows different options for different targets
@example
[iscsi "iqn.target.name"]
  user = "CHAP username"
  password = "CHAP password"
  initiator-name = "iqn.qemu.test:my-initiator"
  # header digest is one of CRC32C|CRC32C-NONE|NONE-CRC32C|NONE
  header-digest = "CRC32C"
@end example


Howto use a configuration file to set iSCSI configuration options:
@example
cat >iscsi.conf <<EOF
[iscsi]
  user = "me"
  password = "my password"
  initiator-name = "iqn.qemu.test:my-initiator"
  header-digest = "CRC32C"
EOF

@value{qemu_system} -drive file=iscsi://127.0.0.1/iqn.qemu.test/1 \
    -readconfig iscsi.conf
@end example


How to set up a simple iSCSI target on loopback and access it via QEMU:
@example
This example shows how to set up an iSCSI target with one CDROM and one DISK
using the Linux STGT software target. This target is available on Red Hat based
systems as the package 'scsi-target-utils'.

tgtd --iscsi portal=127.0.0.1:3260
tgtadm --lld iscsi --op new --mode target --tid 1 -T iqn.qemu.test
tgtadm --lld iscsi --mode logicalunit --op new --tid 1 --lun 1 \
    -b /IMAGES/disk.img --device-type=disk
tgtadm --lld iscsi --mode logicalunit --op new --tid 1 --lun 2 \
    -b /IMAGES/cd.iso --device-type=cd
tgtadm --lld iscsi --op bind --mode target --tid 1 -I ALL

@value{qemu_system} -iscsi initiator-name=iqn.qemu.test:my-initiator \
    -boot d -drive file=iscsi://127.0.0.1/iqn.qemu.test/1 \
    -cdrom iscsi://127.0.0.1/iqn.qemu.test/2
@end example

@node disk_images_gluster
@subsection GlusterFS disk images

GlusterFS is a user space distributed file system.

You can boot from the GlusterFS disk image with the command:
@example
URI:
@value{qemu_system} -drive file=gluster[+@var{type}]://[@var{host}[:@var{port}]]/@var{volume}/@var{path}
                               [?socket=...][,file.debug=9][,file.logfile=...]

JSON:
@value{qemu_system} 'json:@{"driver":"qcow2",
                           "file":@{"driver":"gluster",
                                    "volume":"testvol","path":"a.img","debug":9,"logfile":"...",
                                    "server":[@{"type":"tcp","host":"...","port":"..."@},
                                              @{"type":"unix","socket":"..."@}]@}@}'
@end example

@var{gluster} is the protocol.

@var{type} specifies the transport type used to connect to gluster
management daemon (glusterd). Valid transport types are
tcp and unix. In the URI form, if a transport type isn't specified,
then tcp type is assumed.

@var{host} specifies the server where the volume file specification for
the given volume resides. This can be either a hostname or an ipv4 address.
If transport type is unix, then @var{host} field should not be specified.
Instead @var{socket} field needs to be populated with the path to unix domain
socket.

@var{port} is the port number on which glusterd is listening. This is optional
and if not specified, it defaults to port 24007. If the transport type is unix,
then @var{port} should not be specified.

@var{volume} is the name of the gluster volume which contains the disk image.

@var{path} is the path to the actual disk image that resides on gluster volume.

@var{debug} is the logging level of the gluster protocol driver. Debug levels
are 0-9, with 9 being the most verbose, and 0 representing no debugging output.
The default level is 4. The current logging levels defined in the gluster source
are 0 - None, 1 - Emergency, 2 - Alert, 3 - Critical, 4 - Error, 5 - Warning,
6 - Notice, 7 - Info, 8 - Debug, 9 - Trace

@var{logfile} is a commandline option to mention log file path which helps in
logging to the specified file and also help in persisting the gfapi logs. The
default is stderr.




You can create a GlusterFS disk image with the command:
@example
qemu-img create gluster://@var{host}/@var{volume}/@var{path} @var{size}
@end example

Examples
@example
@value{qemu_system} -drive file=gluster://1.2.3.4/testvol/a.img
@value{qemu_system} -drive file=gluster+tcp://1.2.3.4/testvol/a.img
@value{qemu_system} -drive file=gluster+tcp://1.2.3.4:24007/testvol/dir/a.img
@value{qemu_system} -drive file=gluster+tcp://[1:2:3:4:5:6:7:8]/testvol/dir/a.img
@value{qemu_system} -drive file=gluster+tcp://[1:2:3:4:5:6:7:8]:24007/testvol/dir/a.img
@value{qemu_system} -drive file=gluster+tcp://server.domain.com:24007/testvol/dir/a.img
@value{qemu_system} -drive file=gluster+unix:///testvol/dir/a.img?socket=/tmp/glusterd.socket
@value{qemu_system} -drive file=gluster+rdma://1.2.3.4:24007/testvol/a.img
@value{qemu_system} -drive file=gluster://1.2.3.4/testvol/a.img,file.debug=9,file.logfile=/var/log/qemu-gluster.log
@value{qemu_system} 'json:@{"driver":"qcow2",
                           "file":@{"driver":"gluster",
                                    "volume":"testvol","path":"a.img",
                                    "debug":9,"logfile":"/var/log/qemu-gluster.log",
                                    "server":[@{"type":"tcp","host":"1.2.3.4","port":24007@},
                                              @{"type":"unix","socket":"/var/run/glusterd.socket"@}]@}@}'
@value{qemu_system} -drive driver=qcow2,file.driver=gluster,file.volume=testvol,file.path=/path/a.img,
                                       file.debug=9,file.logfile=/var/log/qemu-gluster.log,
                                       file.server.0.type=tcp,file.server.0.host=1.2.3.4,file.server.0.port=24007,
                                       file.server.1.type=unix,file.server.1.socket=/var/run/glusterd.socket
@end example

@node disk_images_ssh
@subsection Secure Shell (ssh) disk images

You can access disk images located on a remote ssh server
by using the ssh protocol:

@example
@value{qemu_system} -drive file=ssh://[@var{user}@@]@var{server}[:@var{port}]/@var{path}[?host_key_check=@var{host_key_check}]
@end example

Alternative syntax using properties:

@example
@value{qemu_system} -drive file.driver=ssh[,file.user=@var{user}],file.host=@var{server}[,file.port=@var{port}],file.path=@var{path}[,file.host_key_check=@var{host_key_check}]
@end example

@var{ssh} is the protocol.

@var{user} is the remote user.  If not specified, then the local
username is tried.

@var{server} specifies the remote ssh server.  Any ssh server can be
used, but it must implement the sftp-server protocol.  Most Unix/Linux
systems should work without requiring any extra configuration.

@var{port} is the port number on which sshd is listening.  By default
the standard ssh port (22) is used.

@var{path} is the path to the disk image.

The optional @var{host_key_check} parameter controls how the remote
host's key is checked.  The default is @code{yes} which means to use
the local @file{.ssh/known_hosts} file.  Setting this to @code{no}
turns off known-hosts checking.  Or you can check that the host key
matches a specific fingerprint:
@code{host_key_check=md5:78:45:8e:14:57:4f:d5:45:83:0a:0e:f3:49:82:c9:c8}
(@code{sha1:} can also be used as a prefix, but note that OpenSSH
tools only use MD5 to print fingerprints).

Currently authentication must be done using ssh-agent.  Other
authentication methods may be supported in future.

Note: Many ssh servers do not support an @code{fsync}-style operation.
The ssh driver cannot guarantee that disk flush requests are
obeyed, and this causes a risk of disk corruption if the remote
server or network goes down during writes.  The driver will
print a warning when @code{fsync} is not supported:

warning: ssh server @code{ssh.example.com:22} does not support fsync

With sufficiently new versions of libssh and OpenSSH, @code{fsync} is
supported.

@node disk_images_nvme
@subsection NVMe disk images

NVM Express (NVMe) storage controllers can be accessed directly by a userspace
driver in QEMU.  This bypasses the host kernel file system and block layers
while retaining QEMU block layer functionalities, such as block jobs, I/O
throttling, image formats, etc.  Disk I/O performance is typically higher than
with @code{-drive file=/dev/sda} using either thread pool or linux-aio.

The controller will be exclusively used by the QEMU process once started. To be
able to share storage between multiple VMs and other applications on the host,
please use the file based protocols.

Before starting QEMU, bind the host NVMe controller to the host vfio-pci
driver.  For example:

@example
# modprobe vfio-pci
# lspci -n -s 0000:06:0d.0
06:0d.0 0401: 1102:0002 (rev 08)
# echo 0000:06:0d.0 > /sys/bus/pci/devices/0000:06:0d.0/driver/unbind
# echo 1102 0002 > /sys/bus/pci/drivers/vfio-pci/new_id

# @value{qemu_system} -drive file=nvme://@var{host}:@var{bus}:@var{slot}.@var{func}/@var{namespace}
@end example

Alternative syntax using properties:

@example
@value{qemu_system} -drive file.driver=nvme,file.device=@var{host}:@var{bus}:@var{slot}.@var{func},file.namespace=@var{namespace}
@end example

@var{host}:@var{bus}:@var{slot}.@var{func} is the NVMe controller's PCI device
address on the host.

@var{namespace} is the NVMe namespace number, starting from 1.

@node disk_image_locking
@subsection Disk image file locking

By default, QEMU tries to protect image files from unexpected concurrent
access, as long as it's supported by the block protocol driver and host
operating system. If multiple QEMU processes (including QEMU emulators and
utilities) try to open the same image with conflicting accessing modes, all but
the first one will get an error.

This feature is currently supported by the file protocol on Linux with the Open
File Descriptor (OFD) locking API, and can be configured to fall back to POSIX
locking if the POSIX host doesn't support Linux OFD locking.

To explicitly enable image locking, specify "locking=on" in the file protocol
driver options. If OFD locking is not possible, a warning will be printed and
the POSIX locking API will be used. In this case there is a risk that the lock
will get silently lost when doing hot plugging and block jobs, due to the
shortcomings of the POSIX locking API.

QEMU transparently handles lock handover during shared storage migration.  For
shared virtual disk images between multiple VMs, the "share-rw" device option
should be used.

By default, the guest has exclusive write access to its disk image. If the
guest can safely share the disk image with other writers the @code{-device
...,share-rw=on} parameter can be used.  This is only safe if the guest is
running software, such as a cluster file system, that coordinates disk accesses
to avoid corruption.

Note that share-rw=on only declares the guest's ability to share the disk.
Some QEMU features, such as image file formats, require exclusive write access
to the disk image and this is unaffected by the share-rw=on option.

Alternatively, locking can be fully disabled by "locking=off" block device
option. In the command line, the option is usually in the form of
"file.locking=off" as the protocol driver is normally placed as a "file" child
under a format driver. For example:

@code{-blockdev driver=qcow2,file.filename=/path/to/image,file.locking=off,file.driver=file}

To check if image locking is active, check the output of the "lslocks" command
on host and see if there are locks held by the QEMU process on the image file.
More than one byte could be locked by the QEMU instance, each byte of which
reflects a particular permission that is acquired or protected by the running
block driver.

@c man end

@ignore

@setfilename qemu-block-drivers
@settitle QEMU block drivers reference

@c man begin SEEALSO
The HTML documentation of QEMU for more precise information and Linux
user mode emulator invocation.
@c man end

@c man begin AUTHOR
Fabrice Bellard and the QEMU Project developers
@c man end

@end ignore