Add test code which will crawl a fake internal list of checkpoints and
generate the list of bitmaps for merging to gather the final bitmap for
the backup.
The initial tests cover the basic case of all bitmaps being present in
the top layer of the backing chain.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Add test data gathered from a run of qemu after creating bitmaps and
snapshots together in various combinations.
The following sequence of commands was used to achieve the
configuration:
virsh checkpoint-create-as VM --name a
virsh snapshot-create-as VM --disk-only
virsh snapshot-create-as VM --disk-only
virsh checkpoint-create-as VM --name b
virsh checkpoint-create-as VM --name c
virsh snapshot-create-as VM --disk-only
virsh checkpoint-create-as VM --name d
virsh snapshot-create-as VM --disk-only
virsh checkpoint-create-as VM --name current
Note that VM was restarted after these operations to allow renumbering
of the bitmaps in a more human-readable way.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
The real data gathered for the 'basic' test case don't exercise some
fields. Add a copy with a few values modified manually.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Test the extraction of data about changed block tracking bitmaps. The
first test case adds a simple scenario of multiple bitmaps in one layer.
The test data will be also later reused for testing the code that
determines which bitmaps to merge for an incremental backup.
The sequence of bitmaps was created by the libvirt checkpoint API with
the following sequence of commands:
virsh checkpoint-create-as VM --name a
virsh checkpoint-create-as VM --name b
virsh checkpoint-create-as VM --name c
virsh checkpoint-create-as VM --name d
virsh checkpoint-create-as VM --name current
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
In case when the backing store can be represented with something
simpler such as a URI we can use it rather than falling back to the
json: pseudo-protocol.
In cases when it's not worth it (e.g. with the old ugly NBD or RBD
strings) let's switch to json.
The function is exported as we'll need it when overwriting the ugly
strings qemu would come up with during blockjobs.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Test the output against the schema and also against what we expect.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
To allow using -blockdev with blockjobs QEMU needs to reopen files in
read-write mode when modifying the backing chain. To achieve this we
need to use 'auto-read-only' for the backing files rather than the
normal 'read-only' property. That way qemu knows that the files need to
be reopened.
Note that the format drivers (e.g. qcow2) are still opened with the
read-only property enabled when being a member of the backing chain
since they are supposed to be immutable unless a block job is started.
QEMU v4.0 (since commit 23dece19da4) allows also dynamic behaviour for
auto-read-only which allows us to use sVirt as we only grant write
permissions to files when doing a blockjob.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add testing of the host specification part so that we can be sure that
no image/host specific data will be present.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
To allow using -blockdev with RBD we need to support the recently added
RBD authentication.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
To keep feature parity, we need to be able to format the PR manager
alias when using blockdev.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The next patch will forbid the old qcow2 encryption completely. Remove
it from the tests.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reference the storage via node name rather than inlining it. This is
the approach that will be used with -blockdev/blockdev-add since it
allows more control and is more future proof.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Make sure that 'host_device' is generated for type='block'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The test cases would correspond to the following -drive command lines:
file-backing_basic-detect.xml:
-drive file=/var/lib/libvirt/images/a,format=qcow,if=none,id=drive-dummy,detect-zeroes=on
-device virtio-blk-pci,scsi=off,drive=drive-dummy,id=dummy
file-backing_basic-unmap-detect.xml:
-drive file=/var/lib/libvirt/images/a,format=qcow,if=none,id=drive-dummy,discard=unmap,detect-zeroes=unmap
-device virtio-blk-pci,scsi=off,drive=drive-dummy,id=dummy
file-backing_basic-unmap-ignore.xml:
-drive file=/var/lib/libvirt/images/a,format=qcow,if=none,id=drive-dummy,discard=ignore,detect-zeroes=on
-device virtio-blk-pci,scsi=off,drive=drive-dummy,id=dummy
file-backing_basic-unmap.xml:
-drive file=/var/lib/libvirt/images/a,format=qcow,if=none,id=drive-dummy,discard=unmap
-device virtio-blk-pci,scsi=off,drive=drive-dummy,id=dummy
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
iscsi and rbd support authentication of the connection. Combine it with
encryption of qcow2.
The top level disk image would generate the following '-drive' cmdline:
-drive file=rbd:rbdpool/rbdimg:id=testuser-rbd:auth_supported=cephx\;none:
mon_host=host1.example.com\;host2.example.com,
file.password-secret=node-a-s-secalias,encrypt.format=luks,
encrypt.key-secret=node-b-f-encalias,format=qcow2,
if=none,id=drive-dummy
-device virtio-blk-pci,scsi=off,drive=drive-dummy,id=dummy
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Add tests for backing chain handling, including a very long chain which
is fully specified in the XML and an unterminated chain.
The top level disk image would generate the following '-drive':
file-qcow2-backing-chain-encryption.xml:
-drive file=/var/lib/libvirt/images/a,encrypt.format=luks,
encrypt.key-secret=node-b-f-encalias,format=qcow2,if=none,id=drive-dummy
-device virtio-blk-pci,scsi=off,drive=drive-dummy,id=dummy
file-qcow2-backing-chain-noopts.xml:
-drive file=/var/lib/libvirt/images/rhel7.3.1507297895,format=qcow2,if=none,id=drive-dummy
-device virtio-blk-pci,scsi=off,drive=drive-dummy,id=dummy
file-qcow2-backing-chain-unterminated.xml:
-drive file=/var/lib/libvirt/images/rhel7.3.1507297895,format=qcow2,if=none,id=drive-dummy
-device virtio-blk-pci,scsi=off,drive=drive-dummy,id=dummy
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Apart from adding test data add a function which sets up fake secrets
for the test.
The top level disk image would generate the following '-drive' cmdline:
-drive file=/path/luks.img,key-secret=test1-encalias,format=luks,if=none,id=drive-dummy
-device virtio-blk-pci,scsi=off,drive=drive-dummy,id=dummy
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Test that the 'aio' option is applied correctly for the 'file' protocol
backend and across the backing chain.
The top level disk image would generate the following '-drive' cmdline:
file-backing_basic-aio_threads:
-drive file=/var/lib/libvirt/images/a,format=qcow,if=none,id=drive-dummy,aio=threads
-device virtio-blk-pci,scsi=off,drive=drive-dummy,id=dummy
file-raw-aio_native:
-drive file=/path/to/i.img,format=raw,if=none,id=drive-dummy,cache=none,aio=native
-device virtio-blk-pci,scsi=off,drive=drive-dummy,id=dummy,write-cache=on
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Test mapping of the 'FAT' disk format to 'vvfat' in qemu.
The top level disk image would generate the following '-drive' cmdline:
dir-fat-readonly.xml:
-drive file=fat:/var/somefiles,if=none,id=drive-dummy,readonly=on
-device virtio-blk-pci,scsi=off,drive=drive-dummy,id=dummy
dir-fat-floppy.xml
-drive file=fat:floppy:/var/somefiles,if=none,id=drive-dummy,readonly=on
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Formats supporting backing chain such as qed, vmdk, don't have any other
parameters than the backing store and 'qcow' has only encryption params
which will be tested extra. Add this test case so they are covered since
any further test cases will mainly care about 'qcow2' and 'raw'.
The top level disk image would generate the following '-drive' cmdline:
-drive file=/var/lib/libvirt/images/a,format=qed,if=none,id=drive-dummy
-device virtio-blk-pci,scsi=off,drive=drive-dummy,id=dummy
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Similarly to the 'raw' case add tests for bochs, cloop, dmg, ploop, vdi
vhd, and vpc. Covering all supported non-backing formats.
Note that the JSON name for 'ploop' maps to 'parallels' and 'vhd' maps
to 'vhdx'.
Files added here would result in the followint configs:
file-bochs-noopts.xml:
-drive file=/path/to/i.img,format=bochs,if=none,id=drive-dummy
-device virtio-blk-pci,scsi=off,drive=drive-dummy,id=dummy
file-cloop-noopts.xml:
-drive file=/path/to/i.img,format=cloop,if=none,id=drive-dummy
-device virtio-blk-pci,scsi=off,drive=drive-dummy,id=dummy
file-dmg-noopts.xml:
-drive file=/path/to/i.img,format=dmg,if=none,id=drive-dummy
-device virtio-blk-pci,scsi=off,drive=drive-dummy,id=dummy
file-ploop-noopts.xml:
-drive file=/path/to/i.img,format=ploop,if=none,id=drive-dummy
-device virtio-blk-pci,scsi=off,drive=drive-dummy,id=dummy
file-vdi-noopts.xml:
-drive file=/path/to/i.img,format=vdi,if=none,id=drive-dummy
-device virtio-blk-pci,scsi=off,drive=drive-dummy,id=dummy
file-vhd-noopts.xml:
-drive file=/path/to/i.img,format=vhd,if=none,id=drive-dummy
-device virtio-blk-pci,scsi=off,drive=drive-dummy,id=dummy
file-vpc-noopts.xml:
-drive file=/path/to/i.img,format=vpc,if=none,id=drive-dummy
-device virtio-blk-pci,scsi=off,drive=drive-dummy,id=dummy
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Test the JSON props generator with a very simple 'raw' image with no
other options. The node-names for the image are 31 bytes long so that we
validate our node name detector.
The top level disk image would generate the following '-drive' cmdline:
-drive file=/var/lib/libvirt/images/i.img,format=raw,if=none,id=drive-dummy
-device virtio-blk-pci,scsi=off,drive=drive-dummy,id=dummy
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Add a test infrastructure that will allow testing the JSON object
generator used for generating data to use with blockdev-add.
The resulting disk including the backing chain is validated to conform
to the QAPI schema and the expected output files.
The first test cases make sure that libvirt will not allow nodenames
exceeding 31 chars.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
