IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Remove the call to the validating function from the function which sets
stuff up.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Convert the function to just prepare data for the disk. Callers need to
do the looping since there's more to do than just copy the data around.
The code path in qemuDomainPrepareDiskSource doesn't need to loop over
the chain yet, since there currently is no chain at this point. This
will be addressed later in the blockdev series where we will setup much
more stuff.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When restarting libvirt would previously lose the alias of the x509
certificate object. Upon unplug we would then not delete the
corresponding objects.
Restore the alias if we know it should be there.
Luckily for disks we don't support encrypted TLS environment, so there's
no need to regenerate the 'secret' alias for decryption.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Libvirt uses the stored alias to detach the TLS x509 object on disk
unplug. As the alias was not stored, the object would not be detached
if unplugging disks after libvirtd restart.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Previously we did not store the aliases but rather re-generated them
when unplug was necessary. This is very cumbersome since the knowledge
when and which alias to use needs to be stored in the hotplug code as
well.
While this patch will not strictly improve this situation since there
still will be two places containing this code it at least will allow to
remove the mess from the disk-unplug code and will prevent introducing
more mess when adding blockdev support.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add tests for upcoming re-generation of aliases for the secret objects
used by qemu when upgrading libvirt.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Rather than trying to figure out which alias was used, store it in the
status XML.
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>
Change the disk encryption type to qcow2+luks so that the appropriate
secret objects are generated. This tests that the proper alias is used
for the passphrase secret object.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The disk encryption part is no way relevant to the rest of the test so
drop it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Commit 656151bf fixed formatting of the <cmdline> element. Perhaps it
would have been noticed and fixed earlier if we had a test. With this
change, all possible cases of formatting <cmdline> from xmconfig are
covered
1. no 'extra=' or 'root=' in xm.cfg
2. 'extra=' but no 'root=' in xm.cfg
3. 'root=' but no 'extra=' in xm.cfg
4. both 'root=' and 'extra=' in xm.cfg
Case 1 is covered by all existing paravirt tests since they have no
'extra=' or 'root='. Case 2 is covered by adding 'extra=' to a few
of the existing paravirt tests. Cases 3 and 4 are covered by new
tests that only test conversion of xm.cfg to xml.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
My commit b8b42ca added support for formatting the vsock
command line without actually checking if it's supported.
Add it to the per-device validation function.
https://bugzilla.redhat.com/show_bug.cgi?id=1291851
Reported-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
To avoid the <source> vs. <target> confusion,
change <source auto='no' cid='3'/> to:
<cid auto='no' address='3'/>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Suggested-by: Daniel P. Berrangé <berrange@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
When preparing qemuCaps for test cases the following is
happening:
qemuTestParseCapabilitiesArch() is called, which calls
virQEMUCapsLoadCache() which in turn calls
virQEMUCapsInitHostCPUModel() which sets qemuCaps->kvmCPU and
qemuCaps->tcgCPU.
But then the code tries to update the capabilities:
testCompareXMLToArgv() calls testUpdateQEMUCaps() which calls
virQEMUCapsInitHostCPUModel() again overwriting previously
allocated memory. The solution is to free host cpuData in
testUpdateQEMUCaps().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
There's no point in calling testInitQEMUCaps() (which sets
info.qemuCaps) only to overwrite (and leak) it on the very next
line.
==12962== 296 (208 direct, 88 indirect) bytes in 1 blocks are definitely lost in loss record 265 of 331
==12962== at 0x4C2CF26: calloc (vg_replace_malloc.c:711)
==12962== by 0x5D28D9F: virAllocVar (viralloc.c:560)
==12962== by 0x5D96AB4: virObjectNew (virobject.c:239)
==12962== by 0x56DB7C7: virQEMUCapsNew (qemu_capabilities.c:1480)
==12962== by 0x112A5B: testInitQEMUCaps (qemuxml2argvtest.c:361)
==12962== by 0x1371C8: mymain (qemuxml2argvtest.c:2871)
==12962== by 0x13AD0B: virTestMain (testutils.c:1120)
==12962== by 0x1372FD: main (qemuxml2argvtest.c:2883)
Removing the function call renders @gic argument unused therefore
it's removed from the macro (and all its callers).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Found by cppcheck:
[tests/metadatatest.c:284]: (error) Uninitialized variable: test
[tests/objecteventtest.c:855]: (error) Uninitialized variable: test
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Create a new vsock endpoint by opening /dev/vhost-vsock,
set the requested CID via ioctl (or assign a free one if auto='yes'),
pass the file descriptor to QEMU and build the command line.
https://bugzilla.redhat.com/show_bug.cgi?id=1291851
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Add a new 'vsock' element for the vsock device.
The 'model' attribute is optional.
A <source cid> subelement should be used to specify the guest cid,
or <source auto='yes'/> should be used.
https://bugzilla.redhat.com/show_bug.cgi?id=1291851
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Move the check for boot elements into a separate function
and remove its dependency on the parser-supplied bootHash table.
Reconstructing the hash table from the domain definition
effectively duplicates the check for duplicate boot order
values, also present in virDomainDeviceBootParseXML.
Now it will also be run on domains created by other means than XML
parsing, since it will be run even for code paths that did not supply
the bootHash table before.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
When computing a baseline CPU for a specific hypervisor we have to make
sure to include only CPU features supported by the hypervisor. Otherwise
the computed CPU could not be used for starting a new domain.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Collin Walling <walling@linux.ibm.com>
This is required for virCPUBaseline to accept a list of guest CPU
definitions since they do not have arch set.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Collin Walling <walling@linux.ibm.com>
The virDomainDetachDeviceAlias API is designed so that it only
sends detach request to qemu. It's user's responsibility to wait
for DEVICE_DELETED event, not libvirt's. Add @async flag to
qemuDomainDetach*Device() functions so that caller can chose if
detach is semi-synchronous (old virDomainDetachDeviceFlags()) or
fully asynchronous (new virDomainDetachDeviceFlags()).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1566416
Commit id 'fe2af45b' added output for logical_block_size and
num_blocks for both removeable and fixed storage, but did not
update the nodedev capability causing virt-xml-validate to fail.
It's listed as optional only because it only prints if the
sizes are > 0. For a CDROM drive the values won't be formatted.
Update the nodedevxml2xmltest in order to output the values
for storage based on the logic from udevProcessRemoveableMedia
and udevProcessSD with respect to the logical_blocksize and
num_blocks calculations.
Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by Michal Privoznik <mprivozn@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1572491
Commit id '02129b7c0' added a single pagesElem for slightly
different purposes. One usage was an output for host page size
listing and the other for NUMA supported page sizes. For the
former, only the pages unit and size are formatted, while for
the latter the pages unit, size, and availability data is formatted.
The virt-xml-validate would fail because it expected something
extra in the host page size output. So split up pagesElem a bit
and create pagesHost and pagesNuma for the differences.
Modify some capabilityschemadata output to have the output - even
though the results may not be realistic with respect to the
original incarnation of the data.
Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by Michal Privoznik <mprivozn@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1572491
Commit id 'd2440f3b5' added printing the <microcode> for the
capabilities, but didn't update the capabilities schema.
While at it, update capabilityschemadata for caps-test2
and caps-test3 to output some value for validation.
Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by Michal Privoznik <mprivozn@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1572491
Commit id 'b3fd95e36' added rdma as a valid option for
virCapabilitiesAddHostMigrateTransport, but didn't update
the capabilities schema resulting in possible virt-xml-validate
failure.
While at it, update the capabilityschemadata for caps-qemu-kvm
Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by Michal Privoznik <mprivozn@redhat.com>
Commit id 'e4938ce2f' changed the esx_driver to use 'vpxmigr'
instead of esx for virCapabilitiesAddHostMigrateTransport, so
update the capabilities to allow virt-xml-validate to pass and
update the test to use the newer name.
Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by Michal Privoznik <mprivozn@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1572491
Commit id '78661cb' added a physical output, but failed to update
the schema resulting in a failure from virt-xml-validate.
While at it - update the storagevolschemadata for the output.
Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by Michal Privoznik <mprivozn@redhat.com>
Report domaincaps <features><genid supported='yes'/> if the guest
config accepts <genid/> or <genid>$GUID</genid>.
Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1149445
If the domain requests usage of the genid functionality,
then add the QEMU '-device vmgenid' to the command line
providing either the supplied or generated GUID value.
Add tests for both a generated and supplied GUID value.
Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
Add the query of the device objects for the vmgenid device
Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
The VM Generation ID is a mechanism to provide a unique 128-bit,
cryptographically random, and integer value identifier known as
the GUID (Globally Unique Identifier) to the guest OS. The value
is used to help notify the guest operating system when the virtual
machine is executed with a different configuration.
This patch adds support for a new "genid" XML element similar to
the "uuid" element. The "genid" element can have two forms "<genid/>"
or "<genid>$GUID</genid>". If the $GUID is not provided, libvirt
will generate one and save it in the XML.
Since adding support for a generated GUID (or UUID like) value to
be displayed modifying the xml2xml test to include virrandommock.so
is necessary since it will generate a "known" value.
Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
We don't use the text monitor since we dropped support for pre-JSON
qemus. Drop the test so that we can later delete the text monitor
support.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The capability also represents that 'blockdev-add' is functional. It's
necessary to detect it via presence of 'blockdev-del' since blockdev-add
did not have the unsupported 'x-blockdev-add' version previously and
thus would be marked as present even if we could not use it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@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>
Commit 766d5c1b deprecated the capability, because we were assuming
it for every QEMU binary. At the time of the introduction, there
was no way to probe for this via QMP.
However since QEMU 1.5.0 (which is the earliest version we support)
we can rely on the query-command-line-options command to detect this
feature.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1534418
Just like ec982f6d92 denies hugepages for non-existent
guest NUMA nodes in case there are some nodes configured.
Unfortunately, when there are none, qemuBuildNumaArgStr() is not
called and thus we have to have check in qemuBuildMemPathStr()
too.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The JSON property generator should not escape commas as we do on the
command line. The JSON->commandline generator already does that.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We have to escape commas when formatting them on the command line. Add a
test case of a TLS path containing a comma.
Note that the output is wrong, this test case is to prove there's a bug.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
According to virDomainScreenshot() documentation, screens are
numbered sequentially. e.g. having two graphics cards, both with
four heads, screen ID 5 addresses the second head on the second
card.
But apart from that, there's nothing special happening here.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
As of v2.12.0-rc0~32^2 QEMU is capable specifying which display
device and head should the screendump be taken from. Track this
capability so that we can use it later in our virDomainScreenshot
API.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Let us update the existing xml and replies files for QEMU 2.12.0 on
s390x.
Used a z14 using a QEMU 2.12 GA build and the following sequence:
tests/qemucapsprobe /usr/bin/qemu-system-s390x > \
tests/qemucapabilitiesdata/caps_2.12.0.s390x.replies
VIR_TEST_REGENERATE_OUTPUT=1 tests/qemucapabilitiestest
VIR_TEST_REGENERATE_OUTPUT=1 tests/domaincapstest
Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.vnet.ibm.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Everything can be disabled by not using the parent element. There's no
need to store this explicitly. Additionally it does not add any value
since any configuration is dropped if enabled='no' is configured.
Drop the attribute and adjust the code accordingly.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Disk source definition should be validated in
qemuDomainValidateStorageSource rather than in individual generators of
command line arguments.
Change to the XML2XML test is required since now the definition is
actually validated at define time.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Support OpenGL when using SDL backend via -sdl,gl=on. Add associated
tests.
NB: Usage of DO_TEST_CAPS_LATEST in qemuxml2argv doesn't work in
this case because -sdl gl is not introspectable.
Signed-off-by: Maciej Wolny <maciej.wolny@codethink.co.uk>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Support OpenGL acceleration capability when using SDL graphics.
Signed-off-by: Maciej Wolny <maciej.wolny@codethink.co.uk>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Support OpenGL accelerated rendering when using SDL graphics in the
domain config. Add associated test and documentation.
Signed-off-by: Maciej Wolny <maciej.wolny@codethink.co.uk>
Reviewed-by: John Ferlan <jferlan@redhat.com>
In a lot of our mocks (if not all of them) we use our internal
APIs (e.g. VIR_ALLOC). So far, we're relying on test binary that
links with the mock to drag in libvirt.so. Well, this works only
partially. Firstly, whatever binary we execute from tests will
fail (e.g. as Martin reported on the list ./qemucapsprobe fails
to execute qemu). Secondly, if there's a program that tries to
validate linking (like valgrind is doing) it fails because of
unresolved symbols.
Because of that we have to link our mocks with libvirt.so.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Generates the QEMU command line for the vfio-ccw device.
Adds various functionality testing for vfio-ccw in libvirt:
1. Generation of QEMU command line from domain xml file
2. Generation of dump xml from domain xml file
3. Checks duplicate/invalid addresses for vfio-ccw devices.
Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.vnet.ibm.com>
Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Reviewed-by: Stefan Zimmermann <stzi@linux.ibm.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Introduces the vfio-ccw model for mediated devices and prime vfio-ccw
devices such that CCW address will be generated.
Alters the qemuxml2xmltest for testing a basic mdev device using vfio-ccw.
Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.vnet.ibm.com>
Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Reviewed-by: Stefan Zimmermann <stzi@linux.ibm.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Let us introduce the capability vfio-ccw for supporting the basic
channel I/O passthrough, which have been introduced in QEMU 2.10. The
current focus is to support dasd-eckd (cu_type/dev_type = 0x3990/0x3390)
as the target device.
Let us also introduce the capability QEMU_CAPS_CCW_CSSID_UNRESTRICTED
for virtual-css-bridge. This capability is based on the
cssid-unrestricted property which exists if QEMU no longer enforces
cssid restrictions based on ccw device types.
Vfio-ccw capability is dependent on the hidden virtual-css-bridge, so
that we are able to probe for the cssid-unrestriced property to make
sure the devices are visible to non-mcss-e enabled guests.
Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.vnet.ibm.com>
Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Let us introduce the capability QEMU_CAPS_CCW for virtual-css-bridge
and replace QEMU_CAPS_VIRTIO_CCW with QEMU_CAPS_CCW in code segments
which identify support for ccw devices.
The virtual-css-bridge is part of the ccw support introduced in QEMU 2.7.
The QEMU_CAPS_CCW capability is based on the existence of the QEMU type.
Let us also add the capability QEMU_CAPS_CCW to the tests which
require support for ccw devices.
Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.vnet.ibm.com>
Reviewed-by: Bjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1480668
QEMU has this new feature memory-backend-file.discard-data=yes
which is a nifty optimization. Basically, when qemu is quitting
or on memory hotplug it calls munmap() and close() on the file
that is backing the memory. However, this does not mean kernel
won't stop touching that part of memory. It still might. With
this feature enabled we tell kernel: "we don't need this memory
nor data stored in it". This makes kernel drop the memory
immediately without trying to sync memory with the mapped file.
Unfortunately, this cannot be turned on by default because we
can't be sure when users really don't care about what happens to
data after qemu dies. So it has to be opt-in. As usual, there are
three places where one can configure memory attributes. This
patch adds the feature to all of them.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
QEMU has possibility to call madvise(.., MADV_REMOVE) in some
cases. Expose this feature to users by new element/attribute
discard.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This capability tracks if memory-backend-file has discard-data
attribute or not.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This capability tracks if qemu has "qom-list-properties" monitor
command.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
For command line we need two things:
1) -object pr-manager-helper,id=$alias,path=$socketPath
2) -drive file.pr-manager=$alias
In -object pr-manager-helper we tell qemu which socket to connect
to, then in -drive file-pr-manager we just reference the object
the drive in question should use.
For managed PR helper the alias is always "pr-helper0" and socket
path "${vm->priv->libDir}/pr-helper0.sock".
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
This is a definition that holds information on SCSI persistent
reservation settings. The XML part looks like this:
<reservations enabled='yes' managed='no'>
<source type='unix' path='/path/to/qemu-pr-helper.sock' mode='client'/>
</reservations>
If @managed is set to 'yes' then the <source/> is not parsed.
This design was agreed on here:
https://www.redhat.com/archives/libvir-list/2017-November/msg01005.html
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Rather than have virJSONValueArraySize return a -1 when the input
is not an array and then splat an error message, let's check for
an array before calling and then change the return to be a size_t
instead of ssize_t.
That means using the helper virJSONValueIsArray as well as using a
more generic error message such as "Malformed <something> array".
In some cases we can remove stack variables and when we cannot,
those variables should be size_t not ssize_t. Alter a few references
of if (!value) to be if (value == 0) instead as well.
Some callers can already assume an array is being worked on based
on the previous call, so there's less to do.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@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>
Remove gnulib from _LDADD and move LDADDS to replace it. Also reformat
the _SOURCES so that they can be easily extended.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
New tests will add new data structures so rename the 'data' structure.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The gluster protocol in qemu uses two styles, one of which is legacy and
not covered by the QAPI schema.
To allow using of the new style in the blockdev-add code, add a
parameter for qemuBlockStorageSourceGetBackendProps which will switch
between the two modes.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Save and restore node names if we know them or when we will be
generating them in the status XML.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The -no-kvm-pit-reinjection option has been deprecated since
its introduction in QEMU 1.3. See commit <1569fa1>.
Drop the capability since all the QEMUs we support allow tuning
the kvm-pit properties via -global.
Also add the QEMU_CAPS_KVM_PIT_TICK_POLICY to the clock-catchup
tests, since expecting it to succeed with QEMU that does not
have kvm-pit makes no sense.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
We have been checking whether qemu-img supports the -o compat
option by scraping the -help output.
Since we require QEMU 1.5.0 now and this option was introduced in 1.1,
assume we support it and ditch the help parsing code along with the
extra qemu-img invocation.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
We have two leftover "capabilites" for qemu-img:
QEMU_IMG_BACKING_FORMAT_OPTIONS
QEMU_IMG_BACKING_FORMAT_OPTIONS_COMPAT
The former says we are able to specify the backing format via -o
(which has been the case for a long time now) and the second one
says we can use -o compat to specify the qcow2 version.
Since we require QEMU 1.5.0, we can always assume -o compat,
which was introduced in QEMU 1.1.
Drop the test cases using FMT_OPTIONS which have a FMT_COMPAT
counterpart to prepare for deprecating FMT_OPTIONS (and these flags)
completely.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
<features><vmcoreinfo/> is a bare boolean XML property. We don't really
use this format anymore and instead prefer tristate <X state=on|off/>
since it's required for modeling on/off/default. If for example future
qemu started enabling vmcoreinfo by default we wouldn't have any way
for the user to turn this off.
Convert it to tristate. For writing XML this is semanticly the same,
<vmcoreinfo/> is processed as <vmcoreinfo state='on'/>.
For apps reading guest XML this is technically an API change,
as they might misinterpret <vmcoreinfo state='off'/>, however this
has only been present in libvirt since 3.10.0 and I don't think any
apps are dependent on this yet
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Now that mocking NUMA information works on FreeBSD, there are
no longer any test cases that need to be restricted to Linux
only.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
While the current amount of mocking works just fine on most of
our target platforms, it somehow causes issues when using Clang
on FreeBSD.
Work around the issue by mocking a couple more functions. It's
not pretty, but it makes qemuxml2argvtest pass on FreeBSD at
long last.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
There are only a couple remaining issues preventing it from
working on FreeBSD. Let's fix them.
With the mocking in place, qemumemlocktest and qemuxml2xmltest
can finally succeed on FreeBSD.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Clang complains about it:
error: second argument to 'va_arg' is of promotable type
'mode_t' (aka 'unsigned short'); this va_arg has undefined
behavior because arguments will be promoted to 'int'
[-Werror,-Wvarargs]
mode = va_arg(ap, mode_t);
^~~~~~
Work around the issue by passing int to va_arg() and casting
its return value to mode_t afterwards.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
We're using virFileCanonicalizePath() everywhere now, so
mocking this function has become entirely pointless.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
