Commit Graph

26 Commits

Author SHA1 Message Date
Daniel P. Berrangé
912c6b22fc util: require command args to be non-NULL
The virCommand APIs do not expect to be given a NULL value for an arg
name or value. Such a mistake can lead to execution of the wrong
command, as the NULL may prematurely terminate the list of args.
Detect this and report suitable error messages.

This identified a flaw in the storage test which was passing a NULL
instead of the volume path. This flaw was then validated by an incorrect
set of qemu-img args as expected data.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-12-17 14:43:33 +00:00
John Ferlan
b975afc725 storage: Allow inputvol to be encrypted
https://bugzilla.redhat.com/show_bug.cgi?id=1613737

When processing the inputvol for encryption, we need to handle
the case where the inputvol is encrypted. This then allows for
the encrypted inputvol to be used either for an output encrypted
volume or an output volume of some XML provided type.

Add tests to show the various conversion options when either input
or output is encrypted. This includes when both are encrypted.

Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
2018-09-12 07:24:04 -04:00
John Ferlan
8041471858 storage: Allow for inputvol to have any format for encryption
Commit 39cef12a9 altered/fixed the inputvol processing to create
a multistep process when using an inputvol to create an encrypted
output volume; however, it unnecessarily assumed/restricted the
inputvol to be of 'raw' format only.

Modify the processing code to allow the inputvol format to be checked
and used in order to create the encrypted volume.

Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
2018-09-12 07:24:04 -04:00
John Ferlan
39cef12a95 storage: Add support for using inputvol for encryption
Starting with QEMU 2.9, encryption convert processing requires
a multi-step process in order to generate an encrypted image from
some non encrypted raw image.

Processing requires to first create an encrypted image using the
sizing parameters from the input source and second to use the
--image-opts, -n, and --target-image-opts options along with inline
driver options to describe the input and output files, generating
two commands such as:

  $ qemu-img create -f luks \
      --object secret,id=demo.img_encrypt0,file=/path/to/secretFile \
      -o key-secret=demo.img_encrypt0 \
      demo.img 500K
  Formatting 'demo.img', fmt=luks size=512000 key-secret=demo.img_encrypt0
  $ qemu-img convert --image-opts -n --target-image-opts \
      --object secret,id=demo.img_encrypt0,file=/path/to/secretFile \
      driver=raw,file.filename=sparse.img \
      driver=luks,file.filename=demo.img,key-secret=demo.img_encrypt0
  $

This patch handles the convert processing by running the processing
in a do..while loop essentially reusing the existing create logic and
arguments to create the target vol from the inputvol and then converting
the inputvol using new arguments.

This then allows the following virsh command to work properly:

  virsh vol-create-from default encrypt1-luks.xml data.img --inputpool default

where encrypt1-luks.xml would provided the path and secret for
the new image, while data.img would be the source image.

Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
2018-06-26 14:02:43 -04:00
John Ferlan
8f83af6823 storage: Disallow create/resize of qcow2 encrypted images
https://bugzilla.redhat.com/show_bug.cgi?id=1526382

Since commit c4eedd793 disallowed qcow2 encrypted images to be
used for domains, it no longer makes sense to allow a qcow2
encrypted volume to be created or resized.

Add a test that will exhibit the failure of creation as well
as the xml2xml validation of the format still being correct.

Update the documentation to note the removal of the capability
to create and use qcow/default encrypted volumes.

Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
2018-06-26 14:02:43 -04:00
John Ferlan
a02d879858 tests: Remove qcow2 encryption from storagevol tests
We're about to disallow creation of a qcow2 encrypted storage
volume, so let's remove the qcow encryption element from the
tests which are testing whether other format='qcow2' related
features work properly.

Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
2018-06-26 14:02:43 -04:00
Cole Robinson
0de1066fb9 tests: Add storagevol tests for format=iso
Demonstrates the bug fix in commit 0e5db76262
2017-03-08 13:22:33 -05:00
Daniel P. Berrange
a48c714115 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 318ebb36f1
  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-27 18:59:15 +01:00
John Ferlan
a8d0afc75a tests: Adjust LUKS tests to use 'volume' secret type
Commit id's '9bbf0d7e6' and '2552fec24' added some XML parsing tests
for a LUKS volume to use a 'passphrase' secret format. After commit,
this was deemed to be incorrect, so covert the various tests to use
the volume usage format where the 'usage' is the path to the volume
rather than a user defined name string.

Also, removed the qemuxml2argv-luks-disk-cipher.xml since it was
just a duplicate of qemuxml2argv-luks-disks.xml.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2016-07-14 13:01:58 -04:00
John Ferlan
2552fec248 encryption: Add <cipher> and <ivgen> to encryption
For a luks device, allow the configuration of a specific cipher to be
used for encrypting the volume.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2016-07-01 15:46:57 -04:00
John Ferlan
9bbf0d7e64 encryption: Add luks parsing for storageencryption
Add parse and format of the luks/passphrase secret including tests for
volume XML parsing.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2016-07-01 15:46:52 -04:00
Chris J Arges
be6c35e4ac tests: add vol-qcow2-zerocapacity test to storagevolxml2argvtest
Add a testcase for the previous change to ensure zero capacity volumes can be
defined without a backing store.

