Storage volumes may be encrypted, the XML snippet described below is used to represent the details of the encryption. It can be used as a part of a domain or storage configuration.
The top-level tag of volume encryption specification
is encryption
, with a mandatory
attribute format
. Currently defined values
of format
are default
, qcow
,
and luks
.
Each value of format
implies some expectations about the
content of the encryption
tag. Other format values may be
defined in the future.
The encryption
tag can currently contain a sequence of
secret
tags, each with mandatory attributes type
and either uuid
or usage
(since 2.1.0). The only currently defined
value of type
is volume
. The
uuid
is "uuid" of the secret
while
usage
is the "usage" subelement field.
A secret value can be set in libvirt by the
virSecretSetValue
API. Alternatively, if supported
by the particular volume format and driver, automatically generate a
secret value at the time of volume creation, and store it using the
specified uuid
.
<encryption format="default"/>
can be specified only
when creating a qcow volume. If the volume is successfully created, the
encryption formats, parameters and secrets will be auto-generated by
libvirt and the attached encryption
tag will be updated.
The unmodified contents of the encryption
tag can be used
in later operations with the volume, or when setting up a domain that
uses the volume.
The qcow
format specifies that the built-in encryption
support in qcow
- or qcow2
-formatted volume
images should be used. A single
<secret type='passphrase'>
element is expected. Note
that this encryption is inherently broken and should not be used any more.
The luks
format is specific to a luks encrypted volume
and the secret is used in order to either encrypt during volume creation
or decrypt the volume for usage by the domain. A single
<secret type='passphrase'...>
element is expected.
Since 2.1.0.
For volume creation, it is possible to specify the encryption algorithm used to encrypt the luks volume. The following two optional elements may be provided for that purpose. It is hypervisor dependent as to which algorithms are supported. The default algorithm used by the storage driver backend when using qemu-img to create the volume is 'aes-256-cbc' using 'essiv' for initialization vector generation and 'sha256' hash algorithm for both the cipher and the initialization vector generation.
cipher
name
size
mode
hash
ivgen
cipher
. If the cipher
is not provided,
then an error will be generated by the parser.
name
hash
Here is a simple example, specifying use of the qcow
format:
<encryption format='qcow'> <secret type='passphrase' uuid='c1f11a6d-8c5d-4a3e-ac7a-4e171c5e0d4a' /> </encryption>
Assuming a
luks volume type secret
is already defined,
a simple example specifying use of the luks
format
for either volume creation without a specific cipher being defined or
as part of a domain volume definition:
<encryption format='luks'> <secret type='passphrase' uuid='f52a81b2-424e-490c-823d-6bd4235bc572'/> </encryption>
Here is an example specifying use of the luks
format for
a specific cipher algorithm for volume creation:
<volume> <name>twofish.luks</name> <capacity unit='G'>5</capacity> <target> <path>/var/lib/libvirt/images/demo.luks</path> <format type='raw'/> <encryption format='luks'> <secret type='passphrase' uuid='f52a81b2-424e-490c-823d-6bd4235bc572'/> <cipher name='twofish' size='256' mode='cbc' hash='sha256'/> <ivgen name='plain64' hash='sha256'/> </encryption> </target> </volume>