2013-05-03 18:25:37 +04:00
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
< html xmlns = "http://www.w3.org/1999/xhtml" >
2009-08-19 23:50:10 +04:00
< body >
< h1 > Storage volume encryption XML format< / h1 >
< ul id = "toc" > < / ul >
< h2 > < a name = "StorageEncryption" > Storage volume encryption XML< / a > < / h2 >
< p >
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.
< / p >
< p >
The top-level tag of volume encryption specification
is < code > encryption< / code > , with a mandatory
attribute < code > format< / code > . Currently defined values
of < code > format< / code > are < code > default< / code > and < code > qcow< / code > .
Each value of < code > format< / code > implies some expectations about the
content of the < code > encryption< / code > tag. Other format values may be
defined in the future.
< / p >
< p >
The < code > encryption< / code > tag can currently contain a sequence of
< code > secret< / code > tags, each with mandatory attributes < code > type< / code >
2016-05-30 14:47:46 +03:00
and either < code > uuid< / code > or < code > usage< / code >
(< span class = "since" > since 2.1.0< / span > ). The only currently defined
2016-07-11 13:59:03 +03:00
value of < code > type< / code > is < code > volume< / code > . The
2016-05-30 14:47:46 +03:00
< code > uuid< / code > is "uuid" of the < code > secret< / code > while
2016-07-11 13:59:03 +03:00
< code > usage< / code > is the "usage" subelement field.
2016-05-30 14:47:46 +03:00
A secret value can be set in libvirt by the
< a href = "html/libvirt-libvirt-secret.html#virSecretSetValue" >
< code > virSecretSetValue< / code > < / a > API. Alternatively, if supported
2009-08-19 23:50:10 +04:00
by the particular volume format and driver, automatically generate a
secret value at the time of volume creation, and store it using the
specified < code > uuid< / code > .
2011-04-02 02:02:10 +04:00
< / p >
2009-08-19 23:50:10 +04:00
< h3 > < a name = "StorageEncryptionDefault" > "default" format< / a > < / h3 >
< p >
2014-09-10 11:25:40 +04:00
< code > < encryption format="default"/> < / code > can be specified only
2016-07-11 13:59:03 +03:00
when creating a qcow volume. If the volume is successfully created, the
2009-08-19 23:50:10 +04:00
encryption formats, parameters and secrets will be auto-generated by
libvirt and the attached < code > encryption< / code > tag will be updated.
The unmodified contents of the < code > encryption< / code > tag can be used
in later operations with the volume, or when setting up a domain that
uses the volume.
< / p >
< h3 > < a name = "StorageEncryptionQcow" > "qcow" format< / a > < / h3 >
< p >
The < code > qcow< / code > format specifies that the built-in encryption
support in < code > qcow< / code > - or < code > qcow2< / code > -formatted volume
images should be used. A single
< code > < secret type='passphrase'> < / code > element is expected. If
the < code > secret< / code > element is not present during volume creation,
a secret is automatically generated and attached to the volume.
< / p >
2016-06-01 22:01:31 +03:00
< h3 > < a name = "StorageEncryptionLuks" > "luks" format< / a > < / h3 >
< p >
The < code > luks< / code > format is specific to a luks encrypted volume
2016-07-11 13:59:03 +03:00
and the secret is used in order to either encrypt during volume creation
or decrypt the volume for usage by the domain. A single
< code > < secret type='passphrase'...> < / code > element is expected.
2016-06-01 22:01:31 +03:00
< span class = "since" > Since 2.1.0< / span > .
< / p >
2016-06-02 02:21:26 +03:00
< p >
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.
< / p >
< dl >
< dt > < code > cipher< / code > < / dt >
< dd > This element describes the cipher algorithm to be used to either
encrypt or decrypt the luks volume. This element has the following
attributes:
< dl >
< dt > < code > name< / code > < / dt >
< dd > The name of the cipher algorithm used for data encryption,
such as 'aes', 'des', 'cast5', 'serpent', 'twofish', etc.
Support of the specific algorithm is storage driver
implementation dependent.< / dd >
< dt > < code > size< / code > < / dt >
< dd > The size of the cipher in bits, such as '256', '192', '128',
etc. Support of the specific size for a specific cipher is
hypervisor dependent.< / dd >
< dt > < code > mode< / code > < / dt >
< dd > An optional cipher algorithm mode such as 'cbc', 'xts',
'ecb', etc. Support of the specific cipher mode is
hypervisor dependent.< / dd >
< dt > < code > hash< / code > < / dt >
< dd > An optional master key hash algorithm such as 'md5', 'sha1',
'sha256', etc. Support of the specific hash algorithm is
hypervisor dependent.< / dd >
< / dl >
< / dd >
< dt > < code > ivgen< / code > < / dt >
< dd > This optional element describes the initialization vector
generation algorithm used in conjunction with the
< code > cipher< / code > . If the < code > cipher< / code > is not provided,
then an error will be generated by the parser.
< dl >
< dt > < code > name< / code > < / dt >
< dd > The name of the algorithm, such as 'plain', 'plain64',
'essiv', etc. Support of the specific algorithm is hypervisor
dependent.< / dd >
< dt > < code > hash< / code > < / dt >
< dd > An optional hash algorithm such as 'md5', 'sha1', 'sha256',
etc. Support of the specific ivgen hash algorithm is hypervisor
dependent.< / dd >
< / dl >
< / dd >
< / dl >
2009-08-19 23:50:10 +04:00
2016-06-01 22:01:31 +03:00
< h2 > < a name = "example" > Examples< / a > < / h2 >
2009-08-19 23:50:10 +04:00
< p >
Here is a simple example, specifying use of the < code > qcow< / code > format:
< / p >
< pre >
< encryption format='qcow'>
< secret type='passphrase' uuid='c1f11a6d-8c5d-4a3e-ac7a-4e171c5e0d4a' />
< /encryption> < / pre >
2016-06-01 22:01:31 +03:00
< p >
2016-07-11 13:59:03 +03:00
Assuming a < a href = "formatsecret.html#VolumeUsageType" >
< code > luks volume type secret< / code > < / a > is already defined,
2016-06-02 02:21:26 +03:00
a simple example specifying use of the < code > luks< / code > format
for either volume creation without a specific cipher being defined or
as part of a domain volume definition:
2016-06-01 22:01:31 +03:00
< / p >
< pre >
< encryption format='luks'>
2016-07-11 13:59:03 +03:00
< secret type='passphrase' uuid='f52a81b2-424e-490c-823d-6bd4235bc572'/>
2016-06-01 22:01:31 +03:00
< /encryption>
< / pre >
2016-06-02 02:21:26 +03:00
< p >
2016-07-11 13:59:03 +03:00
Here is an example specifying use of the < code > luks< / code > format for
a specific cipher algorithm for volume creation:
2016-06-02 02:21:26 +03:00
< / p >
< pre >
< volume>
< name> twofish.luks< /name>
< capacity unit='G'> 5< /capacity>
< target>
< path> /var/lib/libvirt/images/demo.luks< /path>
storage: remove "luks" storage volume type
The current LUKS support has a "luks" volume type which has
a "luks" encryption format.
This partially makes sense if you consider the QEMU shorthand
syntax only requires you to specify a format=luks, and it'll
automagically uses "raw" as the next level driver. QEMU will
however let you override the "raw" with any other driver it
supports (vmdk, qcow, rbd, iscsi, etc, etc)
IOW the intention though is that the "luks" encryption format
is applied to all disk formats (whether raw, qcow2, rbd, gluster
or whatever). As such it doesn't make much sense for libvirt
to say the volume type is "luks" - we should be saying that it
is a "raw" file, but with "luks" encryption applied.
IOW, when creating a storage volume we should use this XML
<volume>
<name>demo.raw</name>
<capacity>5368709120</capacity>
<target>
<format type='raw'/>
<encryption format='luks'>
<secret type='passphrase' uuid='0a81f5b2-8403-7b23-c8d6-21ccd2f80d6f'/>
</encryption>
</target>
</volume>
and when configuring a guest disk we should use
<disk type='file' device='disk'>
<driver name='qemu' type='raw'/>
<source file='/home/berrange/VirtualMachines/demo.raw'/>
<target dev='sda' bus='scsi'/>
<encryption format='luks'>
<secret type='passphrase' uuid='0a81f5b2-8403-7b23-c8d6-21ccd2f80d6f'/>
</encryption>
</disk>
This commit thus removes the "luks" storage volume type added
in
commit 318ebb36f1027b3357a32d6f781bd77d7a9043fd
Author: John Ferlan <jferlan@redhat.com>
Date: Tue Jun 21 12:59:54 2016 -0400
util: Add 'luks' to the FileTypeInfo
The storage file probing code is modified so that it can probe
the actual encryption formats explicitly, rather than merely
probing existance of encryption and letting the storage driver
guess the format.
The rest of the code is then adapted to deal with
VIR_STORAGE_FILE_RAW w/ VIR_STORAGE_ENCRYPTION_FORMAT_LUKS
instead of just VIR_STORAGE_FILE_LUKS.
The commit mentioned above was included in libvirt v2.0.0.
So when querying volume XML this will be a change in behaviour
vs the 2.0.0 release - it'll report 'raw' instead of 'luks'
for the volume format, but still report 'luks' for encryption
format. I think this change is OK because the storage driver
did not include any support for creating volumes, nor starting
guets with luks volumes in v2.0.0 - that only since then.
Clearly if we change this we must do it before v2.1.0 though.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2016-07-26 19:41:46 +03:00
< format type='raw'/>
2016-06-02 02:21:26 +03:00
< encryption format='luks'>
2016-07-11 13:59:03 +03:00
< secret type='passphrase' uuid='f52a81b2-424e-490c-823d-6bd4235bc572'/>
2016-06-02 02:21:26 +03:00
< cipher name='twofish' size='256' mode='cbc' hash='sha256'/>
< ivgen name='plain64' hash='sha256'/>
< /encryption>
< /target>
< /volume>
< / pre >
2009-08-19 23:50:10 +04:00
< / body >
< / html >
