Storage volume encryption XML format
Storage volume encryption XML ¶
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 and qcow.
      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.
    
"default" format ¶
      <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.
    
"qcow" format ¶
      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.  If
      the secret element is not present during volume creation,
      a secret is automatically generated and attached to the volume.
    
"luks" format ¶
      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
- This element describes the cipher algorithm to be used to either
          encrypt or decrypt the luks volume. This element has the following
          attributes:
          - name
- 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.
- size
- 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.
- mode
- An optional cipher algorithm mode such as 'cbc', 'xts', 'ecb', etc. Support of the specific cipher mode is hypervisor dependent.
- hash
- An optional master key hash algorithm such as 'md5', 'sha1', 'sha256', etc. Support of the specific hash algorithm is hypervisor dependent.
 
- ivgen
- This optional element describes the initialization vector
          generation algorithm used in conjunction with the
          cipher. If thecipheris not provided, then an error will be generated by the parser.- name
- The name of the algorithm, such as 'plain', 'plain64', 'essiv', etc. Support of the specific algorithm is hypervisor dependent.
- hash
- An optional hash algorithm such as 'md5', 'sha1', 'sha256', etc. Support of the specific ivgen hash algorithm is hypervisor dependent.
 
Examples ¶
      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>