Signed-off-by: Chris J Arges <chris.j.arges@canonical.com>
2015-07-24 11:23:45 -04:00
Ján Tomko
155ca616eb Allow creating volumes with a backing store but no capacity
The tool creating the image can get the capacity from the backing
storage. Just refresh the volume afterwards.

https://bugzilla.redhat.com/show_bug.cgi?id=958510
2015-03-02 08:07:11 +01:00
Ján Tomko
e3f1d2a820 Allow cloning volumes with no capacity specified
In virStorageVolCreateXML, add VIR_VOL_XML_PARSE_NO_CAPACITY
to the call parsing the XML of the new volume to make the capacity
optional.

If the capacity is omitted, use the capacity of the old volume.
We already do that for values that are less than the original
volume capacity.
2015-03-02 08:07:11 +01:00
Martin Kletzander
d2632d60aa storage: unify permission formatting
Volume and pool formatting functions took different approaches to
unspecified uids/gids.  When unknown, it is always parsed as -1, but one
of the functions formatted it as unsigned int (wrong) and one as
int (better).  Due to that, our two of our XML files from tests cannot
be parsed on 32-bit machines.

RNG schema needs to be modified as well, but because both
storagepool.rng and storagevol.rng need same schema for permission
element, save some space by moving it to storagecommon.rng.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2014-12-16 15:47:56 +01:00
Chunyan Liu
0b0c641b66 add nocow test case
Add file in storagevolxml2xmlin and storagevolxml2xmlout, let
storagevolxml2xmltest and storagevolschematest cover 'nocow'.
Add test case to storagevolxml2argvtest to cover 'nocow'.

Signed-off-by: Chunyan Liu <cyliu@suse.com>
2014-07-16 13:35:26 +02:00
Eric Blake
1458b2e963 storage: improve directory support in gluster pool
Take advantage of the previous patch's addition of 'netdir' as
a distinct volume type, to expose rather than silently skip
directories embedded in a gluster pool.  Also serves as an XML
validation for the previous patch.

* src/storage/storage_backend_gluster.c
(virStorageBackendGlusterRefreshVol): Don't skip directories.
* tests/storagevolxml2xmltest.c (mymain): Add test.
* tests/storagevolxml2xmlin/vol-gluster-dir.xml: New file.
* tests/storagevolxml2xmlout/vol-gluster-dir.xml: Likewise.

Signed-off-by: Eric Blake <eblake@redhat.com>
2013-11-25 12:46:19 -07:00
Eric Blake
1b5c8d4cbc storage: expose volume meta-type in XML
I got annoyed at having to use both 'virsh vol-list $pool --details'
AND 'virsh vol-dumpxml $vol $pool' to learn if I had populated
the volume correctly.  Since two-thirds of the data present in
virStorageVolGetInfo() already appears in virStorageVolGetXMLDesc(),
this just adds the remaining piece of information, as:

<volume type='...'>
  ...
</volume>

* docs/formatstorage.html.in: Document new <volume type=...>.
* docs/schemas/storagevol.rng (vol): Add it to RelaxNG.
* src/conf/storage_conf.h (virStorageVolTypeToString): Declare.
* src/conf/storage_conf.c (virStorageVolTargetDefFormat): Output
the metatype.
(virStorageVolDefParseXML): Parse it, for unit tests.
* tests/storagevolxml2xmlout/vol-*.xml: Update tests to match.

Signed-off-by: Eric Blake <eblake@redhat.com>
2013-11-25 10:55:19 -07:00
Eric Blake
f5580bd6d6 storage: allow interleave in volume XML
The RNG grammar did not allow arbitrary interleaving, which makes
it harder than necessary to create a new volume from handwritten XML.
(Compare also to commit caf516db for pools).

* docs/schemas/storagevol.rng: Support interleaving.
* tests/storagevolxml2xmlin/vol-file-backing.xml: Test it.

Signed-off-by: Eric Blake <eblake@redhat.com>
2013-11-25 07:51:14 -07:00
Eric Blake
6cc4d6a3fe storage: use valid XML for awkward volume names
$ touch /var/lib/libvirt/images/'a<b>c'
$ virsh pool-refresh default
$ virsh vol-dumpxml 'a<b>c' default | head -n2
<volume>
  <name>a<b>c</name>

Oops.  That's not valid XML.  And when we fix the XML
generation, it fails RelaxNG validation.

I'm also tired of seeing <key>(null)</key> in the example
output for volume xml; while we used NULLSTR() to avoid
a NULL deref rather than relying on glibc's printf
extension behavior, it's even better if we avoid the issue
in the first place.  But this requires being careful that
we don't invalidate any storage backends that were relying
on key being unassigned during virStoragVolCreateXML[From].

I would have split this into two patches (one for escaping,
one for avoiding <key>(null)</key>), but since they both
end up touching a lot of the same test files, I ended up
merging it into one.

