vitalif
/
mirror_qemu
mirror of https://github.com/proxmox/mirror_qemu
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
mirror_qemu/tests/qemu-iotests/082.out

787 lines
36 KiB
Plaintext
Raw Normal View History

qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
QA output created by 082
=== create: Options specified more than once ===
Testing: create -f foo -f qcow2 TEST_DIR/t.qcow2 128M
block: deprecate "encryption=on" in favor of "encrypt.format=aes" Historically the qcow & qcow2 image formats supported a property "encryption=on" to enable their built-in AES encryption. We'll soon be supporting LUKS for qcow2, so need a more general purpose way to enable encryption, with a choice of formats. This introduces an "encrypt.format" option, which will later be joined by a number of other "encrypt.XXX" options. The use of a "encrypt." prefix instead of "encrypt-" is done to facilitate mapping to a nested QAPI schema at later date. e.g. the preferred syntax is now qemu-img create -f qcow2 -o encrypt.format=aes demo.qcow2 Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-8-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:06 +03:00
Formatting 'TEST_DIR/t.qcow2', fmt=qcow2 size=134217728 cluster_size=65536 lazy_refcounts=off refcount_bits=16
iotests: Use _img_info qemu-img info should only be used directly if the format-specific information or the name of the format is relevant (some tests explicitly test format-specific information; test 082 uses qcow2-specific settings to test the qemu-img interface); otherwise, tests should always use _img_info instead. Test 082 was touched only partially. It does test the qemu-img interface; however, its invocations of qemu-img info are not real tests but rather verifications, so if format-specific information is not important for the test, there is no reason not to use _img_info. In contrast to directly invoking qemu-img info, "qcow2" is replaced by "IMGFMT"; but as "qcow2" is only mentioned once in test 082 (in _supported_fmt), I consider this an improvement. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 1412105489-7681-2-git-send-email-mreitz@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2014-09-30 23:31:27 +04:00
image: TEST_DIR/t.IMGFMT
file format: IMGFMT
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
virtual size: 128M (134217728 bytes)
cluster_size: 65536
Testing: create -f qcow2 -o cluster_size=4k -o lazy_refcounts=on TEST_DIR/t.qcow2 128M
block: deprecate "encryption=on" in favor of "encrypt.format=aes" Historically the qcow & qcow2 image formats supported a property "encryption=on" to enable their built-in AES encryption. We'll soon be supporting LUKS for qcow2, so need a more general purpose way to enable encryption, with a choice of formats. This introduces an "encrypt.format" option, which will later be joined by a number of other "encrypt.XXX" options. The use of a "encrypt." prefix instead of "encrypt-" is done to facilitate mapping to a nested QAPI schema at later date. e.g. the preferred syntax is now qemu-img create -f qcow2 -o encrypt.format=aes demo.qcow2 Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-8-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:06 +03:00
Formatting 'TEST_DIR/t.qcow2', fmt=qcow2 size=134217728 cluster_size=4096 lazy_refcounts=on refcount_bits=16
qemu-iotests: 082: Filter the real disk size The real on-disk size of an image depends on things like the host filesystem. _img_info already filters it out, use the function in 082. Signed-off-by: Michael Mueller <mimu@linux.vnet.ibm.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-11-27 19:28:01 +03:00
image: TEST_DIR/t.IMGFMT
file format: IMGFMT
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
virtual size: 128M (134217728 bytes)
cluster_size: 4096
Format specific information:
compat: 1.1
lazy refcounts: true
qcow2: Add refcount_bits to format-specific info Add the bit width of every refcount entry to the format-specific information. In contrast to lazy_refcounts and the corrupt flag, this should be always emitted, even for compat=0.10 although it does not support any refcount width other than 16 bits. This is because if a boolean is optional, one normally assumes it to be false when omitted; but if an integer is not specified, it is rather difficult to guess its value. This new field breaks some test outputs, fix them. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2015-02-10 23:28:44 +03:00
refcount bits: 16
qapi: Add corrupt field to ImageInfoSpecificQCow2 Just like lazy-refcounts, this field will be present iff the qcow2 compat level is 1.1 (or probably any future revision). As expected, this breaks some tests due to the new field present in qemu-img info output; so fix their output accordingly. Suggested-by: Eric Blake <eblake@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 1412105489-7681-3-git-send-email-mreitz@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2014-09-30 23:31:28 +04:00
corrupt: false
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
Testing: create -f qcow2 -o cluster_size=4k -o lazy_refcounts=on -o cluster_size=8k TEST_DIR/t.qcow2 128M
block: deprecate "encryption=on" in favor of "encrypt.format=aes" Historically the qcow & qcow2 image formats supported a property "encryption=on" to enable their built-in AES encryption. We'll soon be supporting LUKS for qcow2, so need a more general purpose way to enable encryption, with a choice of formats. This introduces an "encrypt.format" option, which will later be joined by a number of other "encrypt.XXX" options. The use of a "encrypt." prefix instead of "encrypt-" is done to facilitate mapping to a nested QAPI schema at later date. e.g. the preferred syntax is now qemu-img create -f qcow2 -o encrypt.format=aes demo.qcow2 Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-8-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:06 +03:00
Formatting 'TEST_DIR/t.qcow2', fmt=qcow2 size=134217728 cluster_size=8192 lazy_refcounts=on refcount_bits=16
qemu-iotests: 082: Filter the real disk size The real on-disk size of an image depends on things like the host filesystem. _img_info already filters it out, use the function in 082. Signed-off-by: Michael Mueller <mimu@linux.vnet.ibm.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-11-27 19:28:01 +03:00
image: TEST_DIR/t.IMGFMT
file format: IMGFMT
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
virtual size: 128M (134217728 bytes)
cluster_size: 8192
Format specific information:
compat: 1.1
lazy refcounts: true
qcow2: Add refcount_bits to format-specific info Add the bit width of every refcount entry to the format-specific information. In contrast to lazy_refcounts and the corrupt flag, this should be always emitted, even for compat=0.10 although it does not support any refcount width other than 16 bits. This is because if a boolean is optional, one normally assumes it to be false when omitted; but if an integer is not specified, it is rather difficult to guess its value. This new field breaks some test outputs, fix them. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2015-02-10 23:28:44 +03:00
refcount bits: 16
qapi: Add corrupt field to ImageInfoSpecificQCow2 Just like lazy-refcounts, this field will be present iff the qcow2 compat level is 1.1 (or probably any future revision). As expected, this breaks some tests due to the new field present in qemu-img info output; so fix their output accordingly. Suggested-by: Eric Blake <eblake@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 1412105489-7681-3-git-send-email-mreitz@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2014-09-30 23:31:28 +04:00
corrupt: false
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
Testing: create -f qcow2 -o cluster_size=4k,cluster_size=8k TEST_DIR/t.qcow2 128M
block: deprecate "encryption=on" in favor of "encrypt.format=aes" Historically the qcow & qcow2 image formats supported a property "encryption=on" to enable their built-in AES encryption. We'll soon be supporting LUKS for qcow2, so need a more general purpose way to enable encryption, with a choice of formats. This introduces an "encrypt.format" option, which will later be joined by a number of other "encrypt.XXX" options. The use of a "encrypt." prefix instead of "encrypt-" is done to facilitate mapping to a nested QAPI schema at later date. e.g. the preferred syntax is now qemu-img create -f qcow2 -o encrypt.format=aes demo.qcow2 Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-8-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:06 +03:00
Formatting 'TEST_DIR/t.qcow2', fmt=qcow2 size=134217728 cluster_size=8192 lazy_refcounts=off refcount_bits=16
iotests: Use _img_info qemu-img info should only be used directly if the format-specific information or the name of the format is relevant (some tests explicitly test format-specific information; test 082 uses qcow2-specific settings to test the qemu-img interface); otherwise, tests should always use _img_info instead. Test 082 was touched only partially. It does test the qemu-img interface; however, its invocations of qemu-img info are not real tests but rather verifications, so if format-specific information is not important for the test, there is no reason not to use _img_info. In contrast to directly invoking qemu-img info, "qcow2" is replaced by "IMGFMT"; but as "qcow2" is only mentioned once in test 082 (in _supported_fmt), I consider this an improvement. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 1412105489-7681-2-git-send-email-mreitz@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2014-09-30 23:31:27 +04:00
image: TEST_DIR/t.IMGFMT
file format: IMGFMT
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
virtual size: 128M (134217728 bytes)
cluster_size: 8192
=== create: help for -o ===
Testing: create -f qcow2 -o help TEST_DIR/t.qcow2 128M
Supported options:
size Virtual disk size
compat Compatibility level (0.10 or 1.1)
backing_file File name of a base image
backing_fmt Image format of the base image
block: deprecate "encryption=on" in favor of "encrypt.format=aes" Historically the qcow & qcow2 image formats supported a property "encryption=on" to enable their built-in AES encryption. We'll soon be supporting LUKS for qcow2, so need a more general purpose way to enable encryption, with a choice of formats. This introduces an "encrypt.format" option, which will later be joined by a number of other "encrypt.XXX" options. The use of a "encrypt." prefix instead of "encrypt-" is done to facilitate mapping to a nested QAPI schema at later date. e.g. the preferred syntax is now qemu-img create -f qcow2 -o encrypt.format=aes demo.qcow2 Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-8-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:06 +03:00
encryption Encrypt the image with format 'aes'. (Deprecated in favor of encrypt.format=aes)
qcow2: add support for LUKS encryption format This adds support for using LUKS as an encryption format with the qcow2 file, using the new encrypt.format parameter to request "luks" format. e.g. # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 \ test.qcow2 10G The legacy "encryption=on" parameter still results in creation of the old qcow2 AES format (and is equivalent to the new 'encryption-format=aes'). e.g. the following are equivalent: # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption=on,encrypt.key-secret=sec0 \ test.qcow2 10G # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption-format=aes,encrypt.key-secret=sec0 \ test.qcow2 10G With the LUKS format it is necessary to store the LUKS partition header and key material in the QCow2 file. This data can be many MB in size, so cannot go into the QCow2 header region directly. Thus the spec defines a FDE (Full Disk Encryption) header extension that specifies the offset of a set of clusters to hold the FDE headers, as well as the length of that region. The LUKS header is thus stored in these extra allocated clusters before the main image payload. Aside from all the cryptographic differences implied by use of the LUKS format, there is one further key difference between the use of legacy AES and LUKS encryption in qcow2. For LUKS, the initialiazation vectors are generated using the host physical sector as the input, rather than the guest virtual sector. This guarantees unique initialization vectors for all sectors when qcow2 internal snapshots are used, thus giving stronger protection against watermarking attacks. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-14-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:12 +03:00
encrypt.format Encrypt the image, format choices: 'aes', 'luks'
encrypt.key-secret ID of secret providing qcow AES key or LUKS passphrase
encrypt.cipher-alg Name of encryption cipher algorithm
encrypt.cipher-mode Name of encryption cipher mode
encrypt.ivgen-alg Name of IV generator algorithm
encrypt.ivgen-hash-alg Name of IV generator hash algorithm
encrypt.hash-alg Name of encryption hash algorithm
encrypt.iter-time Time to spend in PBKDF in milliseconds
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
cluster_size qcow2 cluster size
qcow2: Add falloc and full preallocation option preallocation=falloc allocates disk space by posix_fallocate(), preallocation=full allocates disk space by writing zeros to disk. Both modes imply preallocation=metadata. Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-09-10 13:05:49 +04:00
preallocation Preallocation mode (allowed values: off, metadata, falloc, full)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
lazy_refcounts Postpone refcount updates
qcow2: Allow creation with refcount order != 4 Add a creation option to qcow2 for setting the refcount order of images to be created, and respect that option's value. This breaks some test outputs, fix them. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2015-02-19 01:40:49 +03:00
refcount_bits Width of a reference count entry in bits
qemu-img create: add 'nocow' option Add 'nocow' option so that users could have a chance to set NOCOW flag to newly created files. It's useful on btrfs file system to enhance performance. Btrfs has low performance when hosting VM images, even more when the guest in those VM are also using btrfs as file system. One way to mitigate this bad performance is to turn off COW attributes on VM files. Generally, there are two ways to turn off NOCOW on btrfs: a) by mounting fs with nodatacow, then all newly created files will be NOCOW. b) per file. Add the NOCOW file attribute. It could only be done to empty or new files. This patch tries the second way, according to the option, it could add NOCOW per file. For most block drivers, since the create file step is in raw-posix.c, so we can do setting NOCOW flag ioctl in raw-posix.c only. But there are some exceptions, like block/vpc.c and block/vdi.c, they are creating file by calling qemu_open directly. For them, do the same setting NOCOW flag ioctl work in them separately. [Fixed up 082.out due to the new 'nocow' creation option --Stefan] Signed-off-by: Chunyan Liu <cyliu@suse.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2014-06-30 10:29:58 +04:00
nocow Turn off copy-on-write (valid only on btrfs)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
Testing: create -f qcow2 -o ? TEST_DIR/t.qcow2 128M
Supported options:
size Virtual disk size
compat Compatibility level (0.10 or 1.1)
backing_file File name of a base image
backing_fmt Image format of the base image
block: deprecate "encryption=on" in favor of "encrypt.format=aes" Historically the qcow & qcow2 image formats supported a property "encryption=on" to enable their built-in AES encryption. We'll soon be supporting LUKS for qcow2, so need a more general purpose way to enable encryption, with a choice of formats. This introduces an "encrypt.format" option, which will later be joined by a number of other "encrypt.XXX" options. The use of a "encrypt." prefix instead of "encrypt-" is done to facilitate mapping to a nested QAPI schema at later date. e.g. the preferred syntax is now qemu-img create -f qcow2 -o encrypt.format=aes demo.qcow2 Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-8-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:06 +03:00
encryption Encrypt the image with format 'aes'. (Deprecated in favor of encrypt.format=aes)
qcow2: add support for LUKS encryption format This adds support for using LUKS as an encryption format with the qcow2 file, using the new encrypt.format parameter to request "luks" format. e.g. # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 \ test.qcow2 10G The legacy "encryption=on" parameter still results in creation of the old qcow2 AES format (and is equivalent to the new 'encryption-format=aes'). e.g. the following are equivalent: # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption=on,encrypt.key-secret=sec0 \ test.qcow2 10G # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption-format=aes,encrypt.key-secret=sec0 \ test.qcow2 10G With the LUKS format it is necessary to store the LUKS partition header and key material in the QCow2 file. This data can be many MB in size, so cannot go into the QCow2 header region directly. Thus the spec defines a FDE (Full Disk Encryption) header extension that specifies the offset of a set of clusters to hold the FDE headers, as well as the length of that region. The LUKS header is thus stored in these extra allocated clusters before the main image payload. Aside from all the cryptographic differences implied by use of the LUKS format, there is one further key difference between the use of legacy AES and LUKS encryption in qcow2. For LUKS, the initialiazation vectors are generated using the host physical sector as the input, rather than the guest virtual sector. This guarantees unique initialization vectors for all sectors when qcow2 internal snapshots are used, thus giving stronger protection against watermarking attacks. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-14-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:12 +03:00
encrypt.format Encrypt the image, format choices: 'aes', 'luks'
encrypt.key-secret ID of secret providing qcow AES key or LUKS passphrase
encrypt.cipher-alg Name of encryption cipher algorithm
encrypt.cipher-mode Name of encryption cipher mode
encrypt.ivgen-alg Name of IV generator algorithm
encrypt.ivgen-hash-alg Name of IV generator hash algorithm
encrypt.hash-alg Name of encryption hash algorithm
encrypt.iter-time Time to spend in PBKDF in milliseconds
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
cluster_size qcow2 cluster size
qcow2: Add falloc and full preallocation option preallocation=falloc allocates disk space by posix_fallocate(), preallocation=full allocates disk space by writing zeros to disk. Both modes imply preallocation=metadata. Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-09-10 13:05:49 +04:00
preallocation Preallocation mode (allowed values: off, metadata, falloc, full)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
lazy_refcounts Postpone refcount updates
qcow2: Allow creation with refcount order != 4 Add a creation option to qcow2 for setting the refcount order of images to be created, and respect that option's value. This breaks some test outputs, fix them. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2015-02-19 01:40:49 +03:00
refcount_bits Width of a reference count entry in bits
qemu-img create: add 'nocow' option Add 'nocow' option so that users could have a chance to set NOCOW flag to newly created files. It's useful on btrfs file system to enhance performance. Btrfs has low performance when hosting VM images, even more when the guest in those VM are also using btrfs as file system. One way to mitigate this bad performance is to turn off COW attributes on VM files. Generally, there are two ways to turn off NOCOW on btrfs: a) by mounting fs with nodatacow, then all newly created files will be NOCOW. b) per file. Add the NOCOW file attribute. It could only be done to empty or new files. This patch tries the second way, according to the option, it could add NOCOW per file. For most block drivers, since the create file step is in raw-posix.c, so we can do setting NOCOW flag ioctl in raw-posix.c only. But there are some exceptions, like block/vpc.c and block/vdi.c, they are creating file by calling qemu_open directly. For them, do the same setting NOCOW flag ioctl work in them separately. [Fixed up 082.out due to the new 'nocow' creation option --Stefan] Signed-off-by: Chunyan Liu <cyliu@suse.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2014-06-30 10:29:58 +04:00
nocow Turn off copy-on-write (valid only on btrfs)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
Testing: create -f qcow2 -o cluster_size=4k,help TEST_DIR/t.qcow2 128M
Supported options:
size Virtual disk size
compat Compatibility level (0.10 or 1.1)
backing_file File name of a base image
backing_fmt Image format of the base image
block: deprecate "encryption=on" in favor of "encrypt.format=aes" Historically the qcow & qcow2 image formats supported a property "encryption=on" to enable their built-in AES encryption. We'll soon be supporting LUKS for qcow2, so need a more general purpose way to enable encryption, with a choice of formats. This introduces an "encrypt.format" option, which will later be joined by a number of other "encrypt.XXX" options. The use of a "encrypt." prefix instead of "encrypt-" is done to facilitate mapping to a nested QAPI schema at later date. e.g. the preferred syntax is now qemu-img create -f qcow2 -o encrypt.format=aes demo.qcow2 Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-8-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:06 +03:00
encryption Encrypt the image with format 'aes'. (Deprecated in favor of encrypt.format=aes)
qcow2: add support for LUKS encryption format This adds support for using LUKS as an encryption format with the qcow2 file, using the new encrypt.format parameter to request "luks" format. e.g. # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 \ test.qcow2 10G The legacy "encryption=on" parameter still results in creation of the old qcow2 AES format (and is equivalent to the new 'encryption-format=aes'). e.g. the following are equivalent: # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption=on,encrypt.key-secret=sec0 \ test.qcow2 10G # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption-format=aes,encrypt.key-secret=sec0 \ test.qcow2 10G With the LUKS format it is necessary to store the LUKS partition header and key material in the QCow2 file. This data can be many MB in size, so cannot go into the QCow2 header region directly. Thus the spec defines a FDE (Full Disk Encryption) header extension that specifies the offset of a set of clusters to hold the FDE headers, as well as the length of that region. The LUKS header is thus stored in these extra allocated clusters before the main image payload. Aside from all the cryptographic differences implied by use of the LUKS format, there is one further key difference between the use of legacy AES and LUKS encryption in qcow2. For LUKS, the initialiazation vectors are generated using the host physical sector as the input, rather than the guest virtual sector. This guarantees unique initialization vectors for all sectors when qcow2 internal snapshots are used, thus giving stronger protection against watermarking attacks. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-14-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:12 +03:00
encrypt.format Encrypt the image, format choices: 'aes', 'luks'
encrypt.key-secret ID of secret providing qcow AES key or LUKS passphrase
encrypt.cipher-alg Name of encryption cipher algorithm
encrypt.cipher-mode Name of encryption cipher mode
encrypt.ivgen-alg Name of IV generator algorithm
encrypt.ivgen-hash-alg Name of IV generator hash algorithm
encrypt.hash-alg Name of encryption hash algorithm
encrypt.iter-time Time to spend in PBKDF in milliseconds
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
cluster_size qcow2 cluster size
qcow2: Add falloc and full preallocation option preallocation=falloc allocates disk space by posix_fallocate(), preallocation=full allocates disk space by writing zeros to disk. Both modes imply preallocation=metadata. Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-09-10 13:05:49 +04:00
preallocation Preallocation mode (allowed values: off, metadata, falloc, full)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
lazy_refcounts Postpone refcount updates
qcow2: Allow creation with refcount order != 4 Add a creation option to qcow2 for setting the refcount order of images to be created, and respect that option's value. This breaks some test outputs, fix them. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2015-02-19 01:40:49 +03:00
refcount_bits Width of a reference count entry in bits
qemu-img create: add 'nocow' option Add 'nocow' option so that users could have a chance to set NOCOW flag to newly created files. It's useful on btrfs file system to enhance performance. Btrfs has low performance when hosting VM images, even more when the guest in those VM are also using btrfs as file system. One way to mitigate this bad performance is to turn off COW attributes on VM files. Generally, there are two ways to turn off NOCOW on btrfs: a) by mounting fs with nodatacow, then all newly created files will be NOCOW. b) per file. Add the NOCOW file attribute. It could only be done to empty or new files. This patch tries the second way, according to the option, it could add NOCOW per file. For most block drivers, since the create file step is in raw-posix.c, so we can do setting NOCOW flag ioctl in raw-posix.c only. But there are some exceptions, like block/vpc.c and block/vdi.c, they are creating file by calling qemu_open directly. For them, do the same setting NOCOW flag ioctl work in them separately. [Fixed up 082.out due to the new 'nocow' creation option --Stefan] Signed-off-by: Chunyan Liu <cyliu@suse.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2014-06-30 10:29:58 +04:00
nocow Turn off copy-on-write (valid only on btrfs)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
Testing: create -f qcow2 -o cluster_size=4k,? TEST_DIR/t.qcow2 128M
Supported options:
size Virtual disk size
compat Compatibility level (0.10 or 1.1)
backing_file File name of a base image
backing_fmt Image format of the base image
block: deprecate "encryption=on" in favor of "encrypt.format=aes" Historically the qcow & qcow2 image formats supported a property "encryption=on" to enable their built-in AES encryption. We'll soon be supporting LUKS for qcow2, so need a more general purpose way to enable encryption, with a choice of formats. This introduces an "encrypt.format" option, which will later be joined by a number of other "encrypt.XXX" options. The use of a "encrypt." prefix instead of "encrypt-" is done to facilitate mapping to a nested QAPI schema at later date. e.g. the preferred syntax is now qemu-img create -f qcow2 -o encrypt.format=aes demo.qcow2 Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-8-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:06 +03:00
encryption Encrypt the image with format 'aes'. (Deprecated in favor of encrypt.format=aes)
qcow2: add support for LUKS encryption format This adds support for using LUKS as an encryption format with the qcow2 file, using the new encrypt.format parameter to request "luks" format. e.g. # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 \ test.qcow2 10G The legacy "encryption=on" parameter still results in creation of the old qcow2 AES format (and is equivalent to the new 'encryption-format=aes'). e.g. the following are equivalent: # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption=on,encrypt.key-secret=sec0 \ test.qcow2 10G # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption-format=aes,encrypt.key-secret=sec0 \ test.qcow2 10G With the LUKS format it is necessary to store the LUKS partition header and key material in the QCow2 file. This data can be many MB in size, so cannot go into the QCow2 header region directly. Thus the spec defines a FDE (Full Disk Encryption) header extension that specifies the offset of a set of clusters to hold the FDE headers, as well as the length of that region. The LUKS header is thus stored in these extra allocated clusters before the main image payload. Aside from all the cryptographic differences implied by use of the LUKS format, there is one further key difference between the use of legacy AES and LUKS encryption in qcow2. For LUKS, the initialiazation vectors are generated using the host physical sector as the input, rather than the guest virtual sector. This guarantees unique initialization vectors for all sectors when qcow2 internal snapshots are used, thus giving stronger protection against watermarking attacks. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-14-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:12 +03:00
encrypt.format Encrypt the image, format choices: 'aes', 'luks'
encrypt.key-secret ID of secret providing qcow AES key or LUKS passphrase
encrypt.cipher-alg Name of encryption cipher algorithm
encrypt.cipher-mode Name of encryption cipher mode
encrypt.ivgen-alg Name of IV generator algorithm
encrypt.ivgen-hash-alg Name of IV generator hash algorithm
encrypt.hash-alg Name of encryption hash algorithm
encrypt.iter-time Time to spend in PBKDF in milliseconds
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
cluster_size qcow2 cluster size
qcow2: Add falloc and full preallocation option preallocation=falloc allocates disk space by posix_fallocate(), preallocation=full allocates disk space by writing zeros to disk. Both modes imply preallocation=metadata. Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-09-10 13:05:49 +04:00
preallocation Preallocation mode (allowed values: off, metadata, falloc, full)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
lazy_refcounts Postpone refcount updates
qcow2: Allow creation with refcount order != 4 Add a creation option to qcow2 for setting the refcount order of images to be created, and respect that option's value. This breaks some test outputs, fix them. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2015-02-19 01:40:49 +03:00
refcount_bits Width of a reference count entry in bits
qemu-img create: add 'nocow' option Add 'nocow' option so that users could have a chance to set NOCOW flag to newly created files. It's useful on btrfs file system to enhance performance. Btrfs has low performance when hosting VM images, even more when the guest in those VM are also using btrfs as file system. One way to mitigate this bad performance is to turn off COW attributes on VM files. Generally, there are two ways to turn off NOCOW on btrfs: a) by mounting fs with nodatacow, then all newly created files will be NOCOW. b) per file. Add the NOCOW file attribute. It could only be done to empty or new files. This patch tries the second way, according to the option, it could add NOCOW per file. For most block drivers, since the create file step is in raw-posix.c, so we can do setting NOCOW flag ioctl in raw-posix.c only. But there are some exceptions, like block/vpc.c and block/vdi.c, they are creating file by calling qemu_open directly. For them, do the same setting NOCOW flag ioctl work in them separately. [Fixed up 082.out due to the new 'nocow' creation option --Stefan] Signed-off-by: Chunyan Liu <cyliu@suse.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2014-06-30 10:29:58 +04:00
nocow Turn off copy-on-write (valid only on btrfs)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
Testing: create -f qcow2 -o help,cluster_size=4k TEST_DIR/t.qcow2 128M
Supported options:
size Virtual disk size
compat Compatibility level (0.10 or 1.1)
backing_file File name of a base image
backing_fmt Image format of the base image
block: deprecate "encryption=on" in favor of "encrypt.format=aes" Historically the qcow & qcow2 image formats supported a property "encryption=on" to enable their built-in AES encryption. We'll soon be supporting LUKS for qcow2, so need a more general purpose way to enable encryption, with a choice of formats. This introduces an "encrypt.format" option, which will later be joined by a number of other "encrypt.XXX" options. The use of a "encrypt." prefix instead of "encrypt-" is done to facilitate mapping to a nested QAPI schema at later date. e.g. the preferred syntax is now qemu-img create -f qcow2 -o encrypt.format=aes demo.qcow2 Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-8-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:06 +03:00
encryption Encrypt the image with format 'aes'. (Deprecated in favor of encrypt.format=aes)
qcow2: add support for LUKS encryption format This adds support for using LUKS as an encryption format with the qcow2 file, using the new encrypt.format parameter to request "luks" format. e.g. # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 \ test.qcow2 10G The legacy "encryption=on" parameter still results in creation of the old qcow2 AES format (and is equivalent to the new 'encryption-format=aes'). e.g. the following are equivalent: # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption=on,encrypt.key-secret=sec0 \ test.qcow2 10G # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption-format=aes,encrypt.key-secret=sec0 \ test.qcow2 10G With the LUKS format it is necessary to store the LUKS partition header and key material in the QCow2 file. This data can be many MB in size, so cannot go into the QCow2 header region directly. Thus the spec defines a FDE (Full Disk Encryption) header extension that specifies the offset of a set of clusters to hold the FDE headers, as well as the length of that region. The LUKS header is thus stored in these extra allocated clusters before the main image payload. Aside from all the cryptographic differences implied by use of the LUKS format, there is one further key difference between the use of legacy AES and LUKS encryption in qcow2. For LUKS, the initialiazation vectors are generated using the host physical sector as the input, rather than the guest virtual sector. This guarantees unique initialization vectors for all sectors when qcow2 internal snapshots are used, thus giving stronger protection against watermarking attacks. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-14-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:12 +03:00
encrypt.format Encrypt the image, format choices: 'aes', 'luks'
encrypt.key-secret ID of secret providing qcow AES key or LUKS passphrase
encrypt.cipher-alg Name of encryption cipher algorithm
encrypt.cipher-mode Name of encryption cipher mode
encrypt.ivgen-alg Name of IV generator algorithm
encrypt.ivgen-hash-alg Name of IV generator hash algorithm
encrypt.hash-alg Name of encryption hash algorithm
encrypt.iter-time Time to spend in PBKDF in milliseconds
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
cluster_size qcow2 cluster size
qcow2: Add falloc and full preallocation option preallocation=falloc allocates disk space by posix_fallocate(), preallocation=full allocates disk space by writing zeros to disk. Both modes imply preallocation=metadata. Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-09-10 13:05:49 +04:00
preallocation Preallocation mode (allowed values: off, metadata, falloc, full)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
lazy_refcounts Postpone refcount updates
qcow2: Allow creation with refcount order != 4 Add a creation option to qcow2 for setting the refcount order of images to be created, and respect that option's value. This breaks some test outputs, fix them. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2015-02-19 01:40:49 +03:00
refcount_bits Width of a reference count entry in bits
qemu-img create: add 'nocow' option Add 'nocow' option so that users could have a chance to set NOCOW flag to newly created files. It's useful on btrfs file system to enhance performance. Btrfs has low performance when hosting VM images, even more when the guest in those VM are also using btrfs as file system. One way to mitigate this bad performance is to turn off COW attributes on VM files. Generally, there are two ways to turn off NOCOW on btrfs: a) by mounting fs with nodatacow, then all newly created files will be NOCOW. b) per file. Add the NOCOW file attribute. It could only be done to empty or new files. This patch tries the second way, according to the option, it could add NOCOW per file. For most block drivers, since the create file step is in raw-posix.c, so we can do setting NOCOW flag ioctl in raw-posix.c only. But there are some exceptions, like block/vpc.c and block/vdi.c, they are creating file by calling qemu_open directly. For them, do the same setting NOCOW flag ioctl work in them separately. [Fixed up 082.out due to the new 'nocow' creation option --Stefan] Signed-off-by: Chunyan Liu <cyliu@suse.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2014-06-30 10:29:58 +04:00
nocow Turn off copy-on-write (valid only on btrfs)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
Testing: create -f qcow2 -o ?,cluster_size=4k TEST_DIR/t.qcow2 128M
Supported options:
size Virtual disk size
compat Compatibility level (0.10 or 1.1)
backing_file File name of a base image
backing_fmt Image format of the base image
block: deprecate "encryption=on" in favor of "encrypt.format=aes" Historically the qcow & qcow2 image formats supported a property "encryption=on" to enable their built-in AES encryption. We'll soon be supporting LUKS for qcow2, so need a more general purpose way to enable encryption, with a choice of formats. This introduces an "encrypt.format" option, which will later be joined by a number of other "encrypt.XXX" options. The use of a "encrypt." prefix instead of "encrypt-" is done to facilitate mapping to a nested QAPI schema at later date. e.g. the preferred syntax is now qemu-img create -f qcow2 -o encrypt.format=aes demo.qcow2 Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-8-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:06 +03:00
encryption Encrypt the image with format 'aes'. (Deprecated in favor of encrypt.format=aes)
qcow2: add support for LUKS encryption format This adds support for using LUKS as an encryption format with the qcow2 file, using the new encrypt.format parameter to request "luks" format. e.g. # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 \ test.qcow2 10G The legacy "encryption=on" parameter still results in creation of the old qcow2 AES format (and is equivalent to the new 'encryption-format=aes'). e.g. the following are equivalent: # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption=on,encrypt.key-secret=sec0 \ test.qcow2 10G # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption-format=aes,encrypt.key-secret=sec0 \ test.qcow2 10G With the LUKS format it is necessary to store the LUKS partition header and key material in the QCow2 file. This data can be many MB in size, so cannot go into the QCow2 header region directly. Thus the spec defines a FDE (Full Disk Encryption) header extension that specifies the offset of a set of clusters to hold the FDE headers, as well as the length of that region. The LUKS header is thus stored in these extra allocated clusters before the main image payload. Aside from all the cryptographic differences implied by use of the LUKS format, there is one further key difference between the use of legacy AES and LUKS encryption in qcow2. For LUKS, the initialiazation vectors are generated using the host physical sector as the input, rather than the guest virtual sector. This guarantees unique initialization vectors for all sectors when qcow2 internal snapshots are used, thus giving stronger protection against watermarking attacks. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-14-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:12 +03:00
encrypt.format Encrypt the image, format choices: 'aes', 'luks'
encrypt.key-secret ID of secret providing qcow AES key or LUKS passphrase
encrypt.cipher-alg Name of encryption cipher algorithm
encrypt.cipher-mode Name of encryption cipher mode
encrypt.ivgen-alg Name of IV generator algorithm
encrypt.ivgen-hash-alg Name of IV generator hash algorithm
encrypt.hash-alg Name of encryption hash algorithm
encrypt.iter-time Time to spend in PBKDF in milliseconds
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
cluster_size qcow2 cluster size
qcow2: Add falloc and full preallocation option preallocation=falloc allocates disk space by posix_fallocate(), preallocation=full allocates disk space by writing zeros to disk. Both modes imply preallocation=metadata. Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-09-10 13:05:49 +04:00
preallocation Preallocation mode (allowed values: off, metadata, falloc, full)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
lazy_refcounts Postpone refcount updates
qcow2: Allow creation with refcount order != 4 Add a creation option to qcow2 for setting the refcount order of images to be created, and respect that option's value. This breaks some test outputs, fix them. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2015-02-19 01:40:49 +03:00
refcount_bits Width of a reference count entry in bits
qemu-img create: add 'nocow' option Add 'nocow' option so that users could have a chance to set NOCOW flag to newly created files. It's useful on btrfs file system to enhance performance. Btrfs has low performance when hosting VM images, even more when the guest in those VM are also using btrfs as file system. One way to mitigate this bad performance is to turn off COW attributes on VM files. Generally, there are two ways to turn off NOCOW on btrfs: a) by mounting fs with nodatacow, then all newly created files will be NOCOW. b) per file. Add the NOCOW file attribute. It could only be done to empty or new files. This patch tries the second way, according to the option, it could add NOCOW per file. For most block drivers, since the create file step is in raw-posix.c, so we can do setting NOCOW flag ioctl in raw-posix.c only. But there are some exceptions, like block/vpc.c and block/vdi.c, they are creating file by calling qemu_open directly. For them, do the same setting NOCOW flag ioctl work in them separately. [Fixed up 082.out due to the new 'nocow' creation option --Stefan] Signed-off-by: Chunyan Liu <cyliu@suse.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2014-06-30 10:29:58 +04:00
nocow Turn off copy-on-write (valid only on btrfs)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
Testing: create -f qcow2 -o cluster_size=4k -o help TEST_DIR/t.qcow2 128M
Supported options:
size Virtual disk size
compat Compatibility level (0.10 or 1.1)
backing_file File name of a base image
backing_fmt Image format of the base image
block: deprecate "encryption=on" in favor of "encrypt.format=aes" Historically the qcow & qcow2 image formats supported a property "encryption=on" to enable their built-in AES encryption. We'll soon be supporting LUKS for qcow2, so need a more general purpose way to enable encryption, with a choice of formats. This introduces an "encrypt.format" option, which will later be joined by a number of other "encrypt.XXX" options. The use of a "encrypt." prefix instead of "encrypt-" is done to facilitate mapping to a nested QAPI schema at later date. e.g. the preferred syntax is now qemu-img create -f qcow2 -o encrypt.format=aes demo.qcow2 Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-8-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:06 +03:00
encryption Encrypt the image with format 'aes'. (Deprecated in favor of encrypt.format=aes)
qcow2: add support for LUKS encryption format This adds support for using LUKS as an encryption format with the qcow2 file, using the new encrypt.format parameter to request "luks" format. e.g. # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 \ test.qcow2 10G The legacy "encryption=on" parameter still results in creation of the old qcow2 AES format (and is equivalent to the new 'encryption-format=aes'). e.g. the following are equivalent: # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption=on,encrypt.key-secret=sec0 \ test.qcow2 10G # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption-format=aes,encrypt.key-secret=sec0 \ test.qcow2 10G With the LUKS format it is necessary to store the LUKS partition header and key material in the QCow2 file. This data can be many MB in size, so cannot go into the QCow2 header region directly. Thus the spec defines a FDE (Full Disk Encryption) header extension that specifies the offset of a set of clusters to hold the FDE headers, as well as the length of that region. The LUKS header is thus stored in these extra allocated clusters before the main image payload. Aside from all the cryptographic differences implied by use of the LUKS format, there is one further key difference between the use of legacy AES and LUKS encryption in qcow2. For LUKS, the initialiazation vectors are generated using the host physical sector as the input, rather than the guest virtual sector. This guarantees unique initialization vectors for all sectors when qcow2 internal snapshots are used, thus giving stronger protection against watermarking attacks. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-14-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:12 +03:00
encrypt.format Encrypt the image, format choices: 'aes', 'luks'
encrypt.key-secret ID of secret providing qcow AES key or LUKS passphrase
encrypt.cipher-alg Name of encryption cipher algorithm
encrypt.cipher-mode Name of encryption cipher mode
encrypt.ivgen-alg Name of IV generator algorithm
encrypt.ivgen-hash-alg Name of IV generator hash algorithm
encrypt.hash-alg Name of encryption hash algorithm
encrypt.iter-time Time to spend in PBKDF in milliseconds
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
cluster_size qcow2 cluster size
qcow2: Add falloc and full preallocation option preallocation=falloc allocates disk space by posix_fallocate(), preallocation=full allocates disk space by writing zeros to disk. Both modes imply preallocation=metadata. Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-09-10 13:05:49 +04:00
preallocation Preallocation mode (allowed values: off, metadata, falloc, full)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
lazy_refcounts Postpone refcount updates
qcow2: Allow creation with refcount order != 4 Add a creation option to qcow2 for setting the refcount order of images to be created, and respect that option's value. This breaks some test outputs, fix them. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2015-02-19 01:40:49 +03:00
refcount_bits Width of a reference count entry in bits
qemu-img create: add 'nocow' option Add 'nocow' option so that users could have a chance to set NOCOW flag to newly created files. It's useful on btrfs file system to enhance performance. Btrfs has low performance when hosting VM images, even more when the guest in those VM are also using btrfs as file system. One way to mitigate this bad performance is to turn off COW attributes on VM files. Generally, there are two ways to turn off NOCOW on btrfs: a) by mounting fs with nodatacow, then all newly created files will be NOCOW. b) per file. Add the NOCOW file attribute. It could only be done to empty or new files. This patch tries the second way, according to the option, it could add NOCOW per file. For most block drivers, since the create file step is in raw-posix.c, so we can do setting NOCOW flag ioctl in raw-posix.c only. But there are some exceptions, like block/vpc.c and block/vdi.c, they are creating file by calling qemu_open directly. For them, do the same setting NOCOW flag ioctl work in them separately. [Fixed up 082.out due to the new 'nocow' creation option --Stefan] Signed-off-by: Chunyan Liu <cyliu@suse.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2014-06-30 10:29:58 +04:00
nocow Turn off copy-on-write (valid only on btrfs)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
Testing: create -f qcow2 -o cluster_size=4k -o ? TEST_DIR/t.qcow2 128M
Supported options:
size Virtual disk size
compat Compatibility level (0.10 or 1.1)
backing_file File name of a base image
backing_fmt Image format of the base image
block: deprecate "encryption=on" in favor of "encrypt.format=aes" Historically the qcow & qcow2 image formats supported a property "encryption=on" to enable their built-in AES encryption. We'll soon be supporting LUKS for qcow2, so need a more general purpose way to enable encryption, with a choice of formats. This introduces an "encrypt.format" option, which will later be joined by a number of other "encrypt.XXX" options. The use of a "encrypt." prefix instead of "encrypt-" is done to facilitate mapping to a nested QAPI schema at later date. e.g. the preferred syntax is now qemu-img create -f qcow2 -o encrypt.format=aes demo.qcow2 Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-8-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:06 +03:00
encryption Encrypt the image with format 'aes'. (Deprecated in favor of encrypt.format=aes)
qcow2: add support for LUKS encryption format This adds support for using LUKS as an encryption format with the qcow2 file, using the new encrypt.format parameter to request "luks" format. e.g. # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 \ test.qcow2 10G The legacy "encryption=on" parameter still results in creation of the old qcow2 AES format (and is equivalent to the new 'encryption-format=aes'). e.g. the following are equivalent: # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption=on,encrypt.key-secret=sec0 \ test.qcow2 10G # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption-format=aes,encrypt.key-secret=sec0 \ test.qcow2 10G With the LUKS format it is necessary to store the LUKS partition header and key material in the QCow2 file. This data can be many MB in size, so cannot go into the QCow2 header region directly. Thus the spec defines a FDE (Full Disk Encryption) header extension that specifies the offset of a set of clusters to hold the FDE headers, as well as the length of that region. The LUKS header is thus stored in these extra allocated clusters before the main image payload. Aside from all the cryptographic differences implied by use of the LUKS format, there is one further key difference between the use of legacy AES and LUKS encryption in qcow2. For LUKS, the initialiazation vectors are generated using the host physical sector as the input, rather than the guest virtual sector. This guarantees unique initialization vectors for all sectors when qcow2 internal snapshots are used, thus giving stronger protection against watermarking attacks. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-14-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:12 +03:00
encrypt.format Encrypt the image, format choices: 'aes', 'luks'
encrypt.key-secret ID of secret providing qcow AES key or LUKS passphrase
encrypt.cipher-alg Name of encryption cipher algorithm
encrypt.cipher-mode Name of encryption cipher mode
encrypt.ivgen-alg Name of IV generator algorithm
encrypt.ivgen-hash-alg Name of IV generator hash algorithm
encrypt.hash-alg Name of encryption hash algorithm
encrypt.iter-time Time to spend in PBKDF in milliseconds
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
cluster_size qcow2 cluster size
qcow2: Add falloc and full preallocation option preallocation=falloc allocates disk space by posix_fallocate(), preallocation=full allocates disk space by writing zeros to disk. Both modes imply preallocation=metadata. Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-09-10 13:05:49 +04:00
preallocation Preallocation mode (allowed values: off, metadata, falloc, full)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
lazy_refcounts Postpone refcount updates
qcow2: Allow creation with refcount order != 4 Add a creation option to qcow2 for setting the refcount order of images to be created, and respect that option's value. This breaks some test outputs, fix them. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2015-02-19 01:40:49 +03:00
refcount_bits Width of a reference count entry in bits
qemu-img create: add 'nocow' option Add 'nocow' option so that users could have a chance to set NOCOW flag to newly created files. It's useful on btrfs file system to enhance performance. Btrfs has low performance when hosting VM images, even more when the guest in those VM are also using btrfs as file system. One way to mitigate this bad performance is to turn off COW attributes on VM files. Generally, there are two ways to turn off NOCOW on btrfs: a) by mounting fs with nodatacow, then all newly created files will be NOCOW. b) per file. Add the NOCOW file attribute. It could only be done to empty or new files. This patch tries the second way, according to the option, it could add NOCOW per file. For most block drivers, since the create file step is in raw-posix.c, so we can do setting NOCOW flag ioctl in raw-posix.c only. But there are some exceptions, like block/vpc.c and block/vdi.c, they are creating file by calling qemu_open directly. For them, do the same setting NOCOW flag ioctl work in them separately. [Fixed up 082.out due to the new 'nocow' creation option --Stefan] Signed-off-by: Chunyan Liu <cyliu@suse.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2014-06-30 10:29:58 +04:00
nocow Turn off copy-on-write (valid only on btrfs)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
qemu-img: Check for backing image if specified during create Or, rather, force the open of a backing image if one was specified for creation. Using a similar -unsafe option as rebase, allow qemu-img to ignore the backing file validation if possible. It may not always be possible, as in the existing case when a filesize for the new image was not specified. This is accomplished by shifting around the conditionals in bdrv_img_create, such that a backing file is always opened unless we provide BDRV_O_NO_BACKING. qemu-img is adjusted to pass this new flag when -u is provided to create. Sorry for the heinous looking diffstat, but it's mostly whitespace. Inspired by: https://bugzilla.redhat.com/show_bug.cgi?id=1213786 Signed-off-by: John Snow <jsnow@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-07-18 03:34:22 +03:00
Testing: create -f qcow2 -u -o backing_file=TEST_DIR/t.qcow2,,help TEST_DIR/t.qcow2 128M
block: deprecate "encryption=on" in favor of "encrypt.format=aes" Historically the qcow & qcow2 image formats supported a property "encryption=on" to enable their built-in AES encryption. We'll soon be supporting LUKS for qcow2, so need a more general purpose way to enable encryption, with a choice of formats. This introduces an "encrypt.format" option, which will later be joined by a number of other "encrypt.XXX" options. The use of a "encrypt." prefix instead of "encrypt-" is done to facilitate mapping to a nested QAPI schema at later date. e.g. the preferred syntax is now qemu-img create -f qcow2 -o encrypt.format=aes demo.qcow2 Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-8-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:06 +03:00
Formatting 'TEST_DIR/t.qcow2', fmt=qcow2 size=134217728 backing_file=TEST_DIR/t.qcow2,,help cluster_size=65536 lazy_refcounts=off refcount_bits=16
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
qemu-img: Check for backing image if specified during create Or, rather, force the open of a backing image if one was specified for creation. Using a similar -unsafe option as rebase, allow qemu-img to ignore the backing file validation if possible. It may not always be possible, as in the existing case when a filesize for the new image was not specified. This is accomplished by shifting around the conditionals in bdrv_img_create, such that a backing file is always opened unless we provide BDRV_O_NO_BACKING. qemu-img is adjusted to pass this new flag when -u is provided to create. Sorry for the heinous looking diffstat, but it's mostly whitespace. Inspired by: https://bugzilla.redhat.com/show_bug.cgi?id=1213786 Signed-off-by: John Snow <jsnow@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2017-07-18 03:34:22 +03:00
Testing: create -f qcow2 -u -o backing_file=TEST_DIR/t.qcow2,,? TEST_DIR/t.qcow2 128M
block: deprecate "encryption=on" in favor of "encrypt.format=aes" Historically the qcow & qcow2 image formats supported a property "encryption=on" to enable their built-in AES encryption. We'll soon be supporting LUKS for qcow2, so need a more general purpose way to enable encryption, with a choice of formats. This introduces an "encrypt.format" option, which will later be joined by a number of other "encrypt.XXX" options. The use of a "encrypt." prefix instead of "encrypt-" is done to facilitate mapping to a nested QAPI schema at later date. e.g. the preferred syntax is now qemu-img create -f qcow2 -o encrypt.format=aes demo.qcow2 Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-8-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:06 +03:00
Formatting 'TEST_DIR/t.qcow2', fmt=qcow2 size=134217728 backing_file=TEST_DIR/t.qcow2,,? cluster_size=65536 lazy_refcounts=off refcount_bits=16
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
Testing: create -f qcow2 -o backing_file=TEST_DIR/t.qcow2, -o help TEST_DIR/t.qcow2 128M
qemu-img: Invalid option list: backing_file=TEST_DIR/t.qcow2,
Testing: create -f qcow2 -o backing_file=TEST_DIR/t.qcow2 -o ,help TEST_DIR/t.qcow2 128M
qemu-img: Invalid option list: ,help
Testing: create -f qcow2 -o backing_file=TEST_DIR/t.qcow2 -o ,, -o help TEST_DIR/t.qcow2 128M
qemu-img: Invalid option list: ,,
Testing: create -f qcow2 -o help
Supported options:
size Virtual disk size
compat Compatibility level (0.10 or 1.1)
backing_file File name of a base image
backing_fmt Image format of the base image
block: deprecate "encryption=on" in favor of "encrypt.format=aes" Historically the qcow & qcow2 image formats supported a property "encryption=on" to enable their built-in AES encryption. We'll soon be supporting LUKS for qcow2, so need a more general purpose way to enable encryption, with a choice of formats. This introduces an "encrypt.format" option, which will later be joined by a number of other "encrypt.XXX" options. The use of a "encrypt." prefix instead of "encrypt-" is done to facilitate mapping to a nested QAPI schema at later date. e.g. the preferred syntax is now qemu-img create -f qcow2 -o encrypt.format=aes demo.qcow2 Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-8-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:06 +03:00
encryption Encrypt the image with format 'aes'. (Deprecated in favor of encrypt.format=aes)
qcow2: add support for LUKS encryption format This adds support for using LUKS as an encryption format with the qcow2 file, using the new encrypt.format parameter to request "luks" format. e.g. # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 \ test.qcow2 10G The legacy "encryption=on" parameter still results in creation of the old qcow2 AES format (and is equivalent to the new 'encryption-format=aes'). e.g. the following are equivalent: # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption=on,encrypt.key-secret=sec0 \ test.qcow2 10G # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption-format=aes,encrypt.key-secret=sec0 \ test.qcow2 10G With the LUKS format it is necessary to store the LUKS partition header and key material in the QCow2 file. This data can be many MB in size, so cannot go into the QCow2 header region directly. Thus the spec defines a FDE (Full Disk Encryption) header extension that specifies the offset of a set of clusters to hold the FDE headers, as well as the length of that region. The LUKS header is thus stored in these extra allocated clusters before the main image payload. Aside from all the cryptographic differences implied by use of the LUKS format, there is one further key difference between the use of legacy AES and LUKS encryption in qcow2. For LUKS, the initialiazation vectors are generated using the host physical sector as the input, rather than the guest virtual sector. This guarantees unique initialization vectors for all sectors when qcow2 internal snapshots are used, thus giving stronger protection against watermarking attacks. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-14-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:12 +03:00
encrypt.format Encrypt the image, format choices: 'aes', 'luks'
encrypt.key-secret ID of secret providing qcow AES key or LUKS passphrase
encrypt.cipher-alg Name of encryption cipher algorithm
encrypt.cipher-mode Name of encryption cipher mode
encrypt.ivgen-alg Name of IV generator algorithm
encrypt.ivgen-hash-alg Name of IV generator hash algorithm
encrypt.hash-alg Name of encryption hash algorithm
encrypt.iter-time Time to spend in PBKDF in milliseconds
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
cluster_size qcow2 cluster size
qcow2: Add falloc and full preallocation option preallocation=falloc allocates disk space by posix_fallocate(), preallocation=full allocates disk space by writing zeros to disk. Both modes imply preallocation=metadata. Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-09-10 13:05:49 +04:00
preallocation Preallocation mode (allowed values: off, metadata, falloc, full)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
lazy_refcounts Postpone refcount updates
qcow2: Allow creation with refcount order != 4 Add a creation option to qcow2 for setting the refcount order of images to be created, and respect that option's value. This breaks some test outputs, fix them. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2015-02-19 01:40:49 +03:00
refcount_bits Width of a reference count entry in bits
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
Testing: create -o help
Supported options:
size Virtual disk size
iotests: Test help option for unsupporting formats This adds test cases to 082 for qemu-img create/convert/amend "-o help" on formats that do not support creation or amendment, respectively. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20180509210023.20283-7-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2018-05-10 00:00:22 +03:00
Testing: create -f bochs -o help
qemu-img: Format driver 'bochs' does not support image creation
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
=== convert: Options specified more than once ===
Testing: create -f qcow2 TEST_DIR/t.qcow2 128M
block: deprecate "encryption=on" in favor of "encrypt.format=aes" Historically the qcow & qcow2 image formats supported a property "encryption=on" to enable their built-in AES encryption. We'll soon be supporting LUKS for qcow2, so need a more general purpose way to enable encryption, with a choice of formats. This introduces an "encrypt.format" option, which will later be joined by a number of other "encrypt.XXX" options. The use of a "encrypt." prefix instead of "encrypt-" is done to facilitate mapping to a nested QAPI schema at later date. e.g. the preferred syntax is now qemu-img create -f qcow2 -o encrypt.format=aes demo.qcow2 Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-8-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:06 +03:00
Formatting 'TEST_DIR/t.qcow2', fmt=qcow2 size=134217728 cluster_size=65536 lazy_refcounts=off refcount_bits=16
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
Testing: convert -f foo -f qcow2 TEST_DIR/t.qcow2 TEST_DIR/t.qcow2.base
iotests: Use _img_info qemu-img info should only be used directly if the format-specific information or the name of the format is relevant (some tests explicitly test format-specific information; test 082 uses qcow2-specific settings to test the qemu-img interface); otherwise, tests should always use _img_info instead. Test 082 was touched only partially. It does test the qemu-img interface; however, its invocations of qemu-img info are not real tests but rather verifications, so if format-specific information is not important for the test, there is no reason not to use _img_info. In contrast to directly invoking qemu-img info, "qcow2" is replaced by "IMGFMT"; but as "qcow2" is only mentioned once in test 082 (in _supported_fmt), I consider this an improvement. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 1412105489-7681-2-git-send-email-mreitz@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2014-09-30 23:31:27 +04:00
image: TEST_DIR/t.IMGFMT.base
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
file format: raw
virtual size: 128M (134217728 bytes)
Testing: convert -O foo -O qcow2 TEST_DIR/t.qcow2 TEST_DIR/t.qcow2.base
iotests: Use _img_info qemu-img info should only be used directly if the format-specific information or the name of the format is relevant (some tests explicitly test format-specific information; test 082 uses qcow2-specific settings to test the qemu-img interface); otherwise, tests should always use _img_info instead. Test 082 was touched only partially. It does test the qemu-img interface; however, its invocations of qemu-img info are not real tests but rather verifications, so if format-specific information is not important for the test, there is no reason not to use _img_info. In contrast to directly invoking qemu-img info, "qcow2" is replaced by "IMGFMT"; but as "qcow2" is only mentioned once in test 082 (in _supported_fmt), I consider this an improvement. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 1412105489-7681-2-git-send-email-mreitz@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2014-09-30 23:31:27 +04:00
image: TEST_DIR/t.IMGFMT.base
file format: IMGFMT
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
virtual size: 128M (134217728 bytes)
cluster_size: 65536
Testing: convert -O qcow2 -o cluster_size=4k -o lazy_refcounts=on TEST_DIR/t.qcow2 TEST_DIR/t.qcow2.base
qemu-iotests: 082: Filter the real disk size The real on-disk size of an image depends on things like the host filesystem. _img_info already filters it out, use the function in 082. Signed-off-by: Michael Mueller <mimu@linux.vnet.ibm.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-11-27 19:28:01 +03:00
image: TEST_DIR/t.IMGFMT.base
file format: IMGFMT
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
virtual size: 128M (134217728 bytes)
cluster_size: 4096
Format specific information:
compat: 1.1
lazy refcounts: true
qcow2: Add refcount_bits to format-specific info Add the bit width of every refcount entry to the format-specific information. In contrast to lazy_refcounts and the corrupt flag, this should be always emitted, even for compat=0.10 although it does not support any refcount width other than 16 bits. This is because if a boolean is optional, one normally assumes it to be false when omitted; but if an integer is not specified, it is rather difficult to guess its value. This new field breaks some test outputs, fix them. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2015-02-10 23:28:44 +03:00
refcount bits: 16
qapi: Add corrupt field to ImageInfoSpecificQCow2 Just like lazy-refcounts, this field will be present iff the qcow2 compat level is 1.1 (or probably any future revision). As expected, this breaks some tests due to the new field present in qemu-img info output; so fix their output accordingly. Suggested-by: Eric Blake <eblake@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 1412105489-7681-3-git-send-email-mreitz@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2014-09-30 23:31:28 +04:00
corrupt: false
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
Testing: convert -O qcow2 -o cluster_size=4k -o lazy_refcounts=on -o cluster_size=8k TEST_DIR/t.qcow2 TEST_DIR/t.qcow2.base
qemu-iotests: 082: Filter the real disk size The real on-disk size of an image depends on things like the host filesystem. _img_info already filters it out, use the function in 082. Signed-off-by: Michael Mueller <mimu@linux.vnet.ibm.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-11-27 19:28:01 +03:00
image: TEST_DIR/t.IMGFMT.base
file format: IMGFMT
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
virtual size: 128M (134217728 bytes)
cluster_size: 8192
Format specific information:
compat: 1.1
lazy refcounts: true
qcow2: Add refcount_bits to format-specific info Add the bit width of every refcount entry to the format-specific information. In contrast to lazy_refcounts and the corrupt flag, this should be always emitted, even for compat=0.10 although it does not support any refcount width other than 16 bits. This is because if a boolean is optional, one normally assumes it to be false when omitted; but if an integer is not specified, it is rather difficult to guess its value. This new field breaks some test outputs, fix them. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2015-02-10 23:28:44 +03:00
refcount bits: 16
qapi: Add corrupt field to ImageInfoSpecificQCow2 Just like lazy-refcounts, this field will be present iff the qcow2 compat level is 1.1 (or probably any future revision). As expected, this breaks some tests due to the new field present in qemu-img info output; so fix their output accordingly. Suggested-by: Eric Blake <eblake@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 1412105489-7681-3-git-send-email-mreitz@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2014-09-30 23:31:28 +04:00
corrupt: false
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
Testing: convert -O qcow2 -o cluster_size=4k,cluster_size=8k TEST_DIR/t.qcow2 TEST_DIR/t.qcow2.base
iotests: Use _img_info qemu-img info should only be used directly if the format-specific information or the name of the format is relevant (some tests explicitly test format-specific information; test 082 uses qcow2-specific settings to test the qemu-img interface); otherwise, tests should always use _img_info instead. Test 082 was touched only partially. It does test the qemu-img interface; however, its invocations of qemu-img info are not real tests but rather verifications, so if format-specific information is not important for the test, there is no reason not to use _img_info. In contrast to directly invoking qemu-img info, "qcow2" is replaced by "IMGFMT"; but as "qcow2" is only mentioned once in test 082 (in _supported_fmt), I consider this an improvement. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 1412105489-7681-2-git-send-email-mreitz@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2014-09-30 23:31:27 +04:00
image: TEST_DIR/t.IMGFMT.base
file format: IMGFMT
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
virtual size: 128M (134217728 bytes)
cluster_size: 8192
=== convert: help for -o ===
Testing: convert -O qcow2 -o help TEST_DIR/t.qcow2 TEST_DIR/t.qcow2.base
Supported options:
size Virtual disk size
compat Compatibility level (0.10 or 1.1)
backing_file File name of a base image
backing_fmt Image format of the base image
block: deprecate "encryption=on" in favor of "encrypt.format=aes" Historically the qcow & qcow2 image formats supported a property "encryption=on" to enable their built-in AES encryption. We'll soon be supporting LUKS for qcow2, so need a more general purpose way to enable encryption, with a choice of formats. This introduces an "encrypt.format" option, which will later be joined by a number of other "encrypt.XXX" options. The use of a "encrypt." prefix instead of "encrypt-" is done to facilitate mapping to a nested QAPI schema at later date. e.g. the preferred syntax is now qemu-img create -f qcow2 -o encrypt.format=aes demo.qcow2 Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-8-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:06 +03:00
encryption Encrypt the image with format 'aes'. (Deprecated in favor of encrypt.format=aes)
qcow2: add support for LUKS encryption format This adds support for using LUKS as an encryption format with the qcow2 file, using the new encrypt.format parameter to request "luks" format. e.g. # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 \ test.qcow2 10G The legacy "encryption=on" parameter still results in creation of the old qcow2 AES format (and is equivalent to the new 'encryption-format=aes'). e.g. the following are equivalent: # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption=on,encrypt.key-secret=sec0 \ test.qcow2 10G # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption-format=aes,encrypt.key-secret=sec0 \ test.qcow2 10G With the LUKS format it is necessary to store the LUKS partition header and key material in the QCow2 file. This data can be many MB in size, so cannot go into the QCow2 header region directly. Thus the spec defines a FDE (Full Disk Encryption) header extension that specifies the offset of a set of clusters to hold the FDE headers, as well as the length of that region. The LUKS header is thus stored in these extra allocated clusters before the main image payload. Aside from all the cryptographic differences implied by use of the LUKS format, there is one further key difference between the use of legacy AES and LUKS encryption in qcow2. For LUKS, the initialiazation vectors are generated using the host physical sector as the input, rather than the guest virtual sector. This guarantees unique initialization vectors for all sectors when qcow2 internal snapshots are used, thus giving stronger protection against watermarking attacks. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-14-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:12 +03:00
encrypt.format Encrypt the image, format choices: 'aes', 'luks'
encrypt.key-secret ID of secret providing qcow AES key or LUKS passphrase
encrypt.cipher-alg Name of encryption cipher algorithm
encrypt.cipher-mode Name of encryption cipher mode
encrypt.ivgen-alg Name of IV generator algorithm
encrypt.ivgen-hash-alg Name of IV generator hash algorithm
encrypt.hash-alg Name of encryption hash algorithm
encrypt.iter-time Time to spend in PBKDF in milliseconds
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
cluster_size qcow2 cluster size
qcow2: Add falloc and full preallocation option preallocation=falloc allocates disk space by posix_fallocate(), preallocation=full allocates disk space by writing zeros to disk. Both modes imply preallocation=metadata. Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-09-10 13:05:49 +04:00
preallocation Preallocation mode (allowed values: off, metadata, falloc, full)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
lazy_refcounts Postpone refcount updates
qcow2: Allow creation with refcount order != 4 Add a creation option to qcow2 for setting the refcount order of images to be created, and respect that option's value. This breaks some test outputs, fix them. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2015-02-19 01:40:49 +03:00
refcount_bits Width of a reference count entry in bits
qemu-img create: add 'nocow' option Add 'nocow' option so that users could have a chance to set NOCOW flag to newly created files. It's useful on btrfs file system to enhance performance. Btrfs has low performance when hosting VM images, even more when the guest in those VM are also using btrfs as file system. One way to mitigate this bad performance is to turn off COW attributes on VM files. Generally, there are two ways to turn off NOCOW on btrfs: a) by mounting fs with nodatacow, then all newly created files will be NOCOW. b) per file. Add the NOCOW file attribute. It could only be done to empty or new files. This patch tries the second way, according to the option, it could add NOCOW per file. For most block drivers, since the create file step is in raw-posix.c, so we can do setting NOCOW flag ioctl in raw-posix.c only. But there are some exceptions, like block/vpc.c and block/vdi.c, they are creating file by calling qemu_open directly. For them, do the same setting NOCOW flag ioctl work in them separately. [Fixed up 082.out due to the new 'nocow' creation option --Stefan] Signed-off-by: Chunyan Liu <cyliu@suse.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2014-06-30 10:29:58 +04:00
nocow Turn off copy-on-write (valid only on btrfs)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
Testing: convert -O qcow2 -o ? TEST_DIR/t.qcow2 TEST_DIR/t.qcow2.base
Supported options:
size Virtual disk size
compat Compatibility level (0.10 or 1.1)
backing_file File name of a base image
backing_fmt Image format of the base image
block: deprecate "encryption=on" in favor of "encrypt.format=aes" Historically the qcow & qcow2 image formats supported a property "encryption=on" to enable their built-in AES encryption. We'll soon be supporting LUKS for qcow2, so need a more general purpose way to enable encryption, with a choice of formats. This introduces an "encrypt.format" option, which will later be joined by a number of other "encrypt.XXX" options. The use of a "encrypt." prefix instead of "encrypt-" is done to facilitate mapping to a nested QAPI schema at later date. e.g. the preferred syntax is now qemu-img create -f qcow2 -o encrypt.format=aes demo.qcow2 Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-8-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:06 +03:00
encryption Encrypt the image with format 'aes'. (Deprecated in favor of encrypt.format=aes)
qcow2: add support for LUKS encryption format This adds support for using LUKS as an encryption format with the qcow2 file, using the new encrypt.format parameter to request "luks" format. e.g. # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 \ test.qcow2 10G The legacy "encryption=on" parameter still results in creation of the old qcow2 AES format (and is equivalent to the new 'encryption-format=aes'). e.g. the following are equivalent: # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption=on,encrypt.key-secret=sec0 \ test.qcow2 10G # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption-format=aes,encrypt.key-secret=sec0 \ test.qcow2 10G With the LUKS format it is necessary to store the LUKS partition header and key material in the QCow2 file. This data can be many MB in size, so cannot go into the QCow2 header region directly. Thus the spec defines a FDE (Full Disk Encryption) header extension that specifies the offset of a set of clusters to hold the FDE headers, as well as the length of that region. The LUKS header is thus stored in these extra allocated clusters before the main image payload. Aside from all the cryptographic differences implied by use of the LUKS format, there is one further key difference between the use of legacy AES and LUKS encryption in qcow2. For LUKS, the initialiazation vectors are generated using the host physical sector as the input, rather than the guest virtual sector. This guarantees unique initialization vectors for all sectors when qcow2 internal snapshots are used, thus giving stronger protection against watermarking attacks. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-14-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:12 +03:00
encrypt.format Encrypt the image, format choices: 'aes', 'luks'
encrypt.key-secret ID of secret providing qcow AES key or LUKS passphrase
encrypt.cipher-alg Name of encryption cipher algorithm
encrypt.cipher-mode Name of encryption cipher mode
encrypt.ivgen-alg Name of IV generator algorithm
encrypt.ivgen-hash-alg Name of IV generator hash algorithm
encrypt.hash-alg Name of encryption hash algorithm
encrypt.iter-time Time to spend in PBKDF in milliseconds
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
cluster_size qcow2 cluster size
qcow2: Add falloc and full preallocation option preallocation=falloc allocates disk space by posix_fallocate(), preallocation=full allocates disk space by writing zeros to disk. Both modes imply preallocation=metadata. Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-09-10 13:05:49 +04:00
preallocation Preallocation mode (allowed values: off, metadata, falloc, full)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
lazy_refcounts Postpone refcount updates
qcow2: Allow creation with refcount order != 4 Add a creation option to qcow2 for setting the refcount order of images to be created, and respect that option's value. This breaks some test outputs, fix them. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2015-02-19 01:40:49 +03:00
refcount_bits Width of a reference count entry in bits
qemu-img create: add 'nocow' option Add 'nocow' option so that users could have a chance to set NOCOW flag to newly created files. It's useful on btrfs file system to enhance performance. Btrfs has low performance when hosting VM images, even more when the guest in those VM are also using btrfs as file system. One way to mitigate this bad performance is to turn off COW attributes on VM files. Generally, there are two ways to turn off NOCOW on btrfs: a) by mounting fs with nodatacow, then all newly created files will be NOCOW. b) per file. Add the NOCOW file attribute. It could only be done to empty or new files. This patch tries the second way, according to the option, it could add NOCOW per file. For most block drivers, since the create file step is in raw-posix.c, so we can do setting NOCOW flag ioctl in raw-posix.c only. But there are some exceptions, like block/vpc.c and block/vdi.c, they are creating file by calling qemu_open directly. For them, do the same setting NOCOW flag ioctl work in them separately. [Fixed up 082.out due to the new 'nocow' creation option --Stefan] Signed-off-by: Chunyan Liu <cyliu@suse.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2014-06-30 10:29:58 +04:00
nocow Turn off copy-on-write (valid only on btrfs)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
Testing: convert -O qcow2 -o cluster_size=4k,help TEST_DIR/t.qcow2 TEST_DIR/t.qcow2.base
Supported options:
size Virtual disk size
compat Compatibility level (0.10 or 1.1)
backing_file File name of a base image
backing_fmt Image format of the base image
block: deprecate "encryption=on" in favor of "encrypt.format=aes" Historically the qcow & qcow2 image formats supported a property "encryption=on" to enable their built-in AES encryption. We'll soon be supporting LUKS for qcow2, so need a more general purpose way to enable encryption, with a choice of formats. This introduces an "encrypt.format" option, which will later be joined by a number of other "encrypt.XXX" options. The use of a "encrypt." prefix instead of "encrypt-" is done to facilitate mapping to a nested QAPI schema at later date. e.g. the preferred syntax is now qemu-img create -f qcow2 -o encrypt.format=aes demo.qcow2 Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-8-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:06 +03:00
encryption Encrypt the image with format 'aes'. (Deprecated in favor of encrypt.format=aes)
qcow2: add support for LUKS encryption format This adds support for using LUKS as an encryption format with the qcow2 file, using the new encrypt.format parameter to request "luks" format. e.g. # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 \ test.qcow2 10G The legacy "encryption=on" parameter still results in creation of the old qcow2 AES format (and is equivalent to the new 'encryption-format=aes'). e.g. the following are equivalent: # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption=on,encrypt.key-secret=sec0 \ test.qcow2 10G # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption-format=aes,encrypt.key-secret=sec0 \ test.qcow2 10G With the LUKS format it is necessary to store the LUKS partition header and key material in the QCow2 file. This data can be many MB in size, so cannot go into the QCow2 header region directly. Thus the spec defines a FDE (Full Disk Encryption) header extension that specifies the offset of a set of clusters to hold the FDE headers, as well as the length of that region. The LUKS header is thus stored in these extra allocated clusters before the main image payload. Aside from all the cryptographic differences implied by use of the LUKS format, there is one further key difference between the use of legacy AES and LUKS encryption in qcow2. For LUKS, the initialiazation vectors are generated using the host physical sector as the input, rather than the guest virtual sector. This guarantees unique initialization vectors for all sectors when qcow2 internal snapshots are used, thus giving stronger protection against watermarking attacks. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-14-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:12 +03:00
encrypt.format Encrypt the image, format choices: 'aes', 'luks'
encrypt.key-secret ID of secret providing qcow AES key or LUKS passphrase
encrypt.cipher-alg Name of encryption cipher algorithm
encrypt.cipher-mode Name of encryption cipher mode
encrypt.ivgen-alg Name of IV generator algorithm
encrypt.ivgen-hash-alg Name of IV generator hash algorithm
encrypt.hash-alg Name of encryption hash algorithm
encrypt.iter-time Time to spend in PBKDF in milliseconds
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
cluster_size qcow2 cluster size
qcow2: Add falloc and full preallocation option preallocation=falloc allocates disk space by posix_fallocate(), preallocation=full allocates disk space by writing zeros to disk. Both modes imply preallocation=metadata. Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-09-10 13:05:49 +04:00
preallocation Preallocation mode (allowed values: off, metadata, falloc, full)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
lazy_refcounts Postpone refcount updates
qcow2: Allow creation with refcount order != 4 Add a creation option to qcow2 for setting the refcount order of images to be created, and respect that option's value. This breaks some test outputs, fix them. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2015-02-19 01:40:49 +03:00
refcount_bits Width of a reference count entry in bits
qemu-img create: add 'nocow' option Add 'nocow' option so that users could have a chance to set NOCOW flag to newly created files. It's useful on btrfs file system to enhance performance. Btrfs has low performance when hosting VM images, even more when the guest in those VM are also using btrfs as file system. One way to mitigate this bad performance is to turn off COW attributes on VM files. Generally, there are two ways to turn off NOCOW on btrfs: a) by mounting fs with nodatacow, then all newly created files will be NOCOW. b) per file. Add the NOCOW file attribute. It could only be done to empty or new files. This patch tries the second way, according to the option, it could add NOCOW per file. For most block drivers, since the create file step is in raw-posix.c, so we can do setting NOCOW flag ioctl in raw-posix.c only. But there are some exceptions, like block/vpc.c and block/vdi.c, they are creating file by calling qemu_open directly. For them, do the same setting NOCOW flag ioctl work in them separately. [Fixed up 082.out due to the new 'nocow' creation option --Stefan] Signed-off-by: Chunyan Liu <cyliu@suse.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2014-06-30 10:29:58 +04:00
nocow Turn off copy-on-write (valid only on btrfs)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
Testing: convert -O qcow2 -o cluster_size=4k,? TEST_DIR/t.qcow2 TEST_DIR/t.qcow2.base
Supported options:
size Virtual disk size
compat Compatibility level (0.10 or 1.1)
backing_file File name of a base image
backing_fmt Image format of the base image
block: deprecate "encryption=on" in favor of "encrypt.format=aes" Historically the qcow & qcow2 image formats supported a property "encryption=on" to enable their built-in AES encryption. We'll soon be supporting LUKS for qcow2, so need a more general purpose way to enable encryption, with a choice of formats. This introduces an "encrypt.format" option, which will later be joined by a number of other "encrypt.XXX" options. The use of a "encrypt." prefix instead of "encrypt-" is done to facilitate mapping to a nested QAPI schema at later date. e.g. the preferred syntax is now qemu-img create -f qcow2 -o encrypt.format=aes demo.qcow2 Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-8-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:06 +03:00
encryption Encrypt the image with format 'aes'. (Deprecated in favor of encrypt.format=aes)
qcow2: add support for LUKS encryption format This adds support for using LUKS as an encryption format with the qcow2 file, using the new encrypt.format parameter to request "luks" format. e.g. # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 \ test.qcow2 10G The legacy "encryption=on" parameter still results in creation of the old qcow2 AES format (and is equivalent to the new 'encryption-format=aes'). e.g. the following are equivalent: # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption=on,encrypt.key-secret=sec0 \ test.qcow2 10G # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption-format=aes,encrypt.key-secret=sec0 \ test.qcow2 10G With the LUKS format it is necessary to store the LUKS partition header and key material in the QCow2 file. This data can be many MB in size, so cannot go into the QCow2 header region directly. Thus the spec defines a FDE (Full Disk Encryption) header extension that specifies the offset of a set of clusters to hold the FDE headers, as well as the length of that region. The LUKS header is thus stored in these extra allocated clusters before the main image payload. Aside from all the cryptographic differences implied by use of the LUKS format, there is one further key difference between the use of legacy AES and LUKS encryption in qcow2. For LUKS, the initialiazation vectors are generated using the host physical sector as the input, rather than the guest virtual sector. This guarantees unique initialization vectors for all sectors when qcow2 internal snapshots are used, thus giving stronger protection against watermarking attacks. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-14-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:12 +03:00
encrypt.format Encrypt the image, format choices: 'aes', 'luks'
encrypt.key-secret ID of secret providing qcow AES key or LUKS passphrase
encrypt.cipher-alg Name of encryption cipher algorithm
encrypt.cipher-mode Name of encryption cipher mode
encrypt.ivgen-alg Name of IV generator algorithm
encrypt.ivgen-hash-alg Name of IV generator hash algorithm
encrypt.hash-alg Name of encryption hash algorithm
encrypt.iter-time Time to spend in PBKDF in milliseconds
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
cluster_size qcow2 cluster size
qcow2: Add falloc and full preallocation option preallocation=falloc allocates disk space by posix_fallocate(), preallocation=full allocates disk space by writing zeros to disk. Both modes imply preallocation=metadata. Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-09-10 13:05:49 +04:00
preallocation Preallocation mode (allowed values: off, metadata, falloc, full)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
lazy_refcounts Postpone refcount updates
qcow2: Allow creation with refcount order != 4 Add a creation option to qcow2 for setting the refcount order of images to be created, and respect that option's value. This breaks some test outputs, fix them. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2015-02-19 01:40:49 +03:00
refcount_bits Width of a reference count entry in bits
qemu-img create: add 'nocow' option Add 'nocow' option so that users could have a chance to set NOCOW flag to newly created files. It's useful on btrfs file system to enhance performance. Btrfs has low performance when hosting VM images, even more when the guest in those VM are also using btrfs as file system. One way to mitigate this bad performance is to turn off COW attributes on VM files. Generally, there are two ways to turn off NOCOW on btrfs: a) by mounting fs with nodatacow, then all newly created files will be NOCOW. b) per file. Add the NOCOW file attribute. It could only be done to empty or new files. This patch tries the second way, according to the option, it could add NOCOW per file. For most block drivers, since the create file step is in raw-posix.c, so we can do setting NOCOW flag ioctl in raw-posix.c only. But there are some exceptions, like block/vpc.c and block/vdi.c, they are creating file by calling qemu_open directly. For them, do the same setting NOCOW flag ioctl work in them separately. [Fixed up 082.out due to the new 'nocow' creation option --Stefan] Signed-off-by: Chunyan Liu <cyliu@suse.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2014-06-30 10:29:58 +04:00
nocow Turn off copy-on-write (valid only on btrfs)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
Testing: convert -O qcow2 -o help,cluster_size=4k TEST_DIR/t.qcow2 TEST_DIR/t.qcow2.base
Supported options:
size Virtual disk size
compat Compatibility level (0.10 or 1.1)
backing_file File name of a base image
backing_fmt Image format of the base image
block: deprecate "encryption=on" in favor of "encrypt.format=aes" Historically the qcow & qcow2 image formats supported a property "encryption=on" to enable their built-in AES encryption. We'll soon be supporting LUKS for qcow2, so need a more general purpose way to enable encryption, with a choice of formats. This introduces an "encrypt.format" option, which will later be joined by a number of other "encrypt.XXX" options. The use of a "encrypt." prefix instead of "encrypt-" is done to facilitate mapping to a nested QAPI schema at later date. e.g. the preferred syntax is now qemu-img create -f qcow2 -o encrypt.format=aes demo.qcow2 Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-8-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:06 +03:00
encryption Encrypt the image with format 'aes'. (Deprecated in favor of encrypt.format=aes)
qcow2: add support for LUKS encryption format This adds support for using LUKS as an encryption format with the qcow2 file, using the new encrypt.format parameter to request "luks" format. e.g. # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 \ test.qcow2 10G The legacy "encryption=on" parameter still results in creation of the old qcow2 AES format (and is equivalent to the new 'encryption-format=aes'). e.g. the following are equivalent: # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption=on,encrypt.key-secret=sec0 \ test.qcow2 10G # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption-format=aes,encrypt.key-secret=sec0 \ test.qcow2 10G With the LUKS format it is necessary to store the LUKS partition header and key material in the QCow2 file. This data can be many MB in size, so cannot go into the QCow2 header region directly. Thus the spec defines a FDE (Full Disk Encryption) header extension that specifies the offset of a set of clusters to hold the FDE headers, as well as the length of that region. The LUKS header is thus stored in these extra allocated clusters before the main image payload. Aside from all the cryptographic differences implied by use of the LUKS format, there is one further key difference between the use of legacy AES and LUKS encryption in qcow2. For LUKS, the initialiazation vectors are generated using the host physical sector as the input, rather than the guest virtual sector. This guarantees unique initialization vectors for all sectors when qcow2 internal snapshots are used, thus giving stronger protection against watermarking attacks. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-14-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:12 +03:00
encrypt.format Encrypt the image, format choices: 'aes', 'luks'
encrypt.key-secret ID of secret providing qcow AES key or LUKS passphrase
encrypt.cipher-alg Name of encryption cipher algorithm
encrypt.cipher-mode Name of encryption cipher mode
encrypt.ivgen-alg Name of IV generator algorithm
encrypt.ivgen-hash-alg Name of IV generator hash algorithm
encrypt.hash-alg Name of encryption hash algorithm
encrypt.iter-time Time to spend in PBKDF in milliseconds
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
cluster_size qcow2 cluster size
qcow2: Add falloc and full preallocation option preallocation=falloc allocates disk space by posix_fallocate(), preallocation=full allocates disk space by writing zeros to disk. Both modes imply preallocation=metadata. Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-09-10 13:05:49 +04:00
preallocation Preallocation mode (allowed values: off, metadata, falloc, full)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
lazy_refcounts Postpone refcount updates
qcow2: Allow creation with refcount order != 4 Add a creation option to qcow2 for setting the refcount order of images to be created, and respect that option's value. This breaks some test outputs, fix them. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2015-02-19 01:40:49 +03:00
refcount_bits Width of a reference count entry in bits
qemu-img create: add 'nocow' option Add 'nocow' option so that users could have a chance to set NOCOW flag to newly created files. It's useful on btrfs file system to enhance performance. Btrfs has low performance when hosting VM images, even more when the guest in those VM are also using btrfs as file system. One way to mitigate this bad performance is to turn off COW attributes on VM files. Generally, there are two ways to turn off NOCOW on btrfs: a) by mounting fs with nodatacow, then all newly created files will be NOCOW. b) per file. Add the NOCOW file attribute. It could only be done to empty or new files. This patch tries the second way, according to the option, it could add NOCOW per file. For most block drivers, since the create file step is in raw-posix.c, so we can do setting NOCOW flag ioctl in raw-posix.c only. But there are some exceptions, like block/vpc.c and block/vdi.c, they are creating file by calling qemu_open directly. For them, do the same setting NOCOW flag ioctl work in them separately. [Fixed up 082.out due to the new 'nocow' creation option --Stefan] Signed-off-by: Chunyan Liu <cyliu@suse.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2014-06-30 10:29:58 +04:00
nocow Turn off copy-on-write (valid only on btrfs)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
Testing: convert -O qcow2 -o ?,cluster_size=4k TEST_DIR/t.qcow2 TEST_DIR/t.qcow2.base
Supported options:
size Virtual disk size
compat Compatibility level (0.10 or 1.1)
backing_file File name of a base image
backing_fmt Image format of the base image
block: deprecate "encryption=on" in favor of "encrypt.format=aes" Historically the qcow & qcow2 image formats supported a property "encryption=on" to enable their built-in AES encryption. We'll soon be supporting LUKS for qcow2, so need a more general purpose way to enable encryption, with a choice of formats. This introduces an "encrypt.format" option, which will later be joined by a number of other "encrypt.XXX" options. The use of a "encrypt." prefix instead of "encrypt-" is done to facilitate mapping to a nested QAPI schema at later date. e.g. the preferred syntax is now qemu-img create -f qcow2 -o encrypt.format=aes demo.qcow2 Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-8-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:06 +03:00
encryption Encrypt the image with format 'aes'. (Deprecated in favor of encrypt.format=aes)
qcow2: add support for LUKS encryption format This adds support for using LUKS as an encryption format with the qcow2 file, using the new encrypt.format parameter to request "luks" format. e.g. # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 \ test.qcow2 10G The legacy "encryption=on" parameter still results in creation of the old qcow2 AES format (and is equivalent to the new 'encryption-format=aes'). e.g. the following are equivalent: # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption=on,encrypt.key-secret=sec0 \ test.qcow2 10G # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption-format=aes,encrypt.key-secret=sec0 \ test.qcow2 10G With the LUKS format it is necessary to store the LUKS partition header and key material in the QCow2 file. This data can be many MB in size, so cannot go into the QCow2 header region directly. Thus the spec defines a FDE (Full Disk Encryption) header extension that specifies the offset of a set of clusters to hold the FDE headers, as well as the length of that region. The LUKS header is thus stored in these extra allocated clusters before the main image payload. Aside from all the cryptographic differences implied by use of the LUKS format, there is one further key difference between the use of legacy AES and LUKS encryption in qcow2. For LUKS, the initialiazation vectors are generated using the host physical sector as the input, rather than the guest virtual sector. This guarantees unique initialization vectors for all sectors when qcow2 internal snapshots are used, thus giving stronger protection against watermarking attacks. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-14-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:12 +03:00
encrypt.format Encrypt the image, format choices: 'aes', 'luks'
encrypt.key-secret ID of secret providing qcow AES key or LUKS passphrase
encrypt.cipher-alg Name of encryption cipher algorithm
encrypt.cipher-mode Name of encryption cipher mode
encrypt.ivgen-alg Name of IV generator algorithm
encrypt.ivgen-hash-alg Name of IV generator hash algorithm
encrypt.hash-alg Name of encryption hash algorithm
encrypt.iter-time Time to spend in PBKDF in milliseconds
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
cluster_size qcow2 cluster size
qcow2: Add falloc and full preallocation option preallocation=falloc allocates disk space by posix_fallocate(), preallocation=full allocates disk space by writing zeros to disk. Both modes imply preallocation=metadata. Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-09-10 13:05:49 +04:00
preallocation Preallocation mode (allowed values: off, metadata, falloc, full)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
lazy_refcounts Postpone refcount updates
qcow2: Allow creation with refcount order != 4 Add a creation option to qcow2 for setting the refcount order of images to be created, and respect that option's value. This breaks some test outputs, fix them. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2015-02-19 01:40:49 +03:00
refcount_bits Width of a reference count entry in bits
qemu-img create: add 'nocow' option Add 'nocow' option so that users could have a chance to set NOCOW flag to newly created files. It's useful on btrfs file system to enhance performance. Btrfs has low performance when hosting VM images, even more when the guest in those VM are also using btrfs as file system. One way to mitigate this bad performance is to turn off COW attributes on VM files. Generally, there are two ways to turn off NOCOW on btrfs: a) by mounting fs with nodatacow, then all newly created files will be NOCOW. b) per file. Add the NOCOW file attribute. It could only be done to empty or new files. This patch tries the second way, according to the option, it could add NOCOW per file. For most block drivers, since the create file step is in raw-posix.c, so we can do setting NOCOW flag ioctl in raw-posix.c only. But there are some exceptions, like block/vpc.c and block/vdi.c, they are creating file by calling qemu_open directly. For them, do the same setting NOCOW flag ioctl work in them separately. [Fixed up 082.out due to the new 'nocow' creation option --Stefan] Signed-off-by: Chunyan Liu <cyliu@suse.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2014-06-30 10:29:58 +04:00
nocow Turn off copy-on-write (valid only on btrfs)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
Testing: convert -O qcow2 -o cluster_size=4k -o help TEST_DIR/t.qcow2 TEST_DIR/t.qcow2.base
Supported options:
size Virtual disk size
compat Compatibility level (0.10 or 1.1)
backing_file File name of a base image
backing_fmt Image format of the base image
block: deprecate "encryption=on" in favor of "encrypt.format=aes" Historically the qcow & qcow2 image formats supported a property "encryption=on" to enable their built-in AES encryption. We'll soon be supporting LUKS for qcow2, so need a more general purpose way to enable encryption, with a choice of formats. This introduces an "encrypt.format" option, which will later be joined by a number of other "encrypt.XXX" options. The use of a "encrypt." prefix instead of "encrypt-" is done to facilitate mapping to a nested QAPI schema at later date. e.g. the preferred syntax is now qemu-img create -f qcow2 -o encrypt.format=aes demo.qcow2 Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-8-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:06 +03:00
encryption Encrypt the image with format 'aes'. (Deprecated in favor of encrypt.format=aes)
qcow2: add support for LUKS encryption format This adds support for using LUKS as an encryption format with the qcow2 file, using the new encrypt.format parameter to request "luks" format. e.g. # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 \ test.qcow2 10G The legacy "encryption=on" parameter still results in creation of the old qcow2 AES format (and is equivalent to the new 'encryption-format=aes'). e.g. the following are equivalent: # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption=on,encrypt.key-secret=sec0 \ test.qcow2 10G # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption-format=aes,encrypt.key-secret=sec0 \ test.qcow2 10G With the LUKS format it is necessary to store the LUKS partition header and key material in the QCow2 file. This data can be many MB in size, so cannot go into the QCow2 header region directly. Thus the spec defines a FDE (Full Disk Encryption) header extension that specifies the offset of a set of clusters to hold the FDE headers, as well as the length of that region. The LUKS header is thus stored in these extra allocated clusters before the main image payload. Aside from all the cryptographic differences implied by use of the LUKS format, there is one further key difference between the use of legacy AES and LUKS encryption in qcow2. For LUKS, the initialiazation vectors are generated using the host physical sector as the input, rather than the guest virtual sector. This guarantees unique initialization vectors for all sectors when qcow2 internal snapshots are used, thus giving stronger protection against watermarking attacks. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-14-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:12 +03:00
encrypt.format Encrypt the image, format choices: 'aes', 'luks'
encrypt.key-secret ID of secret providing qcow AES key or LUKS passphrase
encrypt.cipher-alg Name of encryption cipher algorithm
encrypt.cipher-mode Name of encryption cipher mode
encrypt.ivgen-alg Name of IV generator algorithm
encrypt.ivgen-hash-alg Name of IV generator hash algorithm
encrypt.hash-alg Name of encryption hash algorithm
encrypt.iter-time Time to spend in PBKDF in milliseconds
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
cluster_size qcow2 cluster size
qcow2: Add falloc and full preallocation option preallocation=falloc allocates disk space by posix_fallocate(), preallocation=full allocates disk space by writing zeros to disk. Both modes imply preallocation=metadata. Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-09-10 13:05:49 +04:00
preallocation Preallocation mode (allowed values: off, metadata, falloc, full)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
lazy_refcounts Postpone refcount updates
qcow2: Allow creation with refcount order != 4 Add a creation option to qcow2 for setting the refcount order of images to be created, and respect that option's value. This breaks some test outputs, fix them. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2015-02-19 01:40:49 +03:00
refcount_bits Width of a reference count entry in bits
qemu-img create: add 'nocow' option Add 'nocow' option so that users could have a chance to set NOCOW flag to newly created files. It's useful on btrfs file system to enhance performance. Btrfs has low performance when hosting VM images, even more when the guest in those VM are also using btrfs as file system. One way to mitigate this bad performance is to turn off COW attributes on VM files. Generally, there are two ways to turn off NOCOW on btrfs: a) by mounting fs with nodatacow, then all newly created files will be NOCOW. b) per file. Add the NOCOW file attribute. It could only be done to empty or new files. This patch tries the second way, according to the option, it could add NOCOW per file. For most block drivers, since the create file step is in raw-posix.c, so we can do setting NOCOW flag ioctl in raw-posix.c only. But there are some exceptions, like block/vpc.c and block/vdi.c, they are creating file by calling qemu_open directly. For them, do the same setting NOCOW flag ioctl work in them separately. [Fixed up 082.out due to the new 'nocow' creation option --Stefan] Signed-off-by: Chunyan Liu <cyliu@suse.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2014-06-30 10:29:58 +04:00
nocow Turn off copy-on-write (valid only on btrfs)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
Testing: convert -O qcow2 -o cluster_size=4k -o ? TEST_DIR/t.qcow2 TEST_DIR/t.qcow2.base
Supported options:
size Virtual disk size
compat Compatibility level (0.10 or 1.1)
backing_file File name of a base image
backing_fmt Image format of the base image
block: deprecate "encryption=on" in favor of "encrypt.format=aes" Historically the qcow & qcow2 image formats supported a property "encryption=on" to enable their built-in AES encryption. We'll soon be supporting LUKS for qcow2, so need a more general purpose way to enable encryption, with a choice of formats. This introduces an "encrypt.format" option, which will later be joined by a number of other "encrypt.XXX" options. The use of a "encrypt." prefix instead of "encrypt-" is done to facilitate mapping to a nested QAPI schema at later date. e.g. the preferred syntax is now qemu-img create -f qcow2 -o encrypt.format=aes demo.qcow2 Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-8-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:06 +03:00
encryption Encrypt the image with format 'aes'. (Deprecated in favor of encrypt.format=aes)
qcow2: add support for LUKS encryption format This adds support for using LUKS as an encryption format with the qcow2 file, using the new encrypt.format parameter to request "luks" format. e.g. # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 \ test.qcow2 10G The legacy "encryption=on" parameter still results in creation of the old qcow2 AES format (and is equivalent to the new 'encryption-format=aes'). e.g. the following are equivalent: # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption=on,encrypt.key-secret=sec0 \ test.qcow2 10G # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption-format=aes,encrypt.key-secret=sec0 \ test.qcow2 10G With the LUKS format it is necessary to store the LUKS partition header and key material in the QCow2 file. This data can be many MB in size, so cannot go into the QCow2 header region directly. Thus the spec defines a FDE (Full Disk Encryption) header extension that specifies the offset of a set of clusters to hold the FDE headers, as well as the length of that region. The LUKS header is thus stored in these extra allocated clusters before the main image payload. Aside from all the cryptographic differences implied by use of the LUKS format, there is one further key difference between the use of legacy AES and LUKS encryption in qcow2. For LUKS, the initialiazation vectors are generated using the host physical sector as the input, rather than the guest virtual sector. This guarantees unique initialization vectors for all sectors when qcow2 internal snapshots are used, thus giving stronger protection against watermarking attacks. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-14-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:12 +03:00
encrypt.format Encrypt the image, format choices: 'aes', 'luks'
encrypt.key-secret ID of secret providing qcow AES key or LUKS passphrase
encrypt.cipher-alg Name of encryption cipher algorithm
encrypt.cipher-mode Name of encryption cipher mode
encrypt.ivgen-alg Name of IV generator algorithm
encrypt.ivgen-hash-alg Name of IV generator hash algorithm
encrypt.hash-alg Name of encryption hash algorithm
encrypt.iter-time Time to spend in PBKDF in milliseconds
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
cluster_size qcow2 cluster size
qcow2: Add falloc and full preallocation option preallocation=falloc allocates disk space by posix_fallocate(), preallocation=full allocates disk space by writing zeros to disk. Both modes imply preallocation=metadata. Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-09-10 13:05:49 +04:00
preallocation Preallocation mode (allowed values: off, metadata, falloc, full)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
lazy_refcounts Postpone refcount updates
qcow2: Allow creation with refcount order != 4 Add a creation option to qcow2 for setting the refcount order of images to be created, and respect that option's value. This breaks some test outputs, fix them. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2015-02-19 01:40:49 +03:00
refcount_bits Width of a reference count entry in bits
qemu-img create: add 'nocow' option Add 'nocow' option so that users could have a chance to set NOCOW flag to newly created files. It's useful on btrfs file system to enhance performance. Btrfs has low performance when hosting VM images, even more when the guest in those VM are also using btrfs as file system. One way to mitigate this bad performance is to turn off COW attributes on VM files. Generally, there are two ways to turn off NOCOW on btrfs: a) by mounting fs with nodatacow, then all newly created files will be NOCOW. b) per file. Add the NOCOW file attribute. It could only be done to empty or new files. This patch tries the second way, according to the option, it could add NOCOW per file. For most block drivers, since the create file step is in raw-posix.c, so we can do setting NOCOW flag ioctl in raw-posix.c only. But there are some exceptions, like block/vpc.c and block/vdi.c, they are creating file by calling qemu_open directly. For them, do the same setting NOCOW flag ioctl work in them separately. [Fixed up 082.out due to the new 'nocow' creation option --Stefan] Signed-off-by: Chunyan Liu <cyliu@suse.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2014-06-30 10:29:58 +04:00
nocow Turn off copy-on-write (valid only on btrfs)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
Testing: convert -O qcow2 -o backing_file=TEST_DIR/t.qcow2,,help TEST_DIR/t.qcow2 TEST_DIR/t.qcow2.base
qemu-img: Could not open 'TEST_DIR/t.qcow2.base': Could not open backing file: Could not open 'TEST_DIR/t.qcow2,help': No such file or directory
Testing: convert -O qcow2 -o backing_file=TEST_DIR/t.qcow2,,? TEST_DIR/t.qcow2 TEST_DIR/t.qcow2.base
qemu-img: Could not open 'TEST_DIR/t.qcow2.base': Could not open backing file: Could not open 'TEST_DIR/t.qcow2,?': No such file or directory
Testing: convert -O qcow2 -o backing_file=TEST_DIR/t.qcow2, -o help TEST_DIR/t.qcow2 TEST_DIR/t.qcow2.base
qemu-img: Invalid option list: backing_file=TEST_DIR/t.qcow2,
Testing: convert -O qcow2 -o backing_file=TEST_DIR/t.qcow2 -o ,help TEST_DIR/t.qcow2 TEST_DIR/t.qcow2.base
qemu-img: Invalid option list: ,help
Testing: convert -O qcow2 -o backing_file=TEST_DIR/t.qcow2 -o ,, -o help TEST_DIR/t.qcow2 TEST_DIR/t.qcow2.base
qemu-img: Invalid option list: ,,
Testing: convert -O qcow2 -o help
Supported options:
size Virtual disk size
compat Compatibility level (0.10 or 1.1)
backing_file File name of a base image
backing_fmt Image format of the base image
block: deprecate "encryption=on" in favor of "encrypt.format=aes" Historically the qcow & qcow2 image formats supported a property "encryption=on" to enable their built-in AES encryption. We'll soon be supporting LUKS for qcow2, so need a more general purpose way to enable encryption, with a choice of formats. This introduces an "encrypt.format" option, which will later be joined by a number of other "encrypt.XXX" options. The use of a "encrypt." prefix instead of "encrypt-" is done to facilitate mapping to a nested QAPI schema at later date. e.g. the preferred syntax is now qemu-img create -f qcow2 -o encrypt.format=aes demo.qcow2 Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-8-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:06 +03:00
encryption Encrypt the image with format 'aes'. (Deprecated in favor of encrypt.format=aes)
qcow2: add support for LUKS encryption format This adds support for using LUKS as an encryption format with the qcow2 file, using the new encrypt.format parameter to request "luks" format. e.g. # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 \ test.qcow2 10G The legacy "encryption=on" parameter still results in creation of the old qcow2 AES format (and is equivalent to the new 'encryption-format=aes'). e.g. the following are equivalent: # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption=on,encrypt.key-secret=sec0 \ test.qcow2 10G # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption-format=aes,encrypt.key-secret=sec0 \ test.qcow2 10G With the LUKS format it is necessary to store the LUKS partition header and key material in the QCow2 file. This data can be many MB in size, so cannot go into the QCow2 header region directly. Thus the spec defines a FDE (Full Disk Encryption) header extension that specifies the offset of a set of clusters to hold the FDE headers, as well as the length of that region. The LUKS header is thus stored in these extra allocated clusters before the main image payload. Aside from all the cryptographic differences implied by use of the LUKS format, there is one further key difference between the use of legacy AES and LUKS encryption in qcow2. For LUKS, the initialiazation vectors are generated using the host physical sector as the input, rather than the guest virtual sector. This guarantees unique initialization vectors for all sectors when qcow2 internal snapshots are used, thus giving stronger protection against watermarking attacks. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-14-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:12 +03:00
encrypt.format Encrypt the image, format choices: 'aes', 'luks'
encrypt.key-secret ID of secret providing qcow AES key or LUKS passphrase
encrypt.cipher-alg Name of encryption cipher algorithm
encrypt.cipher-mode Name of encryption cipher mode
encrypt.ivgen-alg Name of IV generator algorithm
encrypt.ivgen-hash-alg Name of IV generator hash algorithm
encrypt.hash-alg Name of encryption hash algorithm
encrypt.iter-time Time to spend in PBKDF in milliseconds
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
cluster_size qcow2 cluster size
qcow2: Add falloc and full preallocation option preallocation=falloc allocates disk space by posix_fallocate(), preallocation=full allocates disk space by writing zeros to disk. Both modes imply preallocation=metadata. Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-09-10 13:05:49 +04:00
preallocation Preallocation mode (allowed values: off, metadata, falloc, full)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
lazy_refcounts Postpone refcount updates
qcow2: Allow creation with refcount order != 4 Add a creation option to qcow2 for setting the refcount order of images to be created, and respect that option's value. This breaks some test outputs, fix them. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2015-02-19 01:40:49 +03:00
refcount_bits Width of a reference count entry in bits
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
Testing: convert -o help
Supported options:
size Virtual disk size
iotests: Test help option for unsupporting formats This adds test cases to 082 for qemu-img create/convert/amend "-o help" on formats that do not support creation or amendment, respectively. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20180509210023.20283-7-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2018-05-10 00:00:22 +03:00
Testing: convert -O bochs -o help
qemu-img: Format driver 'bochs' does not support image creation
iotests: Add test for 'qemu-img convert -C' compatibility Signed-off-by: Fam Zheng <famz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-07-27 06:34:02 +03:00
=== convert: -C and other options ===
Testing: convert -C -S 4k -O qcow2 TEST_DIR/t.qcow2 TEST_DIR/t.qcow2.target
qemu-img: Cannot enable copy offloading when -S is used
Testing: convert -C -S 8k -O qcow2 TEST_DIR/t.qcow2 TEST_DIR/t.qcow2.target
qemu-img: Cannot enable copy offloading when -S is used
Testing: convert -C -c -O qcow2 TEST_DIR/t.qcow2 TEST_DIR/t.qcow2.target
qemu-img: Cannot enable copy offloading when -c is used
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
=== amend: Options specified more than once ===
Testing: amend -f foo -f qcow2 -o lazy_refcounts=on TEST_DIR/t.qcow2
qemu-iotests: 082: Filter the real disk size The real on-disk size of an image depends on things like the host filesystem. _img_info already filters it out, use the function in 082. Signed-off-by: Michael Mueller <mimu@linux.vnet.ibm.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-11-27 19:28:01 +03:00
image: TEST_DIR/t.IMGFMT
file format: IMGFMT
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
virtual size: 128M (134217728 bytes)
cluster_size: 65536
Format specific information:
compat: 1.1
lazy refcounts: true
qcow2: Add refcount_bits to format-specific info Add the bit width of every refcount entry to the format-specific information. In contrast to lazy_refcounts and the corrupt flag, this should be always emitted, even for compat=0.10 although it does not support any refcount width other than 16 bits. This is because if a boolean is optional, one normally assumes it to be false when omitted; but if an integer is not specified, it is rather difficult to guess its value. This new field breaks some test outputs, fix them. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2015-02-10 23:28:44 +03:00
refcount bits: 16
qapi: Add corrupt field to ImageInfoSpecificQCow2 Just like lazy-refcounts, this field will be present iff the qcow2 compat level is 1.1 (or probably any future revision). As expected, this breaks some tests due to the new field present in qemu-img info output; so fix their output accordingly. Suggested-by: Eric Blake <eblake@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 1412105489-7681-3-git-send-email-mreitz@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2014-09-30 23:31:28 +04:00
corrupt: false
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
Testing: amend -f qcow2 -o size=130M -o lazy_refcounts=off TEST_DIR/t.qcow2
qemu-iotests: 082: Filter the real disk size The real on-disk size of an image depends on things like the host filesystem. _img_info already filters it out, use the function in 082. Signed-off-by: Michael Mueller <mimu@linux.vnet.ibm.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-11-27 19:28:01 +03:00
image: TEST_DIR/t.IMGFMT
file format: IMGFMT
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
virtual size: 130M (136314880 bytes)
cluster_size: 65536
Format specific information:
compat: 1.1
lazy refcounts: false
qcow2: Add refcount_bits to format-specific info Add the bit width of every refcount entry to the format-specific information. In contrast to lazy_refcounts and the corrupt flag, this should be always emitted, even for compat=0.10 although it does not support any refcount width other than 16 bits. This is because if a boolean is optional, one normally assumes it to be false when omitted; but if an integer is not specified, it is rather difficult to guess its value. This new field breaks some test outputs, fix them. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2015-02-10 23:28:44 +03:00
refcount bits: 16
qapi: Add corrupt field to ImageInfoSpecificQCow2 Just like lazy-refcounts, this field will be present iff the qcow2 compat level is 1.1 (or probably any future revision). As expected, this breaks some tests due to the new field present in qemu-img info output; so fix their output accordingly. Suggested-by: Eric Blake <eblake@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 1412105489-7681-3-git-send-email-mreitz@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2014-09-30 23:31:28 +04:00
corrupt: false
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
Testing: amend -f qcow2 -o size=8M -o lazy_refcounts=on -o size=132M TEST_DIR/t.qcow2
qemu-iotests: 082: Filter the real disk size The real on-disk size of an image depends on things like the host filesystem. _img_info already filters it out, use the function in 082. Signed-off-by: Michael Mueller <mimu@linux.vnet.ibm.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-11-27 19:28:01 +03:00
image: TEST_DIR/t.IMGFMT
file format: IMGFMT
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
virtual size: 132M (138412032 bytes)
cluster_size: 65536
Format specific information:
compat: 1.1
lazy refcounts: true
qcow2: Add refcount_bits to format-specific info Add the bit width of every refcount entry to the format-specific information. In contrast to lazy_refcounts and the corrupt flag, this should be always emitted, even for compat=0.10 although it does not support any refcount width other than 16 bits. This is because if a boolean is optional, one normally assumes it to be false when omitted; but if an integer is not specified, it is rather difficult to guess its value. This new field breaks some test outputs, fix them. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2015-02-10 23:28:44 +03:00
refcount bits: 16
qapi: Add corrupt field to ImageInfoSpecificQCow2 Just like lazy-refcounts, this field will be present iff the qcow2 compat level is 1.1 (or probably any future revision). As expected, this breaks some tests due to the new field present in qemu-img info output; so fix their output accordingly. Suggested-by: Eric Blake <eblake@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 1412105489-7681-3-git-send-email-mreitz@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2014-09-30 23:31:28 +04:00
corrupt: false
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
Testing: amend -f qcow2 -o size=4M,size=148M TEST_DIR/t.qcow2
iotests: Use _img_info qemu-img info should only be used directly if the format-specific information or the name of the format is relevant (some tests explicitly test format-specific information; test 082 uses qcow2-specific settings to test the qemu-img interface); otherwise, tests should always use _img_info instead. Test 082 was touched only partially. It does test the qemu-img interface; however, its invocations of qemu-img info are not real tests but rather verifications, so if format-specific information is not important for the test, there is no reason not to use _img_info. In contrast to directly invoking qemu-img info, "qcow2" is replaced by "IMGFMT"; but as "qcow2" is only mentioned once in test 082 (in _supported_fmt), I consider this an improvement. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 1412105489-7681-2-git-send-email-mreitz@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2014-09-30 23:31:27 +04:00
image: TEST_DIR/t.IMGFMT
file format: IMGFMT
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
virtual size: 148M (155189248 bytes)
cluster_size: 65536
=== amend: help for -o ===
Testing: amend -f qcow2 -o help TEST_DIR/t.qcow2
qemu-img: Add print_amend_option_help() The more generic print_block_option_help() function is not really suitable for qemu-img amend, for a couple of reasons: (1) We do not need to append the protocol-level options, as amendment happens only on one node and does not descend downwards to its children. (2) print_block_option_help() says those options are "supported". For option amendment, we do not really know that. So this new function explicitly says that those options are the creation options, and not all of them may be supported. (3) If the driver does not support option amendment, we should not print anything (except for an error message that amendment is not supported). Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1537956 Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20180509210023.20283-5-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2018-05-10 00:00:20 +03:00
Creation options for 'qcow2':
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
size Virtual disk size
compat Compatibility level (0.10 or 1.1)
backing_file File name of a base image
backing_fmt Image format of the base image
block: deprecate "encryption=on" in favor of "encrypt.format=aes" Historically the qcow & qcow2 image formats supported a property "encryption=on" to enable their built-in AES encryption. We'll soon be supporting LUKS for qcow2, so need a more general purpose way to enable encryption, with a choice of formats. This introduces an "encrypt.format" option, which will later be joined by a number of other "encrypt.XXX" options. The use of a "encrypt." prefix instead of "encrypt-" is done to facilitate mapping to a nested QAPI schema at later date. e.g. the preferred syntax is now qemu-img create -f qcow2 -o encrypt.format=aes demo.qcow2 Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-8-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:06 +03:00
encryption Encrypt the image with format 'aes'. (Deprecated in favor of encrypt.format=aes)
qcow2: add support for LUKS encryption format This adds support for using LUKS as an encryption format with the qcow2 file, using the new encrypt.format parameter to request "luks" format. e.g. # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 \ test.qcow2 10G The legacy "encryption=on" parameter still results in creation of the old qcow2 AES format (and is equivalent to the new 'encryption-format=aes'). e.g. the following are equivalent: # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption=on,encrypt.key-secret=sec0 \ test.qcow2 10G # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption-format=aes,encrypt.key-secret=sec0 \ test.qcow2 10G With the LUKS format it is necessary to store the LUKS partition header and key material in the QCow2 file. This data can be many MB in size, so cannot go into the QCow2 header region directly. Thus the spec defines a FDE (Full Disk Encryption) header extension that specifies the offset of a set of clusters to hold the FDE headers, as well as the length of that region. The LUKS header is thus stored in these extra allocated clusters before the main image payload. Aside from all the cryptographic differences implied by use of the LUKS format, there is one further key difference between the use of legacy AES and LUKS encryption in qcow2. For LUKS, the initialiazation vectors are generated using the host physical sector as the input, rather than the guest virtual sector. This guarantees unique initialization vectors for all sectors when qcow2 internal snapshots are used, thus giving stronger protection against watermarking attacks. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-14-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:12 +03:00
encrypt.format Encrypt the image, format choices: 'aes', 'luks'
encrypt.key-secret ID of secret providing qcow AES key or LUKS passphrase
encrypt.cipher-alg Name of encryption cipher algorithm
encrypt.cipher-mode Name of encryption cipher mode
encrypt.ivgen-alg Name of IV generator algorithm
encrypt.ivgen-hash-alg Name of IV generator hash algorithm
encrypt.hash-alg Name of encryption hash algorithm
encrypt.iter-time Time to spend in PBKDF in milliseconds
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
cluster_size qcow2 cluster size
qcow2: Add falloc and full preallocation option preallocation=falloc allocates disk space by posix_fallocate(), preallocation=full allocates disk space by writing zeros to disk. Both modes imply preallocation=metadata. Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-09-10 13:05:49 +04:00
preallocation Preallocation mode (allowed values: off, metadata, falloc, full)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
lazy_refcounts Postpone refcount updates
qcow2: Allow creation with refcount order != 4 Add a creation option to qcow2 for setting the refcount order of images to be created, and respect that option's value. This breaks some test outputs, fix them. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2015-02-19 01:40:49 +03:00
refcount_bits Width of a reference count entry in bits
qemu-img: Add print_amend_option_help() The more generic print_block_option_help() function is not really suitable for qemu-img amend, for a couple of reasons: (1) We do not need to append the protocol-level options, as amendment happens only on one node and does not descend downwards to its children. (2) print_block_option_help() says those options are "supported". For option amendment, we do not really know that. So this new function explicitly says that those options are the creation options, and not all of them may be supported. (3) If the driver does not support option amendment, we should not print anything (except for an error message that amendment is not supported). Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1537956 Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20180509210023.20283-5-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2018-05-10 00:00:20 +03:00
Note that not all of these options may be amendable.
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
Testing: amend -f qcow2 -o ? TEST_DIR/t.qcow2
qemu-img: Add print_amend_option_help() The more generic print_block_option_help() function is not really suitable for qemu-img amend, for a couple of reasons: (1) We do not need to append the protocol-level options, as amendment happens only on one node and does not descend downwards to its children. (2) print_block_option_help() says those options are "supported". For option amendment, we do not really know that. So this new function explicitly says that those options are the creation options, and not all of them may be supported. (3) If the driver does not support option amendment, we should not print anything (except for an error message that amendment is not supported). Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1537956 Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20180509210023.20283-5-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2018-05-10 00:00:20 +03:00
Creation options for 'qcow2':
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
size Virtual disk size
compat Compatibility level (0.10 or 1.1)
backing_file File name of a base image
backing_fmt Image format of the base image
block: deprecate "encryption=on" in favor of "encrypt.format=aes" Historically the qcow & qcow2 image formats supported a property "encryption=on" to enable their built-in AES encryption. We'll soon be supporting LUKS for qcow2, so need a more general purpose way to enable encryption, with a choice of formats. This introduces an "encrypt.format" option, which will later be joined by a number of other "encrypt.XXX" options. The use of a "encrypt." prefix instead of "encrypt-" is done to facilitate mapping to a nested QAPI schema at later date. e.g. the preferred syntax is now qemu-img create -f qcow2 -o encrypt.format=aes demo.qcow2 Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-8-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:06 +03:00
encryption Encrypt the image with format 'aes'. (Deprecated in favor of encrypt.format=aes)
qcow2: add support for LUKS encryption format This adds support for using LUKS as an encryption format with the qcow2 file, using the new encrypt.format parameter to request "luks" format. e.g. # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 \ test.qcow2 10G The legacy "encryption=on" parameter still results in creation of the old qcow2 AES format (and is equivalent to the new 'encryption-format=aes'). e.g. the following are equivalent: # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption=on,encrypt.key-secret=sec0 \ test.qcow2 10G # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption-format=aes,encrypt.key-secret=sec0 \ test.qcow2 10G With the LUKS format it is necessary to store the LUKS partition header and key material in the QCow2 file. This data can be many MB in size, so cannot go into the QCow2 header region directly. Thus the spec defines a FDE (Full Disk Encryption) header extension that specifies the offset of a set of clusters to hold the FDE headers, as well as the length of that region. The LUKS header is thus stored in these extra allocated clusters before the main image payload. Aside from all the cryptographic differences implied by use of the LUKS format, there is one further key difference between the use of legacy AES and LUKS encryption in qcow2. For LUKS, the initialiazation vectors are generated using the host physical sector as the input, rather than the guest virtual sector. This guarantees unique initialization vectors for all sectors when qcow2 internal snapshots are used, thus giving stronger protection against watermarking attacks. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-14-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:12 +03:00
encrypt.format Encrypt the image, format choices: 'aes', 'luks'
encrypt.key-secret ID of secret providing qcow AES key or LUKS passphrase
encrypt.cipher-alg Name of encryption cipher algorithm
encrypt.cipher-mode Name of encryption cipher mode
encrypt.ivgen-alg Name of IV generator algorithm
encrypt.ivgen-hash-alg Name of IV generator hash algorithm
encrypt.hash-alg Name of encryption hash algorithm
encrypt.iter-time Time to spend in PBKDF in milliseconds
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
cluster_size qcow2 cluster size
qcow2: Add falloc and full preallocation option preallocation=falloc allocates disk space by posix_fallocate(), preallocation=full allocates disk space by writing zeros to disk. Both modes imply preallocation=metadata. Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-09-10 13:05:49 +04:00
preallocation Preallocation mode (allowed values: off, metadata, falloc, full)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
lazy_refcounts Postpone refcount updates
qcow2: Allow creation with refcount order != 4 Add a creation option to qcow2 for setting the refcount order of images to be created, and respect that option's value. This breaks some test outputs, fix them. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2015-02-19 01:40:49 +03:00
refcount_bits Width of a reference count entry in bits
qemu-img: Add print_amend_option_help() The more generic print_block_option_help() function is not really suitable for qemu-img amend, for a couple of reasons: (1) We do not need to append the protocol-level options, as amendment happens only on one node and does not descend downwards to its children. (2) print_block_option_help() says those options are "supported". For option amendment, we do not really know that. So this new function explicitly says that those options are the creation options, and not all of them may be supported. (3) If the driver does not support option amendment, we should not print anything (except for an error message that amendment is not supported). Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1537956 Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20180509210023.20283-5-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2018-05-10 00:00:20 +03:00
Note that not all of these options may be amendable.
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
Testing: amend -f qcow2 -o cluster_size=4k,help TEST_DIR/t.qcow2
qemu-img: Add print_amend_option_help() The more generic print_block_option_help() function is not really suitable for qemu-img amend, for a couple of reasons: (1) We do not need to append the protocol-level options, as amendment happens only on one node and does not descend downwards to its children. (2) print_block_option_help() says those options are "supported". For option amendment, we do not really know that. So this new function explicitly says that those options are the creation options, and not all of them may be supported. (3) If the driver does not support option amendment, we should not print anything (except for an error message that amendment is not supported). Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1537956 Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20180509210023.20283-5-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2018-05-10 00:00:20 +03:00
Creation options for 'qcow2':
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
size Virtual disk size
compat Compatibility level (0.10 or 1.1)
backing_file File name of a base image
backing_fmt Image format of the base image
block: deprecate "encryption=on" in favor of "encrypt.format=aes" Historically the qcow & qcow2 image formats supported a property "encryption=on" to enable their built-in AES encryption. We'll soon be supporting LUKS for qcow2, so need a more general purpose way to enable encryption, with a choice of formats. This introduces an "encrypt.format" option, which will later be joined by a number of other "encrypt.XXX" options. The use of a "encrypt." prefix instead of "encrypt-" is done to facilitate mapping to a nested QAPI schema at later date. e.g. the preferred syntax is now qemu-img create -f qcow2 -o encrypt.format=aes demo.qcow2 Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-8-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:06 +03:00
encryption Encrypt the image with format 'aes'. (Deprecated in favor of encrypt.format=aes)
qcow2: add support for LUKS encryption format This adds support for using LUKS as an encryption format with the qcow2 file, using the new encrypt.format parameter to request "luks" format. e.g. # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 \ test.qcow2 10G The legacy "encryption=on" parameter still results in creation of the old qcow2 AES format (and is equivalent to the new 'encryption-format=aes'). e.g. the following are equivalent: # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption=on,encrypt.key-secret=sec0 \ test.qcow2 10G # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption-format=aes,encrypt.key-secret=sec0 \ test.qcow2 10G With the LUKS format it is necessary to store the LUKS partition header and key material in the QCow2 file. This data can be many MB in size, so cannot go into the QCow2 header region directly. Thus the spec defines a FDE (Full Disk Encryption) header extension that specifies the offset of a set of clusters to hold the FDE headers, as well as the length of that region. The LUKS header is thus stored in these extra allocated clusters before the main image payload. Aside from all the cryptographic differences implied by use of the LUKS format, there is one further key difference between the use of legacy AES and LUKS encryption in qcow2. For LUKS, the initialiazation vectors are generated using the host physical sector as the input, rather than the guest virtual sector. This guarantees unique initialization vectors for all sectors when qcow2 internal snapshots are used, thus giving stronger protection against watermarking attacks. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-14-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:12 +03:00
encrypt.format Encrypt the image, format choices: 'aes', 'luks'
encrypt.key-secret ID of secret providing qcow AES key or LUKS passphrase
encrypt.cipher-alg Name of encryption cipher algorithm
encrypt.cipher-mode Name of encryption cipher mode
encrypt.ivgen-alg Name of IV generator algorithm
encrypt.ivgen-hash-alg Name of IV generator hash algorithm
encrypt.hash-alg Name of encryption hash algorithm
encrypt.iter-time Time to spend in PBKDF in milliseconds
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
cluster_size qcow2 cluster size
qcow2: Add falloc and full preallocation option preallocation=falloc allocates disk space by posix_fallocate(), preallocation=full allocates disk space by writing zeros to disk. Both modes imply preallocation=metadata. Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-09-10 13:05:49 +04:00
preallocation Preallocation mode (allowed values: off, metadata, falloc, full)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
lazy_refcounts Postpone refcount updates
qcow2: Allow creation with refcount order != 4 Add a creation option to qcow2 for setting the refcount order of images to be created, and respect that option's value. This breaks some test outputs, fix them. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2015-02-19 01:40:49 +03:00
refcount_bits Width of a reference count entry in bits
qemu-img: Add print_amend_option_help() The more generic print_block_option_help() function is not really suitable for qemu-img amend, for a couple of reasons: (1) We do not need to append the protocol-level options, as amendment happens only on one node and does not descend downwards to its children. (2) print_block_option_help() says those options are "supported". For option amendment, we do not really know that. So this new function explicitly says that those options are the creation options, and not all of them may be supported. (3) If the driver does not support option amendment, we should not print anything (except for an error message that amendment is not supported). Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1537956 Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20180509210023.20283-5-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2018-05-10 00:00:20 +03:00
Note that not all of these options may be amendable.
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
Testing: amend -f qcow2 -o cluster_size=4k,? TEST_DIR/t.qcow2
qemu-img: Add print_amend_option_help() The more generic print_block_option_help() function is not really suitable for qemu-img amend, for a couple of reasons: (1) We do not need to append the protocol-level options, as amendment happens only on one node and does not descend downwards to its children. (2) print_block_option_help() says those options are "supported". For option amendment, we do not really know that. So this new function explicitly says that those options are the creation options, and not all of them may be supported. (3) If the driver does not support option amendment, we should not print anything (except for an error message that amendment is not supported). Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1537956 Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20180509210023.20283-5-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2018-05-10 00:00:20 +03:00
Creation options for 'qcow2':
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
size Virtual disk size
compat Compatibility level (0.10 or 1.1)
backing_file File name of a base image
backing_fmt Image format of the base image
block: deprecate "encryption=on" in favor of "encrypt.format=aes" Historically the qcow & qcow2 image formats supported a property "encryption=on" to enable their built-in AES encryption. We'll soon be supporting LUKS for qcow2, so need a more general purpose way to enable encryption, with a choice of formats. This introduces an "encrypt.format" option, which will later be joined by a number of other "encrypt.XXX" options. The use of a "encrypt." prefix instead of "encrypt-" is done to facilitate mapping to a nested QAPI schema at later date. e.g. the preferred syntax is now qemu-img create -f qcow2 -o encrypt.format=aes demo.qcow2 Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-8-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:06 +03:00
encryption Encrypt the image with format 'aes'. (Deprecated in favor of encrypt.format=aes)
qcow2: add support for LUKS encryption format This adds support for using LUKS as an encryption format with the qcow2 file, using the new encrypt.format parameter to request "luks" format. e.g. # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 \ test.qcow2 10G The legacy "encryption=on" parameter still results in creation of the old qcow2 AES format (and is equivalent to the new 'encryption-format=aes'). e.g. the following are equivalent: # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption=on,encrypt.key-secret=sec0 \ test.qcow2 10G # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption-format=aes,encrypt.key-secret=sec0 \ test.qcow2 10G With the LUKS format it is necessary to store the LUKS partition header and key material in the QCow2 file. This data can be many MB in size, so cannot go into the QCow2 header region directly. Thus the spec defines a FDE (Full Disk Encryption) header extension that specifies the offset of a set of clusters to hold the FDE headers, as well as the length of that region. The LUKS header is thus stored in these extra allocated clusters before the main image payload. Aside from all the cryptographic differences implied by use of the LUKS format, there is one further key difference between the use of legacy AES and LUKS encryption in qcow2. For LUKS, the initialiazation vectors are generated using the host physical sector as the input, rather than the guest virtual sector. This guarantees unique initialization vectors for all sectors when qcow2 internal snapshots are used, thus giving stronger protection against watermarking attacks. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-14-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:12 +03:00
encrypt.format Encrypt the image, format choices: 'aes', 'luks'
encrypt.key-secret ID of secret providing qcow AES key or LUKS passphrase
encrypt.cipher-alg Name of encryption cipher algorithm
encrypt.cipher-mode Name of encryption cipher mode
encrypt.ivgen-alg Name of IV generator algorithm
encrypt.ivgen-hash-alg Name of IV generator hash algorithm
encrypt.hash-alg Name of encryption hash algorithm
encrypt.iter-time Time to spend in PBKDF in milliseconds
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
cluster_size qcow2 cluster size
qcow2: Add falloc and full preallocation option preallocation=falloc allocates disk space by posix_fallocate(), preallocation=full allocates disk space by writing zeros to disk. Both modes imply preallocation=metadata. Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-09-10 13:05:49 +04:00
preallocation Preallocation mode (allowed values: off, metadata, falloc, full)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
lazy_refcounts Postpone refcount updates
qcow2: Allow creation with refcount order != 4 Add a creation option to qcow2 for setting the refcount order of images to be created, and respect that option's value. This breaks some test outputs, fix them. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2015-02-19 01:40:49 +03:00
refcount_bits Width of a reference count entry in bits
qemu-img: Add print_amend_option_help() The more generic print_block_option_help() function is not really suitable for qemu-img amend, for a couple of reasons: (1) We do not need to append the protocol-level options, as amendment happens only on one node and does not descend downwards to its children. (2) print_block_option_help() says those options are "supported". For option amendment, we do not really know that. So this new function explicitly says that those options are the creation options, and not all of them may be supported. (3) If the driver does not support option amendment, we should not print anything (except for an error message that amendment is not supported). Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1537956 Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20180509210023.20283-5-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2018-05-10 00:00:20 +03:00
Note that not all of these options may be amendable.
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
Testing: amend -f qcow2 -o help,cluster_size=4k TEST_DIR/t.qcow2
qemu-img: Add print_amend_option_help() The more generic print_block_option_help() function is not really suitable for qemu-img amend, for a couple of reasons: (1) We do not need to append the protocol-level options, as amendment happens only on one node and does not descend downwards to its children. (2) print_block_option_help() says those options are "supported". For option amendment, we do not really know that. So this new function explicitly says that those options are the creation options, and not all of them may be supported. (3) If the driver does not support option amendment, we should not print anything (except for an error message that amendment is not supported). Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1537956 Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20180509210023.20283-5-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2018-05-10 00:00:20 +03:00
Creation options for 'qcow2':
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
size Virtual disk size
compat Compatibility level (0.10 or 1.1)
backing_file File name of a base image
backing_fmt Image format of the base image
block: deprecate "encryption=on" in favor of "encrypt.format=aes" Historically the qcow & qcow2 image formats supported a property "encryption=on" to enable their built-in AES encryption. We'll soon be supporting LUKS for qcow2, so need a more general purpose way to enable encryption, with a choice of formats. This introduces an "encrypt.format" option, which will later be joined by a number of other "encrypt.XXX" options. The use of a "encrypt." prefix instead of "encrypt-" is done to facilitate mapping to a nested QAPI schema at later date. e.g. the preferred syntax is now qemu-img create -f qcow2 -o encrypt.format=aes demo.qcow2 Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-8-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:06 +03:00
encryption Encrypt the image with format 'aes'. (Deprecated in favor of encrypt.format=aes)
qcow2: add support for LUKS encryption format This adds support for using LUKS as an encryption format with the qcow2 file, using the new encrypt.format parameter to request "luks" format. e.g. # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 \ test.qcow2 10G The legacy "encryption=on" parameter still results in creation of the old qcow2 AES format (and is equivalent to the new 'encryption-format=aes'). e.g. the following are equivalent: # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption=on,encrypt.key-secret=sec0 \ test.qcow2 10G # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption-format=aes,encrypt.key-secret=sec0 \ test.qcow2 10G With the LUKS format it is necessary to store the LUKS partition header and key material in the QCow2 file. This data can be many MB in size, so cannot go into the QCow2 header region directly. Thus the spec defines a FDE (Full Disk Encryption) header extension that specifies the offset of a set of clusters to hold the FDE headers, as well as the length of that region. The LUKS header is thus stored in these extra allocated clusters before the main image payload. Aside from all the cryptographic differences implied by use of the LUKS format, there is one further key difference between the use of legacy AES and LUKS encryption in qcow2. For LUKS, the initialiazation vectors are generated using the host physical sector as the input, rather than the guest virtual sector. This guarantees unique initialization vectors for all sectors when qcow2 internal snapshots are used, thus giving stronger protection against watermarking attacks. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-14-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:12 +03:00
encrypt.format Encrypt the image, format choices: 'aes', 'luks'
encrypt.key-secret ID of secret providing qcow AES key or LUKS passphrase
encrypt.cipher-alg Name of encryption cipher algorithm
encrypt.cipher-mode Name of encryption cipher mode
encrypt.ivgen-alg Name of IV generator algorithm
encrypt.ivgen-hash-alg Name of IV generator hash algorithm
encrypt.hash-alg Name of encryption hash algorithm
encrypt.iter-time Time to spend in PBKDF in milliseconds
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
cluster_size qcow2 cluster size
qcow2: Add falloc and full preallocation option preallocation=falloc allocates disk space by posix_fallocate(), preallocation=full allocates disk space by writing zeros to disk. Both modes imply preallocation=metadata. Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-09-10 13:05:49 +04:00
preallocation Preallocation mode (allowed values: off, metadata, falloc, full)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
lazy_refcounts Postpone refcount updates
qcow2: Allow creation with refcount order != 4 Add a creation option to qcow2 for setting the refcount order of images to be created, and respect that option's value. This breaks some test outputs, fix them. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2015-02-19 01:40:49 +03:00
refcount_bits Width of a reference count entry in bits
qemu-img: Add print_amend_option_help() The more generic print_block_option_help() function is not really suitable for qemu-img amend, for a couple of reasons: (1) We do not need to append the protocol-level options, as amendment happens only on one node and does not descend downwards to its children. (2) print_block_option_help() says those options are "supported". For option amendment, we do not really know that. So this new function explicitly says that those options are the creation options, and not all of them may be supported. (3) If the driver does not support option amendment, we should not print anything (except for an error message that amendment is not supported). Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1537956 Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20180509210023.20283-5-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2018-05-10 00:00:20 +03:00
Note that not all of these options may be amendable.
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
Testing: amend -f qcow2 -o ?,cluster_size=4k TEST_DIR/t.qcow2
qemu-img: Add print_amend_option_help() The more generic print_block_option_help() function is not really suitable for qemu-img amend, for a couple of reasons: (1) We do not need to append the protocol-level options, as amendment happens only on one node and does not descend downwards to its children. (2) print_block_option_help() says those options are "supported". For option amendment, we do not really know that. So this new function explicitly says that those options are the creation options, and not all of them may be supported. (3) If the driver does not support option amendment, we should not print anything (except for an error message that amendment is not supported). Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1537956 Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20180509210023.20283-5-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2018-05-10 00:00:20 +03:00
Creation options for 'qcow2':
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
size Virtual disk size
compat Compatibility level (0.10 or 1.1)
backing_file File name of a base image
backing_fmt Image format of the base image
block: deprecate "encryption=on" in favor of "encrypt.format=aes" Historically the qcow & qcow2 image formats supported a property "encryption=on" to enable their built-in AES encryption. We'll soon be supporting LUKS for qcow2, so need a more general purpose way to enable encryption, with a choice of formats. This introduces an "encrypt.format" option, which will later be joined by a number of other "encrypt.XXX" options. The use of a "encrypt." prefix instead of "encrypt-" is done to facilitate mapping to a nested QAPI schema at later date. e.g. the preferred syntax is now qemu-img create -f qcow2 -o encrypt.format=aes demo.qcow2 Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-8-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:06 +03:00
encryption Encrypt the image with format 'aes'. (Deprecated in favor of encrypt.format=aes)
qcow2: add support for LUKS encryption format This adds support for using LUKS as an encryption format with the qcow2 file, using the new encrypt.format parameter to request "luks" format. e.g. # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 \ test.qcow2 10G The legacy "encryption=on" parameter still results in creation of the old qcow2 AES format (and is equivalent to the new 'encryption-format=aes'). e.g. the following are equivalent: # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption=on,encrypt.key-secret=sec0 \ test.qcow2 10G # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption-format=aes,encrypt.key-secret=sec0 \ test.qcow2 10G With the LUKS format it is necessary to store the LUKS partition header and key material in the QCow2 file. This data can be many MB in size, so cannot go into the QCow2 header region directly. Thus the spec defines a FDE (Full Disk Encryption) header extension that specifies the offset of a set of clusters to hold the FDE headers, as well as the length of that region. The LUKS header is thus stored in these extra allocated clusters before the main image payload. Aside from all the cryptographic differences implied by use of the LUKS format, there is one further key difference between the use of legacy AES and LUKS encryption in qcow2. For LUKS, the initialiazation vectors are generated using the host physical sector as the input, rather than the guest virtual sector. This guarantees unique initialization vectors for all sectors when qcow2 internal snapshots are used, thus giving stronger protection against watermarking attacks. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-14-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:12 +03:00
encrypt.format Encrypt the image, format choices: 'aes', 'luks'
encrypt.key-secret ID of secret providing qcow AES key or LUKS passphrase
encrypt.cipher-alg Name of encryption cipher algorithm
encrypt.cipher-mode Name of encryption cipher mode
encrypt.ivgen-alg Name of IV generator algorithm
encrypt.ivgen-hash-alg Name of IV generator hash algorithm
encrypt.hash-alg Name of encryption hash algorithm
encrypt.iter-time Time to spend in PBKDF in milliseconds
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
cluster_size qcow2 cluster size
qcow2: Add falloc and full preallocation option preallocation=falloc allocates disk space by posix_fallocate(), preallocation=full allocates disk space by writing zeros to disk. Both modes imply preallocation=metadata. Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-09-10 13:05:49 +04:00
preallocation Preallocation mode (allowed values: off, metadata, falloc, full)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
lazy_refcounts Postpone refcount updates
qcow2: Allow creation with refcount order != 4 Add a creation option to qcow2 for setting the refcount order of images to be created, and respect that option's value. This breaks some test outputs, fix them. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2015-02-19 01:40:49 +03:00
refcount_bits Width of a reference count entry in bits
qemu-img: Add print_amend_option_help() The more generic print_block_option_help() function is not really suitable for qemu-img amend, for a couple of reasons: (1) We do not need to append the protocol-level options, as amendment happens only on one node and does not descend downwards to its children. (2) print_block_option_help() says those options are "supported". For option amendment, we do not really know that. So this new function explicitly says that those options are the creation options, and not all of them may be supported. (3) If the driver does not support option amendment, we should not print anything (except for an error message that amendment is not supported). Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1537956 Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20180509210023.20283-5-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2018-05-10 00:00:20 +03:00
Note that not all of these options may be amendable.
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
Testing: amend -f qcow2 -o cluster_size=4k -o help TEST_DIR/t.qcow2
qemu-img: Add print_amend_option_help() The more generic print_block_option_help() function is not really suitable for qemu-img amend, for a couple of reasons: (1) We do not need to append the protocol-level options, as amendment happens only on one node and does not descend downwards to its children. (2) print_block_option_help() says those options are "supported". For option amendment, we do not really know that. So this new function explicitly says that those options are the creation options, and not all of them may be supported. (3) If the driver does not support option amendment, we should not print anything (except for an error message that amendment is not supported). Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1537956 Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20180509210023.20283-5-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2018-05-10 00:00:20 +03:00
Creation options for 'qcow2':
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
size Virtual disk size
compat Compatibility level (0.10 or 1.1)
backing_file File name of a base image
backing_fmt Image format of the base image
block: deprecate "encryption=on" in favor of "encrypt.format=aes" Historically the qcow & qcow2 image formats supported a property "encryption=on" to enable their built-in AES encryption. We'll soon be supporting LUKS for qcow2, so need a more general purpose way to enable encryption, with a choice of formats. This introduces an "encrypt.format" option, which will later be joined by a number of other "encrypt.XXX" options. The use of a "encrypt." prefix instead of "encrypt-" is done to facilitate mapping to a nested QAPI schema at later date. e.g. the preferred syntax is now qemu-img create -f qcow2 -o encrypt.format=aes demo.qcow2 Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-8-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:06 +03:00
encryption Encrypt the image with format 'aes'. (Deprecated in favor of encrypt.format=aes)
qcow2: add support for LUKS encryption format This adds support for using LUKS as an encryption format with the qcow2 file, using the new encrypt.format parameter to request "luks" format. e.g. # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 \ test.qcow2 10G The legacy "encryption=on" parameter still results in creation of the old qcow2 AES format (and is equivalent to the new 'encryption-format=aes'). e.g. the following are equivalent: # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption=on,encrypt.key-secret=sec0 \ test.qcow2 10G # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption-format=aes,encrypt.key-secret=sec0 \ test.qcow2 10G With the LUKS format it is necessary to store the LUKS partition header and key material in the QCow2 file. This data can be many MB in size, so cannot go into the QCow2 header region directly. Thus the spec defines a FDE (Full Disk Encryption) header extension that specifies the offset of a set of clusters to hold the FDE headers, as well as the length of that region. The LUKS header is thus stored in these extra allocated clusters before the main image payload. Aside from all the cryptographic differences implied by use of the LUKS format, there is one further key difference between the use of legacy AES and LUKS encryption in qcow2. For LUKS, the initialiazation vectors are generated using the host physical sector as the input, rather than the guest virtual sector. This guarantees unique initialization vectors for all sectors when qcow2 internal snapshots are used, thus giving stronger protection against watermarking attacks. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-14-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:12 +03:00
encrypt.format Encrypt the image, format choices: 'aes', 'luks'
encrypt.key-secret ID of secret providing qcow AES key or LUKS passphrase
encrypt.cipher-alg Name of encryption cipher algorithm
encrypt.cipher-mode Name of encryption cipher mode
encrypt.ivgen-alg Name of IV generator algorithm
encrypt.ivgen-hash-alg Name of IV generator hash algorithm
encrypt.hash-alg Name of encryption hash algorithm
encrypt.iter-time Time to spend in PBKDF in milliseconds
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
cluster_size qcow2 cluster size
qcow2: Add falloc and full preallocation option preallocation=falloc allocates disk space by posix_fallocate(), preallocation=full allocates disk space by writing zeros to disk. Both modes imply preallocation=metadata. Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-09-10 13:05:49 +04:00
preallocation Preallocation mode (allowed values: off, metadata, falloc, full)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
lazy_refcounts Postpone refcount updates
qcow2: Allow creation with refcount order != 4 Add a creation option to qcow2 for setting the refcount order of images to be created, and respect that option's value. This breaks some test outputs, fix them. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2015-02-19 01:40:49 +03:00
refcount_bits Width of a reference count entry in bits
qemu-img: Add print_amend_option_help() The more generic print_block_option_help() function is not really suitable for qemu-img amend, for a couple of reasons: (1) We do not need to append the protocol-level options, as amendment happens only on one node and does not descend downwards to its children. (2) print_block_option_help() says those options are "supported". For option amendment, we do not really know that. So this new function explicitly says that those options are the creation options, and not all of them may be supported. (3) If the driver does not support option amendment, we should not print anything (except for an error message that amendment is not supported). Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1537956 Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20180509210023.20283-5-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2018-05-10 00:00:20 +03:00
Note that not all of these options may be amendable.
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
Testing: amend -f qcow2 -o cluster_size=4k -o ? TEST_DIR/t.qcow2
qemu-img: Add print_amend_option_help() The more generic print_block_option_help() function is not really suitable for qemu-img amend, for a couple of reasons: (1) We do not need to append the protocol-level options, as amendment happens only on one node and does not descend downwards to its children. (2) print_block_option_help() says those options are "supported". For option amendment, we do not really know that. So this new function explicitly says that those options are the creation options, and not all of them may be supported. (3) If the driver does not support option amendment, we should not print anything (except for an error message that amendment is not supported). Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1537956 Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20180509210023.20283-5-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2018-05-10 00:00:20 +03:00
Creation options for 'qcow2':
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
size Virtual disk size
compat Compatibility level (0.10 or 1.1)
backing_file File name of a base image
backing_fmt Image format of the base image
block: deprecate "encryption=on" in favor of "encrypt.format=aes" Historically the qcow & qcow2 image formats supported a property "encryption=on" to enable their built-in AES encryption. We'll soon be supporting LUKS for qcow2, so need a more general purpose way to enable encryption, with a choice of formats. This introduces an "encrypt.format" option, which will later be joined by a number of other "encrypt.XXX" options. The use of a "encrypt." prefix instead of "encrypt-" is done to facilitate mapping to a nested QAPI schema at later date. e.g. the preferred syntax is now qemu-img create -f qcow2 -o encrypt.format=aes demo.qcow2 Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-8-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:06 +03:00
encryption Encrypt the image with format 'aes'. (Deprecated in favor of encrypt.format=aes)
qcow2: add support for LUKS encryption format This adds support for using LUKS as an encryption format with the qcow2 file, using the new encrypt.format parameter to request "luks" format. e.g. # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 \ test.qcow2 10G The legacy "encryption=on" parameter still results in creation of the old qcow2 AES format (and is equivalent to the new 'encryption-format=aes'). e.g. the following are equivalent: # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption=on,encrypt.key-secret=sec0 \ test.qcow2 10G # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption-format=aes,encrypt.key-secret=sec0 \ test.qcow2 10G With the LUKS format it is necessary to store the LUKS partition header and key material in the QCow2 file. This data can be many MB in size, so cannot go into the QCow2 header region directly. Thus the spec defines a FDE (Full Disk Encryption) header extension that specifies the offset of a set of clusters to hold the FDE headers, as well as the length of that region. The LUKS header is thus stored in these extra allocated clusters before the main image payload. Aside from all the cryptographic differences implied by use of the LUKS format, there is one further key difference between the use of legacy AES and LUKS encryption in qcow2. For LUKS, the initialiazation vectors are generated using the host physical sector as the input, rather than the guest virtual sector. This guarantees unique initialization vectors for all sectors when qcow2 internal snapshots are used, thus giving stronger protection against watermarking attacks. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-14-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:12 +03:00
encrypt.format Encrypt the image, format choices: 'aes', 'luks'
encrypt.key-secret ID of secret providing qcow AES key or LUKS passphrase
encrypt.cipher-alg Name of encryption cipher algorithm
encrypt.cipher-mode Name of encryption cipher mode
encrypt.ivgen-alg Name of IV generator algorithm
encrypt.ivgen-hash-alg Name of IV generator hash algorithm
encrypt.hash-alg Name of encryption hash algorithm
encrypt.iter-time Time to spend in PBKDF in milliseconds
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
cluster_size qcow2 cluster size
qcow2: Add falloc and full preallocation option preallocation=falloc allocates disk space by posix_fallocate(), preallocation=full allocates disk space by writing zeros to disk. Both modes imply preallocation=metadata. Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-09-10 13:05:49 +04:00
preallocation Preallocation mode (allowed values: off, metadata, falloc, full)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
lazy_refcounts Postpone refcount updates
qcow2: Allow creation with refcount order != 4 Add a creation option to qcow2 for setting the refcount order of images to be created, and respect that option's value. This breaks some test outputs, fix them. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2015-02-19 01:40:49 +03:00
refcount_bits Width of a reference count entry in bits
qemu-img: Add print_amend_option_help() The more generic print_block_option_help() function is not really suitable for qemu-img amend, for a couple of reasons: (1) We do not need to append the protocol-level options, as amendment happens only on one node and does not descend downwards to its children. (2) print_block_option_help() says those options are "supported". For option amendment, we do not really know that. So this new function explicitly says that those options are the creation options, and not all of them may be supported. (3) If the driver does not support option amendment, we should not print anything (except for an error message that amendment is not supported). Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1537956 Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20180509210023.20283-5-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2018-05-10 00:00:20 +03:00
Note that not all of these options may be amendable.
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
Testing: amend -f qcow2 -o backing_file=TEST_DIR/t.qcow2,,help TEST_DIR/t.qcow2
Testing: rebase -u -b -f qcow2 TEST_DIR/t.qcow2
Testing: amend -f qcow2 -o backing_file=TEST_DIR/t.qcow2,,? TEST_DIR/t.qcow2
Testing: rebase -u -b -f qcow2 TEST_DIR/t.qcow2
Testing: amend -f qcow2 -o backing_file=TEST_DIR/t.qcow2, -o help TEST_DIR/t.qcow2
qemu-img: Invalid option list: backing_file=TEST_DIR/t.qcow2,
Testing: amend -f qcow2 -o backing_file=TEST_DIR/t.qcow2 -o ,help TEST_DIR/t.qcow2
qemu-img: Invalid option list: ,help
Testing: amend -f qcow2 -o backing_file=TEST_DIR/t.qcow2 -o ,, -o help TEST_DIR/t.qcow2
qemu-img: Invalid option list: ,,
Testing: amend -f qcow2 -o help
qemu-img: Add print_amend_option_help() The more generic print_block_option_help() function is not really suitable for qemu-img amend, for a couple of reasons: (1) We do not need to append the protocol-level options, as amendment happens only on one node and does not descend downwards to its children. (2) print_block_option_help() says those options are "supported". For option amendment, we do not really know that. So this new function explicitly says that those options are the creation options, and not all of them may be supported. (3) If the driver does not support option amendment, we should not print anything (except for an error message that amendment is not supported). Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1537956 Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20180509210023.20283-5-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2018-05-10 00:00:20 +03:00
Creation options for 'qcow2':
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
size Virtual disk size
compat Compatibility level (0.10 or 1.1)
backing_file File name of a base image
backing_fmt Image format of the base image
block: deprecate "encryption=on" in favor of "encrypt.format=aes" Historically the qcow & qcow2 image formats supported a property "encryption=on" to enable their built-in AES encryption. We'll soon be supporting LUKS for qcow2, so need a more general purpose way to enable encryption, with a choice of formats. This introduces an "encrypt.format" option, which will later be joined by a number of other "encrypt.XXX" options. The use of a "encrypt." prefix instead of "encrypt-" is done to facilitate mapping to a nested QAPI schema at later date. e.g. the preferred syntax is now qemu-img create -f qcow2 -o encrypt.format=aes demo.qcow2 Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-8-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:06 +03:00
encryption Encrypt the image with format 'aes'. (Deprecated in favor of encrypt.format=aes)
qcow2: add support for LUKS encryption format This adds support for using LUKS as an encryption format with the qcow2 file, using the new encrypt.format parameter to request "luks" format. e.g. # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encrypt.format=luks,encrypt.key-secret=sec0 \ test.qcow2 10G The legacy "encryption=on" parameter still results in creation of the old qcow2 AES format (and is equivalent to the new 'encryption-format=aes'). e.g. the following are equivalent: # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption=on,encrypt.key-secret=sec0 \ test.qcow2 10G # qemu-img create --object secret,data=123456,id=sec0 \ -f qcow2 -o encryption-format=aes,encrypt.key-secret=sec0 \ test.qcow2 10G With the LUKS format it is necessary to store the LUKS partition header and key material in the QCow2 file. This data can be many MB in size, so cannot go into the QCow2 header region directly. Thus the spec defines a FDE (Full Disk Encryption) header extension that specifies the offset of a set of clusters to hold the FDE headers, as well as the length of that region. The LUKS header is thus stored in these extra allocated clusters before the main image payload. Aside from all the cryptographic differences implied by use of the LUKS format, there is one further key difference between the use of legacy AES and LUKS encryption in qcow2. For LUKS, the initialiazation vectors are generated using the host physical sector as the input, rather than the guest virtual sector. This guarantees unique initialization vectors for all sectors when qcow2 internal snapshots are used, thus giving stronger protection against watermarking attacks. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-id: 20170623162419.26068-14-berrange@redhat.com Reviewed-by: Alberto Garcia <berto@igalia.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2017-06-23 19:24:12 +03:00
encrypt.format Encrypt the image, format choices: 'aes', 'luks'
encrypt.key-secret ID of secret providing qcow AES key or LUKS passphrase
encrypt.cipher-alg Name of encryption cipher algorithm
encrypt.cipher-mode Name of encryption cipher mode
encrypt.ivgen-alg Name of IV generator algorithm
encrypt.ivgen-hash-alg Name of IV generator hash algorithm
encrypt.hash-alg Name of encryption hash algorithm
encrypt.iter-time Time to spend in PBKDF in milliseconds
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
cluster_size qcow2 cluster size
qcow2: Add falloc and full preallocation option preallocation=falloc allocates disk space by posix_fallocate(), preallocation=full allocates disk space by writing zeros to disk. Both modes imply preallocation=metadata. Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2014-09-10 13:05:49 +04:00
preallocation Preallocation mode (allowed values: off, metadata, falloc, full)
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
lazy_refcounts Postpone refcount updates
qcow2: Allow creation with refcount order != 4 Add a creation option to qcow2 for setting the refcount order of images to be created, and respect that option's value. This breaks some test outputs, fix them. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2015-02-19 01:40:49 +03:00
refcount_bits Width of a reference count entry in bits
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
qemu-img: Add print_amend_option_help() The more generic print_block_option_help() function is not really suitable for qemu-img amend, for a couple of reasons: (1) We do not need to append the protocol-level options, as amendment happens only on one node and does not descend downwards to its children. (2) print_block_option_help() says those options are "supported". For option amendment, we do not really know that. So this new function explicitly says that those options are the creation options, and not all of them may be supported. (3) If the driver does not support option amendment, we should not print anything (except for an error message that amendment is not supported). Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1537956 Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20180509210023.20283-5-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2018-05-10 00:00:20 +03:00
Note that not all of these options may be amendable.
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
Testing: convert -o help
Supported options:
size Virtual disk size
iotests: Test help option for unsupporting formats This adds test cases to 082 for qemu-img create/convert/amend "-o help" on formats that do not support creation or amendment, respectively. Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20180509210023.20283-7-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2018-05-10 00:00:22 +03:00
Testing: amend -f bochs -o help
qemu-img: Format driver 'bochs' does not support option amendment
qemu-iotests: Check qemu-img command line parsing Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2014-02-21 19:24:08 +04:00
*** done