Note that this patch allows pretty much any volume name
that can appear in a directory (excluding . and .. because
those are special), but does nothing to change the current
(unenforced) RelaxNG claim that pool names will consist
only of letters, numbers, _, -, and +.  Tightening the C
code to match RelaxNG patterns and/or relaxing the grammar
to match the C code for pool names is a task for another
day (but remember, we DID recently tighten C code for
domain names to exclude a leading '.').

* src/conf/storage_conf.c (virStoragePoolSourceFormat)
(virStoragePoolDefFormat, virStorageVolTargetDefFormat)
(virStorageVolDefFormat): Escape user-controlled strings.
(virStorageVolDefParseXML): Parse key, for use in unit tests.
* src/storage/storage_driver.c (storageVolCreateXML)
(storageVolCreateXMLFrom): Ensure parsed key doesn't confuse
volume creation.
* docs/schemas/basictypes.rng (volName): Relax definition.
* tests/storagepoolxml2xmltest.c (mymain): Test it.
* tests/storagevolxml2xmltest.c (mymain): Likewise.
* tests/storagepoolxml2xmlin/pool-dir-naming.xml: New file.
* tests/storagepoolxml2xmlout/pool-dir-naming.xml: Likewise.
* tests/storagevolxml2xmlin/vol-file-naming.xml: Likewise.
* tests/storagevolxml2xmlout/vol-file-naming.xml: Likewise.
* tests/storagevolxml2xmlout/vol-*.xml: Fix fallout.

Signed-off-by: Eric Blake <eblake@redhat.com>
2013-11-21 17:29:47 -07:00
Ján Tomko
3a75fca289 Move volume XMLs out of storagevolxml2argvdata
Reuse the XML files in storagevolxml2xmlin.

(This requires changing a few backing files to /dev/null,
since virStorageBackendCreateQemuImgCmd checks for its
presence)
2013-07-25 13:26:41 +02:00
Ján Tomko
31d42506fb conf: add features to volume target XML
Add <features> and <compat> elements to volume target XML.

<compat> is a string which for qcow2 represents the QEMU version
it should be compatible with. Valid values are 0.10 and 1.1.
1.1 is implicit if the <features> element is present, otherwise
qemu-img default is used. 0.10 can be specified to explicitly
create older images after the qemu-img default changes.

<features> contains optional features, so far
<lazy_refcounts/> is available, which enables caching of reference
counters, improving performance for snapshots.
2013-06-21 13:25:30 +02:00
Hendrik Schwartke
7383c1d762 Added timestamps to storage volumes
The access, birth, modification and change times are added to
storage volumes and corresponding xml representations.  This
shows up in the XML in this format:

<timestamps>
  <atime>1341933637.027319099</atime>
  <mtime>1341933637.027319099</mtime>
</timestamps>

Signed-off-by: Eric Blake <eblake@redhat.com>
2012-08-02 17:14:17 -06:00
Sebastian Wiedenroth
29bc4fe646 Add a sheepdog backend for the storage driver
This patch brings support to manage sheepdog pools and volumes to libvirt.
It uses the "collie" command-line utility that comes with sheepdog for that.

A sheepdog pool in libvirt maps to a sheepdog cluster.
It needs a host and port to connect to, which in most cases
is just going to be the default of localhost on port 7000.

A sheepdog volume in libvirt maps to a sheepdog vdi.
To create one specify the pool, a name and the capacity.
Volumes can also be resized later.

In the volume XML the vdi name has to be put into the <target><path>.
To use the volume as a disk source for virtual machines specify
the vdi name as "name" attribute of the <source>.
The host and port information from the pool are specified inside the host tag.

  <disk type='network'>
    ...
    <source protocol="sheepdog" name="vdi_name">
      <host name="localhost" port="7000"/>
    </source>
  </disk>

To work right this patch parses the output of collie,
so it relies on the raw output option. There recently was a bug which caused
size information to be reported wrong. This is fixed upstream already and
will be in the next release.

Signed-off-by: Sebastian Wiedenroth <wiedi@frubar.net>
2012-07-18 20:08:27 +01:00
Eric Blake
2e14861224 storage: support more scaling suffixes
Disk manufacturers are fond of quoting sizes in powers of 10,
rather than powers of 2 (after all, 2.1 GB sounds larger than
2.0 GiB, even though the exact opposite is true).  So, we might
as well follow coreutils' lead in supporting three types of
suffix: single letter ${u} (which we already had) and ${u}iB
for the power of 2, and ${u}B for power of 10.

Additionally, it is impossible to create a file with more than
2**63 bytes, since off_t is signed (if you have enough storage
to even create one 8EiB file, I'm jealous).  This now reports
failure up front rather than down the road when the kernel
finally refuses an impossible size.

* docs/schemas/basictypes.rng (unit): Add suffixes.
* src/conf/storage_conf.c (virStorageSize): Use new function.
* docs/formatstorage.html.in: Document it.
* tests/storagevolxml2xmlin/vol-file-backing.xml: Test it.
* tests/storagevolxml2xmlin/vol-file.xml: Likewise.
2012-03-07 18:24:43 -07:00
Cole Robinson
caf8e91588 tests: Add storage volume XML 2 XML tests. 2009-10-16 10:52:27 -04